CIR triangle forumla for QoS calculations

Supposedly an easy way to remember equations in physics and maths, is only really useful at low levels.

It works like this – if I want to remember how to use the formula for density, Density = Mass / Volume , I’d put it into a triangle like so –

/
/
/ M
/——
/ D * V
/———-

Now, if I want the formula for Density, I just cover up the D with my finger, and all that’s left is the M/V bit. That’s my equation. The same works for working out all the letters.

The idea is that you just remember the order of letters in the triangle rather than the equation. Not that much use, though.

Tc = Bc/CIR (in seconds) is the formula.

The router internally calculates the value of Tc based on the configured CIR and Bc values.

If Bc/CIR is more than or equal to 125 ms, it uses an internal Tc value if the router determines that traffic flow will be more stable with a smaller interval.
You can use the show traffic-shape command to determine whether your router is using an internal value for Tc or the value that you configured.

In your example with CIR of 64K and Bc of 8000K, (8,000/64,000) = 0.125 or 125ms. If we wanted a Tc of 100ms, we would simply configure the Bc to be 6400. Then using the formula Tc=Bc/CIR it would be 6,400/64,000 = .1 or 100ms.

Best wishes,

Keith

https://learningnetwork.cisco.com/thread/14406

CEF Adjacency Types That Require Special Handling

Adjacency Types That Require Special Handling

In addition to adjacencies associated with next-hop interfaces (host-route adjacencies), other types of adjacencies are used to expedite switching when certain exception conditions exist. When the prefix is defined, prefixes requiring exception processing are cached with one of the special adjacencies listed in Table 4.

Table 4 Adjacency Types for Exception Processing
This adjacency type…

Receives this processing…

Null adjacency

Packets destined for a Null0 interface are dropped. This can be used as an effective form of access filtering.

Glean adjacency

When a router is connected directly to several hosts, the FIB table on the router maintains a prefix for the subnet rather than for the individual host prefixes. The subnet prefix points to a glean adjacency. When packets need to be forwarded to a specific host, the adjacency database is gleaned for the specific prefix.

Punt adjacency

Features that require special handling or features that are not yet supported in conjunction with CEF switching paths are forwarded to the next switching layer for handling. Features that are not supported are forwarded to the next higher switching level.

Discard adjacency

Packets are discarded.

Drop adjacency

Packets are dropped, but the prefix is checked.

CEF Adjacency Types That Require Special Handling

Difference between CEF, FAST SWITCHING and PROCESS SWITCHING

Process switching requires the CPU to be personally involved with every forwarding decision.

Fast switching still uses the CPU, but after a packet has been forwarded, information about how to reach the destination is stored in a fast-switching cache. This way, when another packet going to the same destination is seen, the next hop information can be re-used from the cache, so the processor doesn’t have to look up and assemble all the information again. If the information is not cached, (for example a first packet for a given destination network) the CPU will have a similar workload, for that packet, as if fast switching was not in use.

Cisco Express Forwarding (CEF), is the evolution of optimizing the router to make it be able to forward more packets faster. CEF cheats a little, by building a Forwarding Information Base (FIB), and an adjacency table. The FIB is accessed very quickly based on how they built it (it is Cisco proprietary), and contains pre-computed reverse lookups, next hop information for routes including the interface and L2 information to use. (All the stuff a router would have to consider when forwarding a packet).

In short:

Process switching is like doing math, long hand.

Fast switching, using the cache, is like doing a problem once long hand, and subsequent problems you remember the answer for, (from memory, or the cache).

CEF is like having programmed an excel spreadsheet, and when the numbers hit the cells, the answer is already calculated.

Best wishes,

Keith

from link:
https://learningnetwork.cisco.com/thread/12668

debug condition interface

debug condition interface

in this example setting debug condition interface f0/0 will only show the OSPF hellos on f0/0 not f0/1
R1 R2
R1 R2

FIRST no condition set:
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar 1 00:05:33.503: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1 from 2.2.2.1
*Mar 1 00:05:34.443: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 1.1.1.1
*Mar 1 00:05:35.191: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 1.1.1.2
*Mar 1 00:05:35.191: OSPF: End of hello processing
*Mar 1 00:05:36.283: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/1 2.2.2.2
*Mar 1 00:05:36.283: OSPF: End of hello processing
*Mar 1 00:05:43.007: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1 from 2.2.2.1
*Mar 1 00:05:44.415: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 1.1.1.2
*Mar 1 00:05:44.415: OSPF: End of hello processing
*Mar 1 00:05:44.419: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 1.1.1.1
*Mar 1 00:05:45.979: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/1 2.2.2.2
*Mar 1 00:05:45.979: OSPF: End of hello processing

SECOND debug condition set:
R1# debug condition interface f0/0
Condition 1 set
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar 1 00:06:12.575: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 1.1.1.2
*Mar 1 00:06:12.575: OSPF: End of hello processing
*Mar 1 00:06:13.315: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 1.1.1.1
*Mar 1 00:06:21.639: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 1.1.1.2
*Mar 1 00:06:21.639: OSPF: End of hello processing
*Mar 1 00:06:22.379: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 1.1.1.1

to remove condition:
R1#no debug condition interface f0/0
This condition is the last interface condition set.
Removing all conditions may cause a flood of debugging
messages to result, unless specific debugging flags
are first removed.

Proceed with removal? [yes/no]: yes
Condition 1 has been removed