CCIE R&S Advanced Technologies Class v4.5 - PIM Sparse Mode Configuration

Transcript

1	Introduction	0h 43m
2	Using the Cisco Documentation	0h 52m
3	Ethernet Overview, Layer 2 Switchports, Trunking, ISL, 802.1q, DTP	0h 47m
4	VTP, VTP Authentication, VTP Pruning	1h 02m
5	VTP Prune Eligible List, VTP Transparent, VTP Troubleshooting, Trunk Allowed List, Extended VLANs	0h 48m
6	VLAN and VTP Review	0h 19m
7	SVIs, Native Routed Interfaces, Router-on-a-Stick	0h 46m
8	Layer 2 EtherChannel, EtherChannel Load Balancing, Layer 3 EtherChannel	0h 57m
9	802.1q Tunneling, Layer 2 Protocol Tunneling, EtherChannel over 802.1q Tunneling	1h 03m
10	STP Root Bridge Election, STP Root Port Election, STP Designated Port Election, STP Priority, STP Cost, STP Port-Priority	1h 46m
11	STP Review	0h 12m
12	STP Timers, STP PortFast	0h 34m
13	STP UplinkFast	0h 11m
14	STP BackboneFast	0h 12m
15	STP BPDU Filter	0h 13m
16	STP BPDU Guard	0h 11m
17	STP Root Guard	0h 11m
18	STP Loop Guard, Unidirectional Link Detection (UDLD)	0h 11m
19	Multiple Spanning-Tree Protocol (MST)	0h 40m
20	Rapid Spanning-Tree Protocol (RSTP), Rapid-PVST	0h 18m
21	MST with Multiple Regions	0h 33m
22	Flex Links	0h 16m
23	Frame Relay	0h 39m
24	Frame Relay Configuration Part 1	0h 34m
25	Frame Relay Configuration Part 2	0h 41m
26	Frame Relay Switching	0h 27m
27	Back-to-Back Frame Relay	0h 08m
28	Frame-Relay End-to-End Keepalives	0h 18m
29	PPP, PPP PAP Authentication, PPP CHAP Authentication	0h 59m
30	PPPoFR, PPPoE	0h 40m
31	Transparent Bridging, IRB	0h 32m
32	Fallback Bridging	0h 14m
33	IP Routing Overview, Switching Paths, Static Routing	0h 42m
34	Static Routing Examples	0h 25m
35	IP Default-Gateway, IP Default-Network	0h 14m
36	On-Demand Routing (ODR)	0h 07m
37	Floating Static Routes	0h 10m
38	Backup Interface	0h 29m
39	Enhanced Object Tracking, IP SLA, Reliable Static Routing	0h 21m
40	Policy Routing	0h 43m
41	GRE Tunneling, GRE Recursive Routing Errors	0h 27m
42	Reliable Backup Interface with GRE	0h 25m
43	RIP Overview, RIP Versions, RIP Auto-Summary	0h 48m
44	RIP Split-Horizon, RIP Timers	0h 22m
45	RIP Broadcast Updates, IP Directed Broadcast, IP Broadcast-Address, Smurf Attacks, Fraggle Attacks	0h 16m
46	RIP Unicast Updates	0h 03m
47	RIP Offset-List	0h 18m
48	RIP Authentication	0h 11m
49	RIP Summarization	0h 10m
50	Prefix-Lists, RIP Distribute-List Filtering, RIP Administrative Distance Filtering	0h 48m
51	RIP Default Routing, RIP Conditional Default Routing	0h 18m
52	RIP Triggered, RIP Validate Update Source,	0h 12m
53	EIGRP Overview	0h 29m
54	EIGRP Auto-Summary	0h 07m
55	EIGRP Split-Horizon	0h 11m
56	EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface	0h 24m
57	EIGRP Hello-Interval, EIGRP Hold-Time	0h 05m
58	EIGRP Authentication	0h 11m
59	EIGRP Time Based Authentication	0h 25m
60	EIGRP Path Selection, EIGRP Metric Weights, EIGRP Traffic Engineering	0h 47m
61	EIGRP Unequal Cost Load Balancing, EIGRP Variance	0h 19m
62	EIGRP QUERY, EIGRP Summarization, EIGRP Leak-Map	0h 28m
63	EIGRP Stub Router Advertisement	0h 22m
64	EIGRP Default Routing	0h 13m
65	EIGRP Route Filtering	0h 11m
66	EIGRP Router-ID	0h 07m
67	Miscellaneous EIGRP Features	0h 02m
68	OSPF Overview	0h 27m
69	Establishing OSPF Adjacencies, Understanding the OSPF Database	0h 43m
70	OSPF Network Type Broadcast, OSPF DR/BDR Election, OSPF over NBMA, OSPF Network Type Non-Broadcast and Point-to-Multipoint	0h 56m
71	OSPF Network Type Point-to-Point, OSPF Network Type Mismatch	0h 13m
72	OSPF Network Type Point-to-Multipoint Non-Broadcast, OSPF Per Neighbor Cost	0h 17m
73	OSPF Network Type Loopback	0h 02m
74	OSPF Path Selection	0h 27m
75	OSPF Convergence Timers	0h 09m
76	OSPF Authentication	0h 12m
77	OSPF Summarization	0h 32m
78	OSPF Stub Areas, OSPF Totally Stubby Areas, OSPF NSSAs, OSPF Totally NSSAs	0h 40m
79	Controlling OSPF NSSA Redistribution	0h 02m
80	OSPF Type 7 to 5 Translator Election, OSPF LSA Type 3 Filter, OSPF Forwarding Address Suppression	0h 24m
81	Route Redistribution Overview	0h 36m
82	Route Redistribution Configuration & Verification, Connected Redistribution	0h 22m
83	OSPF External Path Selection, TCL PING Scripting	0h 33m
84	Routing Loops Overview, EIGRP Route Loop Prevention	0h 55m
85	Metric Based Routing Loops, Route Tagging	0h 46m
86	Administrative Distance Based Routing Loops, Debug IP Routing, IP Route Profile	0h 58m
87	BGP Overview, BGP Peering Types	0h 51m
88	Establishing BGP Peerings, EBGP Multihop, BGP Neighbor Disable Connected Check, BGP TTL Security	0h 49m
89	BGP 4-Byte ASNs	0h 20m
90	BGP Local AS, BGP Peer Groups	0h 30m
91	BGP Next-Hop Self, BGP Next-Hop Processing	0h 30m
92	BGP Route Reflectors	0h 37m
93	Large Scale BGP Route Reflectors with Clusters	0h 34m
94	BGP Confederation	0h 37m
95	BGP NLRI Advertisements, BGP Network Statement, BGP Redistribution	0h 43m
96	BGP Aggregation, BGP Aggregation & Summary-Only, BGP Aggregation & Unsuppress-Map	0h 46m
97	BGP Origin, BGP Aggregation & AS-Set, BGP Aggregation & Advertise-Map	0h 22m
98	BGP Conditional Route Injection	0h 21m
99	BGP Bestpath Selection, BGP Multipath, BGP Weight	0h 53m
100	BGP Local Preference, BGP Local Preference and Communities, BGP AS-Path Prepending,	0h 30m
101	BGP MED, BGP MED Missing As Worst, BGP Deterministic MED	0h 17m
102	BGP Communites, BGP Regular Expressions	0h 43m
103	BGP Filtering, BGP Convergence Timers, BGP Default Routing, Miscellaneous BGP Features	0h 24m
104	MPLS Overview, MPLS Label Distribution Protocol (LDP)	1h 05m
105	MPLS Tunnels, MPLS Penultimate Hop Popping (PHP)	0h 40m
106	MPLS Layer 3 VPNs Overview, VRF Lite	0h 36m
107	MPLS Layer 3 VPNs and VPNv4 BGP	1h 08m
108	MPLS Layer 3 VPN Verification & Troubleshooting	0h 49m
109	MPLS Layer 3 VPN OSPF PE-CE Routing Overview	0h 06m
110	MPLS Layer 3 VPN OSPF PE-CE Routing Path Selection & Sham-Links	2h 01m
111	MPLS Layer 3 VPN OSPF PE-CE Routing Loop Prevention & Down-Bit, OSPF Capability VRF-Lite	0h 40m
112	IPv6 Overview, IPv6 ICMPv6 ND, IPv6 over NBMA	0h 44m
113	IPv6 Routing Overview, IPv6 Static Routing	0h 28m
114	IPv6 RIPng	0h 20m
115	IPv6 EIGRPv6	0h 09m
116	IPv6 OSPFv3	0h 31m
117	MP-BGP for IPv6	0h 26m
118	IPv6 Tunneling	1h 13m
119	Multicast Overview, IGMP	0h 34m
120	PIM Overview	0h 18m
121	PIM Dense Mode	1h 03m
122	PIM Sparse Mode	0h 30m
123	PIM Sparse Mode Configuration	0h 36m
124	PIM Sparse Mode RPF & RP Troubleshooting	0h 27m
125	Auto-RP, Multicast over GRE Tunnels	0h 53m
126	Bootstrap Router (BSR), Bidirectional PIM, Source Specific Multicast (SSM)	0h 40m
127	MSDP, Anycast RP	0h 27m
128	IPv6 Multicast Routing	0h 24m
129	QoS Overview, IntServ QoS, DiffServ QoS, IP Precedence, DSCP, MQC, HQF	0h 41m
130	MQC Classification	0h 44m
131	FIFO, FQ, WFQ, CBWFQ, HQF	0h 50m
132	LLQ	0h 23m
133	WRED	0h 31m
134	Traffic Shaping, Traffic Policing	0h 40m
135	Frame Relay Traffic Shaping (FRTS)	0h 33m
136	RSVP	0h 07m
137	Catalyst 3560 QoS	1h 00m
138	IOS Security Overview, Access Lists (ACLs)	0h 58m
139	Time Based ACLs, Dynamic ACLs	0h 33m
140	Reflexive ACLs	0h 21m
141	TCP Intercept, Content Based Access Control (CBAC)	0h 34m
142	Zone Based Policy Firewall (ZBPF)	1h 09m
143	AAA, Local Authentication, Local Authorization, Role Based CLI Access	0h 43m
144	Port Security, Static CAM Entries, Storm Control, 802.1X Authentication, PACLs, RACLs, VLAN Access Maps (VACLs)	0h 48m
145	DHCP Snooping, Dynamic ARP Inspection (DAI), IP Source Guard	0h 12m
146	Protected Ports, Private VLANs	0h 25m
147	IP Services Overview, HSRP	1h 10m
148	VRRP, GLBP	0h 28m
149	NAT	0h 42m
150	DHCP, DNS	0h 30m
151	NetFlow	0h 09m
152	WCCP, Miscellaneous IP Services	0h 06m
153	System Management Overview, NTP, NTP Authentication	0h 24m
154	SNMP, RMON	0h 38m
155	Syslog, Telnet, SSH, Banners	0h 21m
156	EEM Scripting, Miscellaneous System Management	0h 26m
Total Duration		81h 42m

Slides - Diagrams

Slides - Introduction

Slides - Ethernet Switching

Slides - Advanced Ethernet Switching

Slides - Frame Relay

Slides - PPP

Slides - Transport Bridging

Slides - Redistribution

Slides - IOS Security

Slides - Layer 2 Security

Slides - IP Services

Slides - System Management

0:00:12	So now let's take a look at the actual implementation
0:00:15	of sparse mode.
0:00:16	What I have here is the IGP topology is still prebuilt
0:00:21	where we are running EIGRP on all links
0:00:23	and I've changed the IP PIM dense mode command to the
0:00:27	IP PIM sparse mode on all of the interfaces.
0:00:30	So we essentially have a one-to-one mapping of
0:00:33	IGP plus PIM on all of the links.
0:00:35	What I have not done yet is defined who the rendezvous point is
0:00:41	so this means without this information if we hear any
0:00:44	senders or we hear about any receivers, we're not going to
0:00:47	know where to actually send that traffic.
0:00:50	So before we look at assigning the rendezvous point
0:00:53	let's look at potential failures on sending the registration
0:00:56	or sending the PIM joins.
0:00:59	So there'll be two ways that we look at this.
0:01:02	On Router 4
0:01:05	Router 4 is going to have a join
0:01:09	that is configured on Fast Ethernet 0/0
0:01:12	so this is where the receiver is going to be located.
0:01:15	Router 5 is going to have the sender
0:01:21	come in on that interface in on Fast Ethernet 0/0
0:01:25	so what we would want to see on Router 4 and Router 5
0:01:28	is what happens when we have the sender or the receiver
0:01:31	but we don't know about who the rendezvous point is.
0:01:39	So first on all the neighbors let's go to exec mode and look at the
0:01:44	show ip pim neighbors
0:01:47	so just like we would in dense mode, once we configure
0:01:51	multicast routing globally and then at the interface level
0:01:54	this would be our first verification.
0:01:56	So on Router 1 we see that we have our adjacencies here
0:02:00	it says we're adjacent with Router 4 and 6
0:02:03	Router 3 and Router 5
0:02:05	Router 2 is adjacent with Router 5 and Router 3
0:02:09	3 is adjacent with 1, 2, 5 and Switch 1
0:02:12	so all of the links they should properly be running PIM here.
0:02:16	Now again, you do want to check this on both sides
0:02:20	because if there's an issue where I can send multicast packets
0:02:23	to you, but you cannot send multicast packets to me
0:02:29	well what happens is that when you say show ip pim neighbors
0:02:32	you would see my address, but when I say show ip pim neighbors
0:02:36	I would not see yours.
0:02:38	And typically the case where this is going to happen is that if
0:02:41	you're configuring multicast over the frame relay network
0:02:44	where Router 5 does not have the broadcast keyword
0:02:48	as it's mapping to Router 1
0:02:50	but Router 1 does have that mapping.
0:02:53	When we looked at the show ip pim neighbors on Router 5
0:02:56	we would see 1's address, but 1 would not see 5
0:03:01	so you do need to check it on both sides to make sure that the
0:03:03	adjacency is actually there bidirectionally.
0:03:08	Next step we would look at the show ip pim
0:03:14	rp mapping
0:03:16	this tells us who is the rendezvous point and what particular multicast
0:03:20	groups is it servicing.
0:03:23	So right now I have not configured the rendezvous point
0:03:26	so we don't have any group to RP mappings.
0:03:29	This would then imply if I receive a join message from any of the neighbors
0:03:35	or I start to receive a multicast feed inbound, I'm not going to know
0:03:39	what to do with it.
0:03:41	Now we could tell this if we went to Router 4
0:03:44	and look at the debug ip pim
0:03:47	then at the LAN interface we'll say ip igmp join 224.1.1.4
0:04:01	we should see that Router 4 is going to send the S,G join
0:04:08	but it's not actually going out any of the interfaces.
0:04:14	Now likewise if we were to receive traffic inbound from
0:04:17	a source, let's say on Router 5 and we look at the debug ip pim
0:04:24	then on Switch 2 I'll do a ping
0:04:29	an extended ping going to 224.1.1.4
0:04:37	the outgoing interface is going to be VLAN 58 so this is the link
0:04:42	that connects to Router 5
0:04:43	the source address is 155.28.58.8
0:04:49	so that's my local address.
0:04:52	Now Router 5 should receive this inbound
0:04:56	but basically it's not going to know what to do with this.
0:05:01	So normally what we should see on Router 5 is a message saying that
0:05:05	it's trying to do the registration and it's sending this to the rendezvous point.
0:05:11	Now one important point to note about this and
0:05:15	I mentioned this before talking about the election for
0:05:17	the designated router.
0:05:19	The designated router is the device that is in charge of
0:05:22	sending the registration.
0:05:24	Now if there are multiple first hop routers connected to
0:05:28	the segment, it means that the device that has either the
0:05:32	higher DR priority or the one that has the higher IP address
0:05:39	is going to be elected the DR
0:05:42	Now where this is going to matter is when you try to
0:05:46	source traffic from the router itself for testing
0:05:50	is that if the router's interface itself is the DR
0:05:55	when you send traffic out that link, it is not going to
0:05:59	perform a registration.
0:06:03	So specifically in this case, I'm trying to say that the
0:06:06	sender is located on Switch 2
0:06:09	so I'm sending the traffic this direction ultimately
0:06:11	I'm trying to get Router 4 to receive it out that link.
0:06:17	When we look at the address of Router 5, we have
0:06:19	.5, on Switch 2 we have .8
0:06:24	since they both have the default DR priority value
0:06:28	and I believe the default is zero
0:06:31	but whatever the default is, they both have a tie for
0:06:34	this value, so it means that whoever has the higher
0:06:36	address, they're the one that is elected the DR.
0:06:41	So normally what would happen is that when traffic is
0:06:43	coming in from the server
0:06:46	the device that is the DR is going to trigger the registration message.
0:06:51	So in this case, Switch 2 gets elected the DR because it
0:06:54	has the higher address.
0:06:56	But now the problem is that it is sending the traffic
0:06:59	out the interface and that's not going to trigger the registration.
0:07:06	Now normally this is never going to be an issue in a real design
0:07:09	for multicast because from the router's perspective
0:07:12	the multicast is always coming in, it's not being locally generated
0:07:17	out the interface.
0:07:20	So what I mean by this if we had an actual server that was
0:07:24	located on VLAN 58, when the server sends traffic on
0:07:27	the VLAN 58, from Switch 2's perspective, this traffic is coming in.
0:07:34	So the inbound data plane is going to trigger the registration
0:07:37	but not the outbound data plane.
0:07:43	So we end up in this kind of strange case where the
0:07:45	network could be designed correctly and everything is fine
0:07:48	but we simply cannot test it from the router itself
0:07:55	so what I'm going to do here is go to Router 5 and change the
0:07:58	DR priority so that 5 is elected the DR and not Switch 2
0:08:05	but the key is the only reason I need to do this is because I don't
0:08:08	have an actual application to test the multicast feed from.
0:08:13	So on Fast Ethernet 0/0 I'm going to say ip pim dr priority
0:08:19	it says higher is better so let's give it a 1000
0:08:25	Router 5 says I'm electing the new designated router
0:08:28	it's changing from Switch 2 to myself.
0:08:31	On Switch 2 if we look at the show ip pim neighbors
0:08:40	it says Router 5 is elected the DR
0:08:43	and the default DR priority there is 1
0:08:51	so now let's try this again, let's go to Switch 2
0:08:53	we'll send a ping
0:08:56	we'll ping to 224.1.1.5 let's say
0:09:04	this is going to go out VLAN 58
0:09:07	and it's coming from 155.28.58.8
0:09:13	so it's my connected interface there.
0:09:21	On Router 5 if we look at the show debug
0:09:24	we are debugging IP PIM
0:09:26	but we don't see any output from the process.
0:09:29	Now another thing we could do here is try to do a packet
0:09:32	level debug to see if Router 5 is even receiving this to begin with.
0:09:38	Now the only issue with this is just like normal
0:09:41	unicast routing is that transit traffic between the
0:09:45	interfaces is normally cef switched.
0:09:48	When the traffic goes to the cef process, the router is
0:09:51	not going to show it in the debug output because only
0:09:54	process switch traffic is debugged.
0:09:56	So what this means is that if I want to see the debug output for
0:09:59	traffic moving between the interfaces, I need to
0:10:02	go to the link level and say no ip mroute cache
0:10:07	so on Router 5 I'm going to say this on all the interfaces
0:10:10	no ip mroute cache
0:10:26	so on Switch 2 let's try this again, let's just ping
0:10:28	any random address. Let's say ping 224.1.1.6
0:10:34	we should see this come in on Router 5
0:10:40	but it's not seeing any of the outputs so let's look at the
0:10:43	show ip mroute
0:10:49	and notice that we do see the *,G entries
0:10:54	but we don't see the S,Gs
0:10:59	and it's not a coincidence that these are matching the addresses
0:11:01	that I'm pinging so on Switch 2 if I were to ping
0:11:04	a new address let's say 224.1.1.7
0:11:09	This should show up in the multicast routing table of Router 5
0:11:12	but we don't know about the source.
0:11:15	Basically this is an indication
0:11:17	that the group is running in sparse mode
0:11:21	but we don't know who the rendezvous point is.
0:11:25	So normally at this point, we would send the registration
0:11:28	message, but Router 5 doesn't have the RP configured, so
0:11:30	it cannot do that.
0:11:34	The same would have been true on Router 4
0:11:37	when we join the group here, we should see that
0:11:41	this is going to trigger a PIM join message.
0:11:46	If we go to Fast Ethernet 0/0 say ip igmp join
0:11:50	225.1.1.8
0:11:56	we should see that on the link that goes up towards the rendezvous point
0:12:00	we should send a join message.
0:12:02	If we show ip mroute for 224.1.1.8
0:12:09	it says the incoming interface is null because we do not
0:12:13	know who the rendezvous point is.
0:12:18	Normally what we should see from the receiving portion
0:12:20	of the tree, so Router 4 is where the receiver is
0:12:24	located. It means the receiver is on the rendezvous point's tree
0:12:28	the RPT or the shared tree.
0:12:31	When we look at the show ip mroute here
0:12:34	it should say that the incoming interface
0:12:37	is the link that we would use to get back to the
0:12:40	rendezvous point.
0:12:43	So here it says the incoming interface is null basically
0:12:47	it means we don't know who the rendezvous point is
0:12:50	or we don't know how to reach them based on the routing table.
0:12:56	So now let's look at the second case where maybe we
0:12:59	know who the rendezvous point is, but we don't have a route to their address.
0:13:03	So on all of the devices now, simply what I'm going to do
0:13:07	is say ip pim rp address is 1.2.3.4
0:13:13	so this is any random address that does not exist in the topology.
0:13:17	They're not going to have a route to it and they're not going to be able to
0:13:19	reach it.
0:13:29	We can see the debug ip pim output on Router 5
0:13:31	it's now saying for these particular *,G entries
0:13:34	I now know who the rendezvous point is.
0:13:37	It's 1.2.3.4
0:13:40	If on Switch 2 we send traffic to a new address
0:13:43	so let's ping 224.1.1.9
0:13:50	Router 5 should receive this inbound. It says
0:13:54	I know who the rendezvous point is, it's 1.2.3.4
0:13:58	but if we were to look at the debug ip packet detail
0:14:07	and send these packets again let's say 224.1.1.10
0:14:13	What we should see on Router 5
0:14:16	is that it tries to send a unicast message to 1234
0:14:24	and we can see this is kind of a lot of output here because
0:14:26	not only is this EIGRP now, this is also PIM on the
0:14:30	interfaces, so what I want to do now, I want to
0:14:34	run this debug again, but say not eigrp and not pim
0:14:38	so for access list 100
0:14:42	I'll say ip access list 100 or ip access list extended 100
0:14:46	sequence number 5 is going to deny
0:14:52	or actually no, I don't want to deny PIM because I want to see
0:14:54	the PIM output, so let's just deny the EIGRP.
0:14:57	Let's say debug ip packet detail 100
0:15:07	Now on Switch 2 let's send packets to a new destination
0:15:10	224.1.1.11
0:15:18	Router 5 says the packet came in from 155.28.58.8
0:15:23	destination is 224.1.1.11
0:15:31	Normally what we would see here is that there should be
0:15:34	a unicast PIM packet that goes towards the rendezvous point.
0:15:42	Now if we look at the show ip pim rp mapping
0:15:48	we do know who the rendezvous point is
0:15:51	but simply based on the fact that we don't have a route to it
0:15:55	then we're not going to be able to use that.
0:15:58	Now if I were to actually configure this let's say
0:16:00	I went to Router 1 and advertised this interface
0:16:04	let's say interface loopback 1234
0:16:07	has the address 1.2.3.4
0:16:10	/32
0:16:12	then under the EIGRP process
0:16:22	which is process number 100 let's say router eigrp 100
0:16:26	network 1.2.3.4
0:16:31	Since now the rest of the domain should actually have
0:16:33	a route to 1.2.3.4
0:16:39	let's look at both of those debugs again. Let's say debug
0:16:41	ip packet detail 100 and debug ip pim
0:16:47	What we should now see is that when someone starts
0:16:50	to send traffic
0:16:53	Router 5 should receive this inbound
0:16:57	it's going to generate a unicast PIM
0:17:02	we see it's protocol number 103 that's going to
0:17:04	1.2.3.4
0:17:06	that is the registration message.
0:17:09	So if we look at the full
0:17:14	full output for this
0:17:28	Router 5 is saying I'm sending the PIM version 2
0:17:31	register packet to 1.2.3.4
0:17:33	about this specific source
0:17:36	and this specific group, so this is the S,G entry
0:17:40	it's 155.28.58.8, 224.1.1.12
0:17:49	Now if the registration is correct, what we should see is that there
0:17:53	is a register stop message that comes back in from Router 1
0:17:58	so if we look for the pim debug response for this
0:18:11	and we may want to do this again this debug without the debug ip packet detail
0:18:17	but here we're receiving it says we received register stop
0:18:19	from the rendezvous point about this particular source
0:18:24	and this particular group so this means that we told Router 1
0:18:27	who the sender is and Router 1 acknowledged us.
0:18:34	If we sent the register, but did not get the register stop
0:18:38	it would mean that Router 1 did get the registration, but it
0:18:41	is denying it and typically the reason that that is going to
0:18:45	happen is if the rendezvous point doesn't have a route back to the
0:18:48	sender, so at this point now on the topology
0:18:54	when Router 5 does the registration
0:18:58	specifically the group was 155.28.58.8, 224.1.1.12
0:19:12	If we go to everyone in the topology and show ip mroute
0:19:16	224.1.1.12
0:19:20	which device's routing table should this show up in.
0:19:30	It should be the DR who is connected to the sender
0:19:35	so in this case that's Router 5 and it should be the rendezvous point.
0:19:39	The other devices in the topology like Router 2
0:19:42	Router 3, Router 6 they should not see the S,G
0:19:46	for this particular group.
0:19:49	So let's go to all the routers
0:19:53	let's say show ip mroute for 224.1.1.12
0:20:00	Router 1 who is the RP it should see this in the routing table.
0:20:05	Now notice that there's multiple sources here.
0:20:08	The reason why there's multiple sources is that when I did the
0:20:12	ping on Switch 2
0:20:15	I didn't actually specify what interface to make it come from.
0:20:18	So this was just a standard ping.
0:20:23	So really what I should do is do an extended ping
0:20:25	and give it just one individual source address.
0:20:28	So let's try this with a new group let's say
0:20:31	ping 224.1.1.13
0:20:40	extended commands yes I want it to go out VLAN 58
0:20:44	and I want it to come from 155.28.58.8
0:20:51	Now no one has actually joined to that group yet.
0:20:56	So if we go to all of the routers
0:20:59	and say show ip mroute for that group.
0:21:03	Ideally what we should see is that Router 1 knows about this
0:21:07	and Router 5 knows about this
0:21:09	because one is the rendezvous point
0:21:14	so it does know it says this particular source is sending to this group.
0:21:19	This is the interface that the traffic should come in on
0:21:23	because the reverse path towards that source is Router 5
0:21:30	Right now the group is pruned because I don't actually have any receivers.
0:21:33	This is also why the outgoing interface list is null.
0:21:38	Once I actually start to forward the traffic, I should see
0:21:40	in the outgoing interface list the link that points down to
0:21:43	the actual receiver.
0:21:50	If we look at the same output on Router 2, it does not know
0:21:52	about that entry, neither does Router 3
0:21:56	nor 4
0:21:59	5 is going to know this because it is the DR
0:22:03	so it has the actual destination directly attached.
0:22:06	Notice that Router 5 again says the incoming interface
0:22:09	is the LAN segment that goes to the sender
0:22:13	but the outgoing interface list is null
0:22:17	so in a normal sparse mode operation, the rendezvous point
0:22:22	should know about all of the senders in the network
0:22:26	but the devices in the transit path are not going to install
0:22:29	this until the traffic actually wants to be received.
0:22:34	So this means that the actual packet flow like the
0:22:37	IPTV feed it's only going to be local to the
0:22:41	DR's segment. It's not going to be forwarded out to the
0:22:44	transit links until someone actually wants it.
0:22:48	Now once someone does send a join message, what we should see
0:22:51	is that the rendezvous point is going to learn about that
0:22:55	based on the PIM join message. It's going to then
0:23:00	build the reverse path tree up to the receiver
0:23:08	so from the rendezvous point down to the receiver
0:23:13	then once the receiver actually starts to get the packets, then it
0:23:16	can build the shortest path tree back to the source.
0:23:21	So now let's say for this particular group
0:23:23	which is 224.1.1.13
0:23:29	we have the source here so the source is Switch 2
0:23:33	we'll say the destination
0:23:35	is Switch 3's LAN segment.
0:23:39	Now I know that either Router 3 or Router 6 are going to be
0:23:42	in the transit path here, so we're going to look at the
0:23:44	debug ip pim on both of them, then regardless
0:23:47	of what the path is to that receiver
0:23:50	we should see the debug output happen at least on one of them.
0:23:56	So on Router 3 let's look at the debug ip pim
0:24:01	same thing on Router 6
0:24:03	Now if we were to go to Switch 3
0:24:08	so Switch 3 is going to be the receiver
0:24:11	on the VLAN 9
0:24:14	I'll say ip igmp join 224.1.1.13
0:24:20	I should see on either Router 3 or Router 6
0:24:24	so depending on who is in the reverse path
0:24:27	and I could see this if I were to trace to 1.2.3.4
0:24:33	so it shows me Router 6 is in my transit path to get to the DR
0:24:36	or excuse me, to get to the rendezvous point.
0:24:39	So Router 6 should see the join message come in.
0:24:44	It says a join was received about the particular group
0:24:49	224.1.1.13
0:24:54	It came in from Switch 1 on Fast Ethernet 0/0.67
0:24:59	The RPT bit is set.
0:25:05	That means that this is a shared tree join.
0:25:10	Again, the shared tree is the *,G
0:25:13	so it basically means that this join message is supposed to go up to the
0:25:16	rendezvous point, so *,G join it came in from Switch 1
0:25:21	RPT bit is set.
0:25:24	So now we would need to know who's the rendezvous point.
0:25:28	Router 6 does a lookup on this locally it says
0:25:30	that it's going to 1234 that's the RP
0:25:36	so now I am locally going to originate the join
0:25:40	my reverse path neighbor up to 1.2.3.4
0:25:43	is Router 1's address on the LAN segment
0:25:47	so now I continue to send the join.
0:25:50	Once Router 1 gets this, it now knows both pieces of the puzzle.
0:25:55	It knows who the sender is and it know who the receiver is.
0:25:59	So we should see on the way back
0:26:01	we now receive the traffic in from the rendezvous point
0:26:08	then ultimately there is going to be a new join and a new
0:26:12	prune that is for the S,G entry.
0:26:19	So here is us building the tree back to the rendezvous point.
0:26:22	Once this is built, we're going to receive another
0:26:27	join that is for...
0:26:37	let's see, who is this coming from? This should be coming in from...
0:26:49	I believe it should be coming in from Switch 1
0:26:52	What this is going to depend on is what is
0:26:55	Switch 3's path to get to 155.28.58.8
0:27:04	Ok, it's still through Router 6
0:27:07	so we should see that Router 6 received the shared tree prune
0:27:12	and then the shortest path tree join
0:27:21	which is this one.
0:27:24	This is Router 6 telling Router 1 you need to
0:27:27	leave the shared tree.
0:27:31	Then we have a join that is going to Router 1
0:27:35	it says the S bit prune that's telling them again to
0:27:38	leave the shared tree. There should be another
0:27:42	join message here that says I want to be added to the tree
0:27:46	for that
0:27:51	so you can see it's a lot of output sometimes it's hard to read through this
0:27:54	but the end result of this if we look at the show ip mroute for
0:27:57	224.1.1.13 what we should see is that Router 6 is
0:28:02	now on the -- excuse me, the shortest path tree
0:28:06	for this particular entry.
0:28:08	And when you look at it in real time, it happens almost
0:28:11	immediately. It's within like 10 milliseconds
0:28:14	that as soon as the traffic starts to flow over the tree
0:28:17	over the shared tree, you immediately switch over to the
0:28:20	shortest path tree.
0:28:22	So in reality you're only going to see the delay if you configure the
0:28:25	router manually to delay it with the ip pim spt threshold command
0:28:31	but when we look at the show ip mroute output and it says the
0:28:35	flag is capital T, this means that we are on the shortest path tree.
0:28:44	Now the reason that this is going to be significant
0:28:46	the difference between the shared tree and the shortest path tree
0:28:51	is that the RPF lookup will be different depending on
0:28:55	whether we're doing this on the shared tree or the
0:28:59	shortest path tree.
0:29:01	And also this is going to be different between sparse mode and
0:29:04	dense mode. In the case of sparse mode
0:29:08	the rendezvous point is going to do an RPF check on
0:29:11	two things. It does it against the register message coming in
0:29:15	from the DR and the actual data plane forwarding from the source.
0:29:24	The receiver of the traffic is going to perform the RPF check up
0:29:29	against the rendezvous point
0:29:31	the RPF check against the rendezvous point if it is on the
0:29:34	shared tree.
0:29:37	If the receiver is on the shortest path tree,
0:29:40	the RPF check happens on the source.
0:29:46	Now ultimately which one you're going to be on depends on
0:29:49	how the traffic is routed through the network
0:29:52	and there's a couple different ways that we could change this.
0:29:55	First and foremost again this is going to be based on the
0:29:57	unicast routing.
0:29:59	So if we were to change how EIGRP is routing in the network here
0:30:03	that would change how the shared tree and then ultimately
0:30:07	the shortest path tree is going to be built.
0:30:10	But most of the time once the unicast domain is solid
0:30:14	you probably don't want to mess with that within the
0:30:16	scope of the lab exam
0:30:18	because it really only makes logical sense that they would
0:30:21	give you the multicast section after IGP is done
0:30:24	because none of the multicast is going to work until IGP is
0:30:27	up and working.
0:30:29	So if you have some sort of problem with the reverse path
0:30:32	forwarding failure, a lot of the times it would not
0:30:35	make sense to change your IGP domain
0:30:37	because basically you'd have to go back and re-verify
0:30:40	all of that stuff.
0:30:42	Within the scope of multicast, if I'm trying to fix a reverse
0:30:46	path forwarding failure, I want to make a change that is
0:30:49	just going to affect multicast and not the other sections.
0:30:54	So mainly there's two ways that we can modify this
0:30:57	with a manual static multicast route
0:31:01	which is the IP mroute statement
0:31:03	or dynamically with multicast BGP.
0:31:09	Now regardless of whichever one that we use, multicast
0:31:11	BGP or the static multicast route, those are automatically
0:31:15	going to override any of the dynamic information learned
0:31:18	from IGP.
0:31:21	So if I have an EIRGP route versus the static multicast route
0:31:24	I'm going to choose the static multicast route.
0:31:27	If I have an EBGP learned multicast route
0:31:31	I would prefer that over EIGRP because EBGP has the
0:31:36	lower administrative distance.
0:31:40	Now if I had an IBGP learned multicast route
0:31:43	and I were comparing it to EIGRP
0:31:48	then I would choose the EIGRP route because that
0:31:50	has the lower administrative distance than IBGP.
0:31:54	So it's the same type of logic as regular unicast routing
0:31:57	where the static route has a distance of one
0:32:00	it's going to be the lowest administrative distance versus a
0:32:03	connected interface
0:32:06	then the dynamically learned protocols are going to follow their
0:32:08	normal administrative distance structure where
0:32:11	EBGP would be the most preferred so if you're running
0:32:14	multicast BGP and the route's coming from an external neighbor
0:32:17	that's what you're going to use.
0:32:20	But if it's coming from an IBGP neighbor
0:32:23	basically it means that the multicast source is
0:32:25	within your network
0:32:27	so you would prefer the IGP route to the multicast source
0:32:31	versus the IBGP route.
0:32:34	Now you could technically change this if you wanted to by
0:32:37	changing the administrative distance, but generally
0:32:40	IGP is going to be the best way to do this because it's
0:32:43	you're already assuming that it is a loop-free path.
0:32:48	Now one thing that's really important to note about this
0:32:50	is that if you use a static multicast route
0:32:54	to allow traffic to be routed in a different link
0:32:59	it does not say that traffic can come in that interface
0:33:03	it says that traffic must come in that interface.
0:33:09	And the place that this is a common mistake that people
0:33:11	do is to configure a default multicast route out an interface
0:33:17	which essentially means that that can be the only link
0:33:21	that multicast is allowed to come inbound.
0:33:26	So let's say theoretically in our particular topology
0:33:29	that I have some RPF failure that's occurring on Switch 1
0:33:34	so for the traffic that's coming in from Switch 2
0:33:37	let's say that the traffic is routed this direction.
0:33:42	This is the multicast.
0:33:45	But for whatever reason my IGP route
0:33:49	points out towards Router 6
0:33:51	so since the incoming interface for multicast and the outgoing
0:33:55	interface for unicast do not agree with each other
0:33:58	then I'm not going to be able to accept the traffic inbound.
0:34:02	So in order to fix this, I go to Switch 1
0:34:05	and say that I want a static multicast route that points to any
0:34:08	source, so it's 0.0.0.0/0
0:34:12	and it's via 155.28.37.3
0:34:18	so I'm essentially saying it's ok for the traffic to
0:34:21	come in from Router 3
0:34:25	The problem is now since the static route has a
0:34:28	lower administrative distance than IGP
0:34:32	the rules work a little bit different here than normal
0:34:34	than normal unicast routing does
0:34:36	because with normal unicast routing, we don't look at the
0:34:39	distance first, we look at what?
0:34:45	We look at the longest match.
0:34:47	So normally if we were to compare /0 versus /24
0:34:53	the /24 is a longer match so we would pick that.
0:34:56	But in the case of a multicast static route, it's not the longer
0:35:01	match that we care about
0:35:04	it's basically that the static route is going to be preferred
0:35:06	over anything, so essentially what this means is that on
0:35:09	Switch 1 if I were to point the default multicast route
0:35:12	out Fast Ethernet 0/3
0:35:16	I would not be able to have a source
0:35:19	that is located on Router 4
0:35:21	send traffic that direction
0:35:27	because the multicast static route not only says
0:35:30	this is where the traffic should come in
0:35:33	it's saying this is where the traffic must come in.
0:35:38	Now additionally this is also going to control how we build
0:35:41	the tree either to the rendezvous point
0:35:46	or to the sender.
0:35:51	So let's look at some cases where we do have problems with the
0:35:53	reverse path forwarding and then what are the different possible
0:35:56	solutions that we can change in order to fix this.

Now Viewing

CCIE R&S Advanced Technologies Class v4.5
Title:	CCIE R&S Advanced Technologies Class v4.5
Duration:	81h 42m
The CCIE Routing & Switching Advanced Technologies Class is the first step in understanding CCIE level technologies and is a companion to the Advanced Technologies Lab Workbook. Each technology you need to know for the CCIE Routing & Switching lab will be described in detail using an instructor led hands on demonstration. The class consists of over 80 hours of in depth explanations and examples.
Get instant access to our entire library!
	Sign Up
Download this Course
$299.00	Add to Cart

PIM Sparse Mode Configuration

Create Bookmark