CCIE IP Precedence Vs DSCP Values

The Table bellow Represent the TOS filed in the IP Header

IPP

IPP

IPP

DropP

DropP

0

ECN

ECN

Drop P = Drop Precedence
IPP = IP Precedence

The Drop Precedence means the probability that the packet
will be dropped, the higher the value it is more likely to be dropped.

IP Precedence is the importance value of a packet, the
higher the value the packet is more valuable.

In IP Precedence we have 0 – 7 values and you can see that
by looking into the amount of fields that we have

Routing (Best Effort) - 000
Priority - 001
Immediate - 010
Flash – 011 => mainly used for Voice Signaling or for
Video
Flash-Override - 100
Critical – 101 => mainly used for Voice RTP
Internet - 110
Network - 111

You do not need to remember the name value of each one, you
can simply see it with:

TermServ(config)#access-list 100 permit ip any any precedence ?
(0-7) Precedence value
critical Match packets with critical precedence (5)
flash Match packets with flash precedence (3)
flash-override Match packets with flash override precedence (4)
immediate Match packets with immediate precedence (2)
internet Match packets with internetwork control precedence (6)
network Match packets with network control precedence (7)
priority Match packets with priority precedence (1)
routine Match packets with routine precedence (0)


with that said now we have added 2 more bits for the or more
accurate 3 bits but only 2 bits we are playing with for allowing us to
determine with in the scope of class witch is more preferable and for that we
divided to 6 main classes

Class 0 – Called also Best Effort all bits are 0 = 000000
Now we have 4 classes that are with in them divided each to 3 separate

Class1	AF11 001010	AF12 001100	AF13 001110
Class2	AF21 010010	AF22 010100	AF23 010110
Class3	AF31 011010	AF32 011100	AF33 011110
Class4	AF41 100010	AF42 100100	AF43 100110

DropP
IPP

Class 5 – EF Expedited Forwarding last class used for Voice
Traffic Mainly 101110, and also all the DSCP values you can see with a simple ACL, but I think it is better to understand the principle and once you understand it you will not have to remember you will simply know. As it is relatively simple but the quantity makes people confused.

TermServ(config)#access-list 100 permit ip any any dscp ?
(0-63) Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)

CCIE INTERNETWROKEXPERT

I would like to express my grate appreciation to the contribution that Internetworkexpert brings to the Technical Community, although they are a commercial company they do give away free seminars and do help people that are in need to learn and do not have a lot of financial resources to do that.


So Thank you InternetworkExpert

Here is a recent v-sminar that was added on IPv6 http://classroom.internetworkexpert.com/p23982603/

Soon they will release a v-seminar that was transferred yesterday for free on Catalyst QoS.

Also grate thanks to there top notch instructors:

Brian Dennis, CCIE #2210 (R&S/ISP Dial/Security/Service Provider)

Brian McGahan, CCIE #8593 (R&S/Service Provider/Security)

THANK YOU!

CCIE SecureCRT Tip

As you all know the mostly used terminal in the CCIE lab exam is the old SecureCRT from http://www.vandyke.com/ without the tabs addition. but what you do have is the key mapping.

you can set for example:

F6 to be the CTRL SHIFT 6+x by simply setting the send sting in the key map to \036x
F7 to be CTRL SHIFT 66 sequence of braking in the middle of a trace or a ping when you connected with the Access Server by mapping \0366

I my self practicing without the shortcuts but each person with its own methods and tactics.

I believe the quest is like a preparation for the Olympics so practice practice practice.

CCIE VERIFY RPF FAIL

One of the major issues with Multicast is finding the RPF and making sure that there is no Failure in it, as if we do have a fail we can patch it by adding ip mroute (like a static route but only to pass the RPF, not actually changing the path of the packet).

So how we can find such fail we have several tools the first one is to find if we have rp mapping.

R6#sh ip pim rp ma
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:14:48, expires: 00:00:02
R6#

we see here in that example that we do have RP Mapping so we defiantly passed the RPF.

I have made an RPF fail and we now will try to trace it:

R6#sh ip mroute count
IP Multicast Statistics
3 routes using 1962 bytes of memory
3 groups, 0.00 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

we see that we are not receiving packets from our mapping agent when we listen on group 224.0.1.40 so some where along the path we have an RPF fail.

R6#sh ip mrou
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 227.0.0.1), 00:02:19/00:02:47, RP 0.0.0.0, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:47

(*, 224.0.1.1), 00:02:19/00:02:53, RP 0.0.0.0, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:53

(*, 224.0.1.39), 00:01:12/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(150.1.5.5, 224.0.1.39), 00:01:12/00:01:47, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 166.1.12.1
Outgoing interface list: Null

(*, 224.0.1.40), 00:02:20/00:02:54, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:20/00:02:54

R6#

we see above that we do get see the RP and we get it from 166.1.12.1 so lets got to R1 (166.1.12.1).

R1#sh ip mroute count
IP Multicast Statistics
5 routes using 2946 bytes of memory
4 groups, 0.25 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 1
RP-tree: Forwarding: 0/0/0/0, Other: 1/0/1

Group: 224.0.1.39, Source count: 1, Packets forwarded: 12, Packets received: 12
Source: 150.1.5.5/32, Forwarding: 12/1/48/0, Other: 12/0/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0
R1#

we see here that we still do not recive any packet on the mapping group.

R1#sh ip mrou
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 227.0.0.1), 00:01:24/00:02:10, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.0.1.1), 00:01:24/stopped, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(166.1.12.4, 224.0.1.1), 00:00:20/00:03:09, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:00:20/00:03:09

(166.1.12.6, 224.0.1.1), 00:00:20/00:03:09, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:00:20/00:03:09

(*, 224.0.1.39), 00:01:26/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00
Serial1/0, Forward/Sparse, 00:01:26/00:00:00

(150.1.5.5, 224.0.1.39), 00:01:26/00:02:56, flags: T
Incoming interface: Serial1/0, RPF nbr 166.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00

(*, 224.0.1.40), 00:01:27/00:02:04, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:27/00:00:00
Serial1/0, Forward/Sparse, 00:01:27/00:00:00

R1#

now lets go again one step forward to R5 to see if R5 is also not receiving packets for group of the mapping agent.

R5#sh ip pim rp ma
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:45, expires: 00:00:01
R5#

and we can see that we do receive the mapping from 150.1.3.3 on R5 so we know that the RPF fail happen on R1 to R3

Now I will tell you that R5 R3 and R1 are connected over FR (Physical Interface only) R5 is the hub and R1 and R3 are the spokes. so first we need to make sure that we enabled

R5(config-if)#ip pim nbma-mode

that command will make sure that packets received on one VC of the FR can go out that same interface to another VC for Sparse Groups Only

here bellow you can see the output of sparse group with the nbma-mode enable you can see it is going out of that same interface but to different IP (VC)

(*, 227.0.0.1), 20:05:09/stopped, RP 150.1.5.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, 166.1.0.3, Forward/Sparse, 00:15:40/00:01:01
Serial1/0, 166.1.0.5, Forward/Sparse, 04:28:41/00:02:42

And on that same router R5 although I have enabled nbma-mode you can see that for dense mode group it is acting different.

(*, 224.0.1.40), 17:24:56/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 17:24:56/00:00:00
Serial1/0, Forward/Sparse, 17:24:56/00:00:00

So now that we see that we traced where the RPF is we need to solve it, on R1

R1#sh ip route 150.1.3.3
Routing entry for 150.1.3.3/32
Known via "ospf 1", distance 110, metric 65, type intra area
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1536 1 255 1 1500
Last update from 166.1.0.3 on Serial1/0, 00:17:50 ago
Routing Descriptor Blocks:
* 166.1.0.3, from 150.1.3.3, 00:17:50 ago, via Serial1/0
Route metric is 65, traffic share count is 1

R1#sh ip route 166.1.0.3
Routing entry for 166.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Advertised by eigrp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/0
Route metric is 0, traffic share count is 1

we know that 224.0.1.40 is Dense mode group and it cannot pass the RPF due to that as it will not be able to go out the same interface it came in.
so what we can do is create a tunnel interface between R1 to R3. And set the RPF to check the path trough that tunnel.

interface Tunnel0
ip unnumbered Loopback0
ip pim sparse-mode
tunnel source Loopback0
tunnel destination 150.1.3.3
!
R1#sh run inc ip mrou
ip mroute 150.1.3.3 255.255.255.255 Tunnel0
R1#

!
interface Tunnel0
ip unnumbered Loopback0
ip pim sparse-mode
tunnel source Loopback0
tunnel destination 150.1.1.1
end

R3#
we must make sure that the source and the destination match exactly on both side like showed here and both on the interface that we are sourcing and destination and the tunnel we enabling PIM.

R1#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
166.1.0.5 Serial1/0 20:52:24/00:01:20 v2 1 / DR S
166.1.12.4 FastEthernet0/0 17:20:06/00:01:24 v2 1 / S
166.1.12.6 FastEthernet0/0 20:51:54/00:01:21 v2 1 / DR S
150.1.3.3 Tunnel0 00:02:12/00:01:30 v2 1 / S
R1#
R1#sh ip pim rp ma
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:10, expires: 00:00:02
R1#

And now we can go back to R6 and see that we have also mapping on R6 so we solved RPF fail.

R6#sh ip pim rp ma
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:33, expires: 00:00:03
R6#

CCIE PIM AUTO RP

In that section I would like to talk about Auto-RP, well not until recently I have had little to say about multicasting as it was something I know but like most I didn’t really understand or have struggled to really see how it works, I only know that when you enable it, you basically save bandwidth by using one stream instead of unicasting to each and every station, and on the basic it is true but the how it works is more important for us candidates.

So here I will show you how the Auto-RP works and what tools do we have to make it work. Well we should all know that we have today 3 basic operation modes of PIM

Sparse Mode – or as it called source tree and it is mostly used today Multicast Networks using a Pull Technology meaning if you do not ask I will not send it

Dense Mode – or as it called shared tree and this is the very basic of Multicast using Push Technology meaning I will always send and if you say you do not need it I will Prune back but after a certain time out I will again send to you just so you want miss it if you do need it in some point.

Sparse-Dense Mode – well this is a hybrid of the 2 methods meaning that I will Sparse if I have an RP (Rendezvous Point) but if I don’t have one or I loose it then I will fall over to Dense Mode.

When we enable PIM Sparse Mode we most have and RP the RP witch is like having a DR in the OSPF, it will be responsible on the Path for the Multicast Group.

To have RP in a Sparse Group we have 3 methods:
a) Static
b) Auto-RP Cisco proprietary
c) BSR the industry standard

We will talk here about Auto RP:
First Step before we start with any multicast config we need to make sure that all our unicasting routing is working so that is the initial step before we even think on Multicast.

Why?! Because Multicast is relaying on our Unicast to pass the traffic as we know RPF is done based on the Unicast routing Table and the RPF is basic check of backwards Path between the Sources of the Traffic to the Destination, with that said each time a new group is announced it must go trough the RPF check.

To Enable Auto RP we must specify an RP-Candidate and RP-Mapping

RP-Candidate is to announce your self as an RP, you can also announce one Router to be RP for certain groups and different Router to be RP for different groups.

RP-Mapping the Mapping agent can be the same Router as the Candidate but it also can be a different Router it is simply to send the router in the Multicast Domain the mapping to the RP.

When you enable the RP Candidate you Join a Group 224.0.1.39 and when you enable the Mapping you Join Group 224.0.1.40 also you can see that all Routers that you set with multicast join group 224.0.1.40 if you do:

R2#sh ip mrou
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:00:00/00:02:59, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:00/00:02:59


On the RP I am setting the announce and the discovery and the listner
The listner is actually to enable the pim to send the 224.0.1.39/40 as Dense Mode with out needing to enable sparse-dense mode or other workaround as this 2 groups must be in Dense Mode.
!
! I used a loopback as the source of the groups but you can also enable the source to come ! From a physical interface although if you loose that interface you will loose your RP. ! You must also remember that all Routers in the Multicast Domain must have Unicast ! Connectivity to the RP
!
ip pim autorp listener
ip pim send-rp-announce 150.1.1.1 scope 255 interval 10
ip pim send-rp-discovery Loopback0 scope 255 interval 10
!
!
Also if you use the loopback as the RP then you must enable on the loopback also PIM
After you enable on all the interfaces in your path PIM you should check for neighbor relationship:

R1#sh ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
120.1.0.3 Serial1/0 00:24:52/00:01:29 v2 1 / DR S
120.1.0.2 Serial1/0 00:26:37/00:01:38 v2 1 / S

Then you should check that you have mapping to the RP:

R3#sh ip pim rp ma
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.1.1 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:12:15, expires: 00:00:26

If one of the steps is failing then first check for RPF fail by:

R3#sh ip mroute count
IP Multicast Statistics
4 routes using 1788 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.0.1.39, Source count: 1, Packets forwarded: 0, Packets received: 11
Source: 150.1.1.1/32, Forwarding: 0/-1/0/0, Other: 11/0/11

Group: 224.0.1.40, Source count: 1, Packets forwarded: 0, Packets received: 11
Source: 150.1.1.1/32, Forwarding: 0/-1/0/0, Other: 11/0/11

If you had a fail here then the Other: 11/11/0 meaning that the failed would increase.

To solve a RPF fail you need to make sure that you pass the RPF check and the RPF check is done using the Unicast routing table meaning that you need to check that the path that the packet is taking is trough the Multicast Domain and not trough a non Multicast interfaces.

Also you can pass the RPF by adding a static

R3(config)#ip mroute 0.0.0.0 0.0.0.0
# For the exam you must ask if it is allowed.

When using PIM Sparse in NBMA environment like Frame Relay you need to make sure you enter the ip pim nbma command to disable the split horizon rule that traffic coming into the interface is not going out that same interface.

The IP pim nbma is working only for Sparse Mode Group

Candidate RP need to be able to communicate only with the mapping agent and the Routers in the Domain need to be able to communicate with the Mapping agent so from that we can understand that we need to watch our Route to the Mapping Agent.

Ok I think I will end it here for now, I hope this was good info.