CCIE Routing & Switching Advanced Technologies Class

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 34m
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 59m

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:13	In our next section here, we're going to look at the
0:00:15	specifics of PIM in dense mode how to do the basic configuration
0:00:20	what are the different verification techniques that we can use
0:00:23	and then if we do run into problems, what are the different troubleshooting
0:00:25	commands with the show commands, the debug commands and what are the
0:00:30	specific outputs that we're going to be looking for.
0:00:32	Now PIM dense mode we'll see has a lot of less design
0:00:36	options that are inherent to sparse mode
0:00:39	either with rendezvous points or source specific multicast
0:00:42	so there's really a limit to the number of problems
0:00:44	that we could run into with dense mode
0:00:46	mainly it would be related to some sort of Layer 2 problem in the
0:00:50	network or some sort of basic IGP routing problem
0:00:53	where we cannot properly perform the reverse path forwarding check
0:00:57	because essentially the configuration is only going to be
0:00:59	two commands, to enable multicast routing globally on the router
0:01:04	and then put pim dense mode at the interface level.
0:01:10	Now as I mentioned before, PIM in dense mode uses the
0:01:14	implicit join model or basically a push model where the routers
0:01:19	are going to flood all of the multicast traffic that they receive
0:01:22	out every single interface running PIM and it's up to the
0:01:26	routers on the other side of the link that if they do not want the
0:01:29	traffic, to send a PIM prune message that is
0:01:34	essentially going to unjoin the links that they do not want.
0:01:38	So we'll see that one of the main issues of using PIM in dense mode
0:01:42	is that it's not scalable because of this type of flooding
0:01:45	and also the amount of state information
0:01:48	for the *,Gs and S,Gs that's going to be
0:01:51	installed into the multicast routing table.
0:01:57	Now as you can see also their PIM is defined in RFC 3973
0:02:02	PIM for dense mode so if you want to get really specific information
0:02:05	about the packet formats or the actual adjacency state machine
0:02:10	then that stuff is going to be located in the RFC.
0:02:15	Now the first step for PIM in dense mode is going to be
0:02:18	to figure out who are the neighbors on the connected links.
0:02:21	So PIM for both dense and sparse mode it's going to use the
0:02:24	same basic protocol format for finding the neighbors.
0:02:27	It uses the reserved multicast address that is 224.0.0.13
0:02:34	Now this would then imply that any Layer 2 link that
0:02:38	we're running the protocol over we need to make sure that we can
0:02:41	send multicast packets out, so it's pretty obvious to figure that
0:02:45	out that if we're going to be running multicast on the interface
0:02:47	when we actually get to the data plane, then we need to make sure
0:02:50	that there's no problem with multicast transport over the Layer 2 interfaces.
0:02:55	Generally the only case that this is going to occur
0:02:58	is when we have multipoint non-broadcast multi-access
0:03:02	interfaces like a multipoint frame relay main interface
0:03:06	the multipoint frame relay sub interface
0:03:08	where we need to do the manual Layer 3 to Layer 2
0:03:11	resolution for the destination IP address to our local frame relay DLCI.
0:03:18	So on Router 5 in this specific case we have the
0:03:20	multipoint serial 0/0/0 interface
0:03:24	that's connected down to four different Layer 2 circuits.
0:03:27	We have 504, 501, 503 and 502
0:03:32	so this means that from the PIM control plane
0:03:35	when we go to send the packets out to 224.0.0.13
0:03:38	if Router 5 does not support pseudo broadcast on those
0:03:43	individual circuits, then we're not going to be able to establish
0:03:46	the PIM adjacency.
0:03:48	Now we can test this on the routers fairly quickly if we were
0:03:51	to just go to Router 5
0:03:54	and send packets to 225.255.255.255
0:04:00	so it's the all host broadcast
0:04:03	if I now get responses back in from routers 1, 2, 3 and 4
0:04:07	I know that I'm able to send broadcast and multicast
0:04:10	packets out those Layer 2 circuits.
0:04:14	So from the frame relay interface driver point of view
0:04:18	they're going to treat broadcast and multicast the same
0:04:21	they go into the frame relay broadcast queue so when we
0:04:24	look at the show run interface serial 0/0/0
0:04:28	we're using the broadcast keyword on the end of the
0:04:31	frame relay mapping. There's no separate command
0:04:34	that's going to be used for multicast.
0:04:36	And the same would be true for IPv6 so when we're doing
0:04:40	our manual frame relay map IPv6 commands
0:04:43	we need to make sure that the broadcast keyword is
0:04:45	associated with the circuit that's going to allow us
0:04:48	to have the pseudo broadcast support which then supports
0:04:51	the broadcast like the all 255s we just saw
0:04:54	and then all of the multicast packets.
0:04:58	If we were to look at the debug ip packet detail
0:05:03	and then enable multicast routing
0:05:07	so let's go to global config and actually before I do this, let's
0:05:10	turn off debugging for the EIGRP packets
0:05:16	so I'm using EIGRP as my underlying IGP
0:05:19	I can tell that for two different reasons.
0:05:22	One is that I'm sending packets to 224.0.0.10
0:05:25	which is the EIGRP reserved multicast address and also
0:05:29	because this is IP protocol number 88
0:05:32	so when I'm debugging IP packets, since the EIGRP
0:05:36	packets are process switched, they're locally
0:05:38	from the router, they're locally destined to the router
0:05:40	then it's going to show up in this output, so the first thing
0:05:43	I'm going to do is just exclude EIGRP from this debug.
0:05:46	So we'll say access list 100 deny eigrp any any
0:05:49	access list 100 permit ip any any
0:05:58	then to clean up the debug output a little bit, we'll say
0:06:01	no service timestamps
0:06:03	Now if we look at the debug ip packet detail 100
0:06:09	we should see that once multicast is enabled, so we'll
0:06:12	say ip multicast routing
0:06:16	then at the interface level ip pim dense mode
0:06:20	we should now see that Router 5 is going to do
0:06:23	two different things.
0:06:24	It's sending PIM messages
0:06:28	which are going to 224.0.0.3 -- 224.0.0.13
0:06:34	that is using IP protocol number 103
0:06:41	we then also have packets that are going to 224.0.0.1
0:06:45	which is the all hosts multicast and it says
0:06:50	this is protocol number 2
0:06:53	so if we were to look at the specific numbers
0:06:57	let's say access list 101 permit 2 any any
0:07:05	if we then look at the show access list 101
0:07:09	we can see protocol number 2
0:07:12	it's IGMP
0:07:14	so simply based on the fact that I have enabled PIM
0:07:17	on the interface, it means that the router is sending
0:07:21	IGMP query messages to all hosts on the segment
0:07:25	so it's going to 224.0.0.1
0:07:28	and then it's also sending an IGMP message to 224.0.1.40
0:07:37	which 224.0.1.40 is what address?
0:07:47	This is for auto RP
0:07:49	so 224.0.1.40 is the group that we're going to send
0:07:55	the mapping agent messages to so we'll this a little bit
0:07:58	later when we configure auto RP with sparse mode.
0:08:01	Basically what this means is that as soon as we enable the
0:08:04	multicast routing process, regardless of whether we're
0:08:08	we are running sparse mode or dense mode
0:08:10	the router is automatically going to try to join
0:08:13	224.0.1.40 to be a member of the auto RP mapping agent group.
0:08:23	So it essentially means the router is trying to figure out who is the
0:08:26	rendezvous point on any of the interfaces.
0:08:29	Now we'll see that this behavior has changed over
0:08:32	the IOS versions. In older versions you had to manually
0:08:36	enable this with either PIM in sparse dense mode or the
0:08:40	auto RP listener, but in the newer versions by default
0:08:43	the router will always listen for the messages from the
0:08:47	mapping agent.
0:08:48	So it's kind of an automatic workaround that they put in the code
0:08:52	that the router is always going to be a member of the
0:08:54	group 224.0.1.40
0:08:57	Now where we would see this additionally if we look at
0:08:59	the show ip mroute
0:09:03	we will always see a *,G entry for 224.0.1.40
0:09:07	even if we're not running auto RP
0:09:11	If we are running auto RP, not only will we see the
0:09:14	*,G entry, we should see the S,G entry where the
0:09:18	source is the mapping agent's address.
0:09:23	So we'll come back to look at that in more detail later
0:09:25	but we can see just with these two commands, we have IP multicast
0:09:28	routing in global config. At the link level we have
0:09:31	IP PIM in dense mode. We're sending PIM
0:09:34	going to 224.0.0.13 it's protocol number 103
0:09:38	it also enabled IGMP and we're now in IGMP client
0:09:42	for 224.0.1.40
0:09:47	So our next step then would be basically to enable
0:09:49	dense mode on every single interface.
0:09:52	So to speed this up, what I'm going to do
0:09:54	is basically go to the access server
0:09:57	and then send the command to every single interface that I
0:10:00	want it to participate in PIM in dense mode.
0:10:07	So from the access server I'm going to say
0:10:12	first go to global config and turn IP multicast routing on.
0:10:19	Now for some of the switches they run multicast routing with
0:10:24	distributed Cef in hardware so instead of saying ip multicast routing
0:10:28	you have to say ip multicast routing distributed
0:10:31	From a configuration point of view, there's going to be nothing
0:10:35	different beyond this, it's just that we're enabling the hardware
0:10:38	multicast switching process as opposed to the software
0:10:40	multicast switching that the regular IOS runs by default.
0:10:46	So now we have multicast done, I'll say that on all the LAN
0:10:49	interfaces we have ip pim dense mode
0:10:54	so for the routers that have two LAN interfaces, that's going to be
0:10:56	both of them. This would be on the serial interfaces
0:11:02	some of the routers have this as point to point sub interfaces
0:11:10	then I have some links that are point to point between
0:11:13	the routers serial 0/1
0:11:16	this is on routers 2, 3, 4 and 5 or actually 1, 2, 4 and 5
0:11:20	on Router 3, these are serial 1/2 and serial 1/3
0:11:27	so this is basically just a quick way so I can enable
0:11:30	it on all of the interfaces. Normally you would want to
0:11:33	go to all of the routers individually turn ip multicast routing on
0:11:37	turn PIM on on all of the connected links
0:11:39	then if we look at the show ip pim interfaces
0:11:44	it's going to show us what are the connected interfaces that are actually
0:11:47	running the protocol.
0:11:48	So if we were to correlate this
0:11:52	from the show ip interface brief
0:11:55	and I only care about the links that have IP addresses
0:11:59	assigned so I'm going to exclude any links that say
0:12:04	unassigned
0:12:06	then I'm going to compare this to the show ip pim interfaces
0:12:12	so ideally in the multicast network, every single
0:12:14	interface that runs IP should have PIM enabled on.
0:12:20	We'll see the reason why is that this is going to prevent
0:12:23	failures in the reverse path forwarding check or the
0:12:26	RPF check.
0:12:30	So again, I need to look at the
0:12:32	interfaces running IP and then also the PIM interfaces.
0:12:38	So on Router 1 I have four interfaces running IP
0:12:41	the LAN interface, two WAN interfaces and the loopback
0:12:45	the loopback interface doesn't need PIM enabled on.
0:12:49	The only case that I would need to run PIM on the loopback
0:12:52	is when I am the rendezvous point and the rendezvous point's
0:12:58	address is the loopback interface.
0:13:00	So this would be true of static RP, auto RP or BSR.
0:13:07	Whatever address is the address of the RP
0:13:10	whatever interface has that address assigned
0:13:12	that also needs to run PIM.
0:13:14	But in the case of dense mode since we don't have rendezvous points,
0:13:17	then we don't necessarily need to put it on the loopback.
0:13:20	Ok, we can put it there, but it's not really going to accomplish anything.
0:13:26	On Router 2 likewise we have the same one LAN interface
0:13:30	we have two WAN interfaces, right now they're all running PIM.
0:13:34	On Router 3 we have 1, 2, 3, 4 physical links and the loopback
0:13:43	and all of those are running PIM.
0:13:46	Fast Ethernet 0/1 this has the process enabled
0:13:49	but there's no IP address assigned, so that's not really
0:13:52	going to do anything, I could take it off that interface
0:13:54	but it's not going to hurt anything.
0:13:58	On Router 4 I have PIM enabled on the main
0:14:02	frame relay interface serial 0/0/0
0:14:06	but this is not where my IP address is assigned.
0:14:09	So then this is going to be a problem on Router 4
0:14:11	PIM needs to be configured on whatever is the link
0:14:14	that has the IP address assigned which may or may not
0:14:17	be the actual physical interface so on the sub interface I need to
0:14:21	say ip pim in dense mode
0:14:24	and then also on the point to point link that goes over to
0:14:28	Router 5
0:14:37	So in a real design here normally we would just enable PIM on
0:14:40	every single interface. Within the scope of the lab exam though
0:14:44	it's very important to note whatever interfaces they're telling
0:14:47	you either to enable multicast routing on or to not
0:14:51	because that ultimately is going to affect how the
0:14:54	reverse path forwarding check is run and then
0:14:57	how the multicast tree is going to be built.
0:15:00	So we'll first look at the case where multicast is
0:15:02	working fine because PIM is on all of the interfaces
0:15:05	then we'll see a problem where PIM is enabled on
0:15:08	some, but not all and what the end result of the multicast flow is going to be.
0:15:17	Then on Router 6 I have two separate Ethernet sub interfaces
0:15:22	I need to put this on
0:15:26	so I have interface Fast Ethernet 0/0.146
0:15:30	ip pim in dense mode
0:15:35	on Fast Ethernet 0/0.67 as well
0:15:38	so we could see once PIM is enabled, I get the logging message
0:15:42	that the neighbor adjacency is up
0:15:44	but we'll see that there can actually be cases where the
0:15:48	PIM neighbor shows up on one side of the link and not the other
0:15:52	so you do need to check the adjacency on both sides.
0:15:57	Then on Switch 1 this is going to be Fast Ethernet 3
0:16:00	ip pim dense
0:16:03	VLAN 7
0:16:06	VLAN 67
0:16:10	and VLAN 79
0:16:12	so again, even if the link is only going towards the
0:16:15	end hosts, PIM still needs to be enabled there
0:16:18	because that is what is enabling IGMP.
0:16:21	There's no separate command that says just turn IGMP on, but
0:16:24	don't turn PIM on.
0:16:33	Then on Switch 2 this is going to be on our VLAN 8
0:16:37	ip pim dense
0:16:42	VLAN 58
0:16:49	and then we have a port channel 1
0:16:52	that is going between Switch 2 Switch 4
0:16:59	so this is going where again, where the IP address is
0:17:00	assigned, not necessarily what the physical link is.
0:17:09	On Switch 3 we have interface VLAN 9
0:17:13	ip pim dense
0:17:18	VLAN 79
0:17:19	and then lastly on Switch 4, on Switch 4 this is going to be VLAN 10
0:17:25	and port channel 1
0:17:27	So now essentially PIM should be on every single interface
0:17:31	on our topology
0:17:33	since I'm additionally running IGP on every interface
0:17:36	specifically in this topology I have EIGRP enabled everywhere.
0:17:41	It should mean that once I send the multicast flows
0:17:44	out, the network is basically automatically going to figure out
0:17:47	what should the correct incoming interfaces be
0:17:51	and what are the incorrect incoming interfaces.
0:17:56	So to test this, let's say that we have a server that is
0:17:59	located on Switch 3
0:18:02	this is where the source of the traffic is going to be.
0:18:07	Then we have a receiver that is connected to Router 4's
0:18:14	LAN interface.
0:18:20	Now there's a couple different ways that we can simulate
0:18:22	the source of the multicast traffic and two different ways
0:18:26	that we can simulate the receiver of the multicast traffic.
0:18:29	Actually more than two, there's a couple other ways that we can do it as well.
0:18:32	But the -- generally the easiest way to test this
0:18:35	would be to go to
0:18:40	the segment that we want to be the receiver. In this case
0:18:43	on Router 4, this is Fast Ethernet 0/0
0:18:46	and we'll say ip igmp join group
0:18:50	and whatever particular address that we want to listen for.
0:18:53	So if we say 224.1.1.1 could be any address here.
0:18:59	Now once we do this, it means that Router 4 is
0:19:01	sending an IGMP report message saying that I'm
0:19:05	essentially an end host for that particular group.
0:19:10	If we now look at the show ip igmp membership
0:19:16	it says that on interface Fast Ethernet 0/0
0:19:19	the reporter 204.12.28.4
0:19:25	said they wanted traffic for group 224.1.1.1
0:19:34	Since the router is running IGMP version 2 by default
0:19:38	it means that this is not a source specific join.
0:19:42	This is a *,G join, not an S,G join
0:19:47	so Router 4 is saying I don't care where the traffic comes
0:19:50	from, I only care that the traffic is going to 224.1.1.1
0:19:57	so next on all of the devices, let's look at the output of
0:20:03	the show ip mroute so this is the equivalent of the
0:20:07	show ip route
0:20:09	where we are verifying the multicast routing table
0:20:13	as opposed to the unicast routing table.
0:20:15	Now if we look at Router 4 who is the device that is
0:20:19	attached to the receiver
0:20:22	so on Router 4 I went to Fast Ethernet 0/0 and said
0:20:25	ip igmp join 224.1.1.1
0:20:30	This now means that Router 4 is listening for this group address
0:20:34	to come in any possible interface, so we have the
0:20:39	*,G entry, but not yet the S,G entry.
0:20:46	Essentially what this means is that Router 4 knows about
0:20:49	a receiver, but it does not yet know about the sender.
0:20:55	Under normal circumstances for PIM dense mode and PIM
0:20:59	sparse mode, the *,G entry means that we know about
0:21:03	the receiver, but we don't yet know about the sender.
0:21:08	Only once we install the S,G entry do we know
0:21:13	about both the sender and the receiver.
0:21:20	So if we look at any of the routers let's say if we look at the
0:21:23	topology, we know that Router 1 and Router 6 are attached to Router 4
0:21:28	If we go to Router 1, notice that we do not have
0:21:32	a *,G entry for 224.1.1.1
0:21:36	and the reason why is that PIM dense mode is using
0:21:42	the implicit join mechanism.
0:21:45	So when Router 4 finds out that there's a client
0:21:47	on its segment, it's not going to tell any of the other routers about it.
0:21:52	It's going to assume that if someone has the traffic
0:21:55	for 224.1.1.1
0:21:57	it's already going to be flooded to me in the first place.
0:22:02	So now Router 4 is listening for the traffic to come in
0:22:04	any interface, but it's not telling any of the other routers
0:22:08	that I actually have the receiver.
0:22:11	So at this point, Router 4 is going to be the only
0:22:13	one who has that *,G entry installed.
0:22:18	We see we don't have it on Router 1, not on Router 2
0:22:22	Router 3
0:22:23	5, Router 6 etc.
0:22:26	so none of the other devices are going to know about that.
0:22:31	The next step is that we would have the actual sender
0:22:34	come onto the segment.
0:22:35	In our case we're going to simulate this on
0:22:38	Switch 3's VLAN 9 interface.
0:22:41	Now there's a couple different ways we could do this.
0:22:44	One of the real easy ways is just to send ICMP pings.
0:22:49	So we could ping to the multicast address 224.1.1.1
0:22:54	and we should see that throughout the PIM network
0:22:56	these packets are going to be flooded everywhere.
0:23:01	We could also tell the devices to run the IP SLA feature
0:23:05	and generate UDP echoes that are going to the particular
0:23:09	multicast address.
0:23:14	The advantage of doing the SLA is that it would be a
0:23:16	continuous feed that we could keep the UDP packets
0:23:20	being sent and then change the different conditions of the
0:23:22	network and see what the result is of the change of the forwarding.
0:23:28	So in our particular case, just for simplicity we're going to go
0:23:31	to Switch 3 and we'll just do some basic pings.
0:23:34	So on Switch 3 I'm going to do an extended ping
0:23:39	that says the address I'm going to is 224.1.1.1
0:23:44	I'll set the repeat count very high so it's going to
0:23:47	do a continuous ping.
0:23:49	I don't care how long the packet is. I don't really care
0:23:52	what the timeout is. What I do care about is what is the
0:23:56	outgoing interface
0:23:58	and what is the source address that I'm going to generate the packet from.
0:24:03	So when you're testing multicast, you need to know
0:24:05	what is the interface that you are forwarding the feed
0:24:08	out and what is the source address that it is coming from
0:24:13	because that ultimately is going to affect the reverse
0:24:15	path forwarding check for the other routers that are in
0:24:19	the topology.
0:24:22	Now if this were a real design and I have some media server
0:24:26	that's located on VLAN 9
0:24:28	if I'm trying to do a test of the network to see if
0:24:30	the traffic can actually move from VLAN 9 to BB3
0:24:36	It wouldn't make sense for me to source packets from
0:24:38	VLAN 79 which is Switch 3's normal outgoing interface
0:24:43	it would use to send the packets
0:24:47	because when the devices in the transit path receive
0:24:50	packets in from VLAN 79, it could technically be a
0:24:54	different reverse path forwarding check
0:24:57	versus packets received from VLAN 9
0:25:03	so in other words, Router 6 could have a different route to
0:25:05	VLAN 79 than it does have to VLAN 9
0:25:08	it depends on the underlying routing protocol that we're
0:25:11	using to reach the destination.
0:25:13	Maybe VLAN 9 is not even advertised into IGP
0:25:17	where VLAN 79 is, so in order to see what are the
0:25:21	other possible issues, other possible design issues
0:25:26	in the network, we need to make sure we know exactly
0:25:28	what the source is and what is the outgoing interface.
0:25:32	So from Switch 3, I want to send the traffic from
0:25:34	the address that is on VLAN 9 so this is going to be the
0:25:38	source IP, but the outgoing interface should be VLAN 79
0:25:43	so that's why I want to forward the packet out.
0:25:50	This is the interface field this is going to be VLAN 79
0:25:54	so that's the outgoing interface.
0:25:56	The source address will be 155.28.9.9
0:26:01	so that's my address on the VLAN 9
0:26:06	Now if the network is working end to end
0:26:09	where my multicast flow can go all the way to Router 4
0:26:12	and then 4 can send a unicast response
0:26:16	we should be receiving the ICMP echo reply back in
0:26:20	but ultimately this is not really a good test of multicast
0:26:24	because a normal multicast application is a unidirectional
0:26:28	flow where multicast applications are always going to use UDP
0:26:34	and they're going from the sender down to the receiver
0:26:38	without any explicit acknowledgement.
0:26:41	So if we're sending a video feed
0:26:45	we don't need for the receiving application to do any type of
0:26:48	error checking where we're asking the source to do retransmission.
0:26:53	This means that the traffic is going to go from the sender to the
0:26:55	receiver, but we don't necessarily need it to
0:26:58	go from the receiver back to the sender.
0:27:01	So we can end up in cases where by testing this with a
0:27:04	ping, if we do not get an echo reply back in
0:27:08	that's not necessarily an indication that there's a problem.
0:27:12	Really the only thing that we care about is did the packet
0:27:16	get to Router 4 and get forwarded out that particular link.
0:27:21	I don't really care if Router 4 can send an ICMP echo reply back
0:27:24	I want to make sure that the unidirectional feed
0:27:27	from VLAN 79 was able to route through whatever path the tree
0:27:32	is built and then be forwarded down to Router 4's LAN interface.
0:27:38	Now since Router 4 is now process switching this feed
0:27:42	because the IP -- again, the IP IGMP join group command
0:27:45	is going to tell the router to process switch that particular
0:27:48	destination. I should be able to go to Router 4
0:27:57	and look at the debug ip mpacket for multicast packets
0:28:02	and see the feed being received inbound
0:28:07	and then forwarded out the particular link.
0:28:12	Now notice here on Router 4 we're actually receiving it
0:28:15	we're receiving it in Fast Ethernet 0/1, but we're
0:28:19	forwarding it out multiple interfaces.
0:28:21	We're forwarding it out Fast Ethernet 0/0
0:28:25	and we're forwarding it out serial 0/0.1
0:28:28	which is this direction towards the frame relay network.
0:28:35	So this is based on basically the flooding and pruning behavior of
0:28:40	dense mode, so even though there's no clients that are
0:28:44	located on serial 0/0.1
0:28:47	for whatever reason on this particular topology,
0:28:50	that link is being used for flooding.
0:28:57	Now on Router 4 if we look at the show ip mroute
0:29:01	what we should have see that is changed
0:29:04	is now we know about who the sender is.
0:29:09	So not only do we have the *,G entry
0:29:12	but now we also have the S,G
0:29:15	Router 4 is saying that the sender
0:29:18	is 155.28.9.9
0:29:22	their traffic came in Fast Ethernet 0/1
0:29:27	The reverse path forwarding neighbor is Router 6
0:29:32	What this essentially means is that when Router 4
0:29:36	looks in the unicast routing table and
0:29:39	says how do I get to 155.28.9.9
0:29:43	we should see that the outgoing interface is
0:29:46	Fast Ethernet 0/1
0:29:48	and the RPF neighbor is Router 6
0:29:55	Now what this means from the RPF check's point of view
0:29:58	is that for a multipoint LAN interface, it's actually doing
0:30:02	two different checks, it's making sure not only
0:30:05	is Fast Ethernet 0/1 the incoming interface
0:30:10	but when I send any IGMP join message or an IGMP
0:30:15	prune or an IGMP grapht
0:30:19	or excuse me a PIM graft because it would be PIM join
0:30:22	PIM prune or PIM graft
0:30:25	I would be sending it out Fast Ethernet 0/1
0:30:28	but specifically to that individual neighbor.
0:30:33	So the PIM messages between the routers, they are
0:30:37	multicast destinations
0:30:40	but inside the actual PIM payload of the packet
0:30:44	one of the fields is the unicast address
0:30:47	of the neighbor on the link.
0:30:51	Now we'll see the implication of this is that there's certain
0:30:55	designs that can be kind of unpredictable as to
0:30:57	exactly what's going to happen with PIM where one of them
0:31:01	one of the classic design issues would be with
0:31:03	non-broadcast interfaces that if I have a sender
0:31:09	that is behind Router 2 and the receiver
0:31:14	here is on Router 4
0:31:18	this means that 2 is going to need to send the traffic
0:31:20	to 5 and 5 is going to send it back down to 4
0:31:23	so assuming there's no other transit links in the network.
0:31:26	So if the frame relay is the only physical path.
0:31:29	The packet would go from 2 to 5 from 5 to 4
0:31:34	so one of the problems is how do we deal with on Router 5
0:31:36	the packet coming in and going out the same interface.
0:31:43	The other problem is that from Router 4 as the receiver
0:31:47	when I receive the packets inbound, Router 4 would
0:31:51	say that the RPF neighbor is who?
0:32:01	Now really it depends.
0:32:02	It depends on what the underlying IGP protocol says.
0:32:07	If Router 4 says that the IGP next hop value
0:32:12	to this particular segment is Router 5
0:32:17	let's say it's the .5 address
0:32:18	that means that Router 5 is the RPF neighbor
0:32:23	and any PIM information about that particular sender
0:32:26	would be sent directly to Router 5
0:32:29	however, if the RPF neighbor is Router 2
0:32:34	it would mean that PIM information about that particular
0:32:37	group whether it's a PIM join, whether it's a PIM
0:32:40	prune or PIM graft would try to be sent directly from 4 to 2
0:32:45	and not to Router 5
0:32:51	Now the reason that this is an issue is that Router 4 and Router 2
0:32:54	they're not on the same Layer 2 network.
0:32:57	So this means that when Router 4 tries to send
0:33:01	a PIM message to Router 2
0:33:06	Even though the destination address is multicast going to
0:33:08	224.0.0.13
0:33:11	inside of the PIM packet the unicast address
0:33:16	of the neighbor on the link is encoded.
0:33:21	So Router 4 sends a packet out to frame relay
0:33:23	it's saying the destination is 224.0.0.13
0:33:26	but inside of it, it says the neighbor who is supposed to receive it
0:33:29	is 155.28.0.2
0:33:34	this would then mean when Router 5 receives this in
0:33:37	on the frame relay
0:33:40	what is Router 5 going to do with that packet?
0:33:49	Is it going to forward it out to Router 2 or is it going to ignore it?
0:34:00	Now one key about this is based on the format of the
0:34:04	address, the address is 224.0.0
0:34:08	which is significant because it's what type of address is in multicast.
0:34:19	224.0.0 is link local.
0:34:22	It means that the TTL, the Time To Live field, should be 1
0:34:27	and the packet should not be routable between different interfaces.
0:34:32	So we can end up in some strange designs here
0:34:35	that if Router 4 says that the RPF neighbor is Router 2
0:34:39	any PIM message about either trying to join a multicast tree
0:34:44	or to leave a multicast tree it's not actually going to
0:34:47	be received by Router 2
0:34:49	The message would be sent from 4 to 5
0:34:52	5 is going to drop it and then it's never going to get to 2
0:34:56	and the way that we can see this is by looking at the
0:34:58	multicast routing table
0:35:00	this is what the RPF neighbor is telling us.
0:35:04	Now for point to point links, we don't care about who the
0:35:07	RPF neighbor is because if the interface is serial 0/1/0
0:35:13	on Router 4
0:35:14	if this is our RPF interface
0:35:19	then it's implied that the RPF neighbor is the address
0:35:22	on Router 5's end of the link because that's a point to point segment.
0:35:26	If packets are coming in that interface, the only
0:35:29	possible sender is Router 5
0:35:31	but for multipoint interfaces, that's not necessarily the case.
0:35:35	When Router 4 is receiving packets in the LAN interface
0:35:39	they could be coming in from 1 or they could be coming in from 6
0:35:45	so Router 4 needs to keep track of these
0:35:48	because when I send unicast packets back to the
0:35:50	source, I may not be sending them to Router 1
0:35:54	I may be sending them to Router 6
0:35:57	so the key here is that when we are building the multicast tree
0:36:02	the RPF neighbor is the value that's going to
0:36:06	control who are we sending the PIM control plane message to.
0:36:11	In the case of dense mode PIM, this would be related to
0:36:15	either the prune message or the graft message
0:36:19	where the prune message is simply us saying that we don't
0:36:22	want the traffic anymore.
0:36:24	So normally the packet is going to be flooded out all
0:36:27	of the interfaces, any of the interfaces that we don't want to
0:36:31	receive it in, we're going to reply back with the prune message.
0:36:40	Now for interfaces that we do want the traffic to come in
0:36:45	it means that all other possible links are going to
0:36:49	be the outgoing interfaces.
0:36:53	So when the router receives the packet in, the first thing it's going to
0:36:55	do is do a reverse path forwarding check on the source.
0:37:01	Whichever feed passed the RPF check, that's now considered the
0:37:05	incoming interface.
0:37:08	So the incoming interface is always the one that's closest to the source.
0:37:12	All of the other interface that are running PIM
0:37:14	those now get inserted into the outgoing interface list or the OIL.
0:37:20	Next thing dense mode does is send the packet to all of the interfaces
0:37:24	in the outgoing interface list.
0:37:27	It's then up to the next hop router downstream
0:37:30	to figure out whether they actually want the traffic or
0:37:33	not based on if they have receivers or based on
0:37:37	if the reverse path forwarding check is either passing or failing.
0:37:42	So if the RPF check fails, the router immediately has to
0:37:45	reply back with a PIM prune message saying I do not want this traffic.
0:37:49	Only if the RPF check passes and it knows about other
0:37:53	interfaces that are running dense mode, can the router
0:37:56	continue to forward the traffic on.
0:38:03	Now in our particular topology we would be able to see this
0:38:05	in a couple different places if we were to look at the
0:38:08	debug ip pim
0:38:10	so let's say we go to Switch 1
0:38:13	and from Switch 1's perspective we know that when the packet
0:38:16	comes in VLAN 79, there's three other interfaces
0:38:20	running PIM which are VLAN 7, VLAN 67
0:38:24	and Fast Ethernet 0/3
0:38:29	that means we're going to flood packets out all three of these.
0:38:32	Now when the packets go out eventually from Router 4's
0:38:36	perspective there's only one path that we want inbound
0:38:40	and it's really going to depend on what is Router 4's
0:38:44	unicast route back to the source.
0:38:46	If the unicast route is back via Router 6
0:38:50	what we should see is that this path here is the
0:38:54	one that is using for the flooding so the actual
0:38:58	forwarding of the traffic and this one
0:39:01	is going to be the pruned path.
0:39:08	So in the case of dense mode, the tree is always a source
0:39:12	based tree.
0:39:15	The way that we are determining how to build the source based tree
0:39:18	is based on the underlying interior gateway protocol
0:39:21	or it could be static routing, technically it could be BGP
0:39:24	but the vast majority of the time, it's going to be based on IGP.
0:39:32	So let's go to Switch 3 and stop the ping from being sent.
0:39:38	Next we'll do is go to Switch 1 who is in the transit path here
0:39:41	and look at the debug ip pim.
0:39:45	And additionally on everybody here I'm going to turn off
0:39:48	time stamping.
0:39:52	So in global config no service timestamps
0:39:56	that's just going to make the output a little bit easier to read.
0:39:59	Now within the scope of the lab exam you may want to
0:40:01	turn timestamps on
0:40:04	or leave them on if they already are
0:40:06	so then when you're looking at your different debugs
0:40:08	and you're looking at your log
0:40:10	your log buffer
0:40:11	you can see what different types of stuff is happening
0:40:13	at what time of the day.
0:40:15	So maybe if you're debugging IP routing during the day
0:40:19	you could leave that being sent to the buffer
0:40:21	then when you look at the show buffer or show log
0:40:24	if there's a change in the routing table, you're going to
0:40:27	have a time reference to figure out when exactly something is going on.
0:40:29	But in my particular case, we don't need to see what the
0:40:32	the timestamps are, so on Switch 1
0:40:35	I'm saying debug ip pim
0:40:39	next step on Router 4 I'm going to join an additional group.
0:40:43	We'll say ip igmp join 224.1.1.2
0:40:50	Now again, if we were to look at the show ip mroute
0:40:53	everywhere
0:40:55	what should we see about group 224.1.1.2
0:41:09	We should see that Router 4 has the *,G entry installed
0:41:15	and everyone else has no entry installed
0:41:18	because right now Router 4 knows about the receiver
0:41:22	which in this case is the receiver is itself
0:41:25	but it does not yet know about any senders.
0:41:29	So again, if we look at on everyone
0:41:34	the show ip mroute
0:41:39	we should see that the only device that has any state information
0:41:43	about 224.1.1.2
0:41:52	is going to be Router 4
0:41:54	so Router 4 right now it does have the *,G entry
0:41:57	but nobody else has it.
0:41:59	It says the outgoing -- or the incoming interface list
0:42:01	is null, this is because we're not hearing about any senders yet.
0:42:06	The outgoing interface list so let's say show ip mroute specifically
0:42:11	224.1.1.2
0:42:15	The outgoing interface is every other possible interface that's
0:42:18	running PIM.
0:42:23	So now let's actually send the traffic, let's go to Switch 3
0:42:26	again, we'll do the extended ping
0:42:29	the traffic going to 224.1.1.2
0:42:33	send it with a high repeat count
0:42:37	extended commands yes I want this to go out VLAN 79
0:42:41	and I want it to come from 155.28.9.9
0:42:55	so what we should now see has changed
0:42:58	is that in the multicast routing table everyone in the
0:43:02	network should now know about both the *,G and the S,G entry.
0:43:10	If we look at Router 4 say show ip mroute
0:43:12	it now knows about who the sender is.
0:43:15	If we were to look at this on everyone else
0:43:18	and say show ip mroute for 224.1.1.2
0:43:25	regardless of where they are in the topology, so even
0:43:29	all the way down on Switch 4
0:43:33	everyone in the network they should now be installing
0:43:36	224.1.1.2 specifically from that source.
0:43:43	The reason why is that this traffic is being flooded everywhere.
0:43:49	Even if the devices do not want the traffic,
0:43:52	they have to install the state in the table
0:43:58	and this is one of the scalability limitations of dense mode.
0:44:01	Not only do we have to flood the actual data plane traffic
0:44:05	everywhere, so whatever the actual multicast feed is
0:44:08	everyone in the dense mode network would have a *,G
0:44:12	entry for every group and an S,G entry for every sender and group pair.
0:44:21	Now there's a question, "Why does everyone get the *,G?"
0:44:24	is that by default with dense mode or sparse mode
0:44:26	you cannot install the S,G without installing the *,G
0:44:32	so you could think of the *,G as a less specific match
0:44:35	for the particular group where like in regular IP routing
0:44:39	we would prefer the /32 route that's the longest match
0:44:42	versus some aggregate. In multicast we can think of
0:44:46	this like as the aggregate and then this is the longer match.
0:44:51	So if there's multiple overlapping matches in the multicast routing table
0:44:55	you're going to route the traffic not only based on the
0:44:57	destination group, but also what where it came from
0:45:00	so the source and the group.
0:45:05	The only time that's not going to be the case is when either we're
0:45:08	running source specific multicast or we are running bidirectional PIM
0:45:14	where SSM and bidirectional PIM they're basically the exact
0:45:17	opposites of each other.
0:45:22	Source specific multicast says that we cannot install
0:45:26	*,G entries
0:45:28	we can only install S,G entries
0:45:33	where with bidirectional PIM it says we cannot install
0:45:36	S,Gs we can only install *,G
0:45:43	So unless we're running SSM or bidirectional PIM
0:45:46	for every source that we know about, we should see both
0:45:50	the *,G and the S,G
0:45:52	Now if we look at Switch 1 who is doing the debugging here.
0:46:00	the debug ip pim we should see these messages on Switch 1
0:46:04	let's look at the show log
0:46:07	and I am logging to the console at debugging
0:46:18	let's show debug
0:46:20	we are debugging PIM I think what the issue may be
0:46:25	is that on the Catalyst IOS, we're not going to be able to
0:46:28	see the output of this debug.
0:46:30	So you'll see the switches they process multicast differently
0:46:34	because it's switched in hardware as opposed to the
0:46:37	software which is what the router does.
0:46:39	So it generally means that you're not going to be able to see as much
0:46:42	debug output, so what I'm going to need to do instead here
0:46:46	is we'll do the debugs on Router 6
0:46:49	and Router 3
0:46:51	because both of them are still going to be in the transit path
0:46:53	to get to Router 4
0:46:55	so what I want to see here is what's the difference between the
0:46:58	feed that goes to Router 3 versus the feed that goes to
0:47:01	Router 6
0:47:03	because one of them should be the feed that we're actually going to
0:47:05	use and the other one should be pruned.
0:47:09	Which one we're using is then ultimately going to depend on
0:47:11	what Router 4's unicast routing table says.
0:47:21	So next let's go back to Switch 3 and stop sending that traffic.
0:47:27	On Router 6 we'll debug ip pim
0:47:30	same thing on Router 3 debug ip pim
0:47:35	On Router 4 I will join a new group
0:47:38	let's say 224.1.1.3
0:47:41	then on Switch 1 we'll send traffic to that.
0:48:02	So we're sending traffic to 224.1.1.3
0:48:05	it's coming from 155.28.9.9
0:48:09	and it's going out VLAN 79
0:48:13	On Router 3 we see some output from the debug message.
0:48:17	It says that there was an assert message received on
0:48:20	serial 1/2 for 224.1.1.3
0:48:26	This is the specific source.
0:48:30	The assert metric to the source is 28672
0:48:36	basically this is our EIGRP metric to get back to the sender.
0:48:40	The reason that this happened it says the assert came in
0:48:45	on serial 1/2 if we look at the topology here
0:48:51	from Switch 3 the traffic goes to Switch 1
0:48:53	Switch 1 sends this to Router 6
0:48:56	6 is going to flood this out to 1 and 1 is going to flood it to 3
0:49:02	Switch 1 also sends this to 3 3 is going to flood to 1
0:49:05	so now there's a loop in the topology.
0:49:08	In dense mode, there's two things that are going to
0:49:11	prevent this, one is the reverse path forwarding check
0:49:16	that when Router 3 receives traffic in serial 1/2
0:49:20	it knows not to use that interface as the incoming interface
0:49:24	because that's not what's installed in the routing table.
0:49:27	To get back to Switch 3, Router 3 is going to route
0:49:29	this way
0:49:31	simply because the bandwidth and the delay is better
0:49:36	out the Ethernet links than it's going to be out the point to point serial.
0:49:41	So the assert message is used any time that
0:49:45	there's possible duplicate forwarding onto the LAN
0:49:51	or in this case it's a point to point link, so basically anywhere that there's
0:49:54	duplicate forwarding on the network, the routers are then going to
0:49:58	have an election to figure out who is the one that is supposed to be
0:50:03	forwarding the traffic onto that segment.
0:50:05	So only the initial packets of the feed are going to fail
0:50:09	the reverse path forwarding check, once the router
0:50:12	hears a packet coming in on interface that is in the
0:50:17	outgoing interface list, so in this specific case
0:50:21	from Router 3's perspective serial 1/2 this is in the
0:50:25	outgoing interface list.
0:50:29	Specifically Router 3 is going to say the incoming interface
0:50:32	is FA 0/0
0:50:35	The outgoing interface list includes serial 1/2
0:50:39	serial 1/3
0:50:42	serial 1/0.1 which is the link to the frame relay.
0:50:47	Since I'm now receiving the same feed in something that's in my
0:50:53	outgoing interface list, this is what triggers the assert message.
0:50:58	So now whoever has the better IGP metric to the source
0:51:02	or in the case of the tie, whoever has the higher
0:51:05	IP address, they're going to be the one that is in charge of
0:51:07	forwarding the traffic over the link.
0:51:12	So what this then implies for a PIM dense mode network
0:51:15	is the IGP metric is going to affect how the multicast
0:51:19	tree is built.
0:51:21	Whoever has the better cost
0:51:24	back to the sender, that's the device that's going to be in
0:51:27	charge of forwarding the traffic onto that particular link.
0:51:35	So we'll see later when we get into the more details about
0:51:38	building the multicast trees from the sparse mode perspective
0:51:42	this would also imply that if I were to change the IGP
0:51:45	routing, so if I were to do traffic engineering for EIGRP
0:51:49	that's going to affect my multicast traffic flows as well.
0:51:56	So there could be certain cases in the design where
0:51:58	we want the unicast flows and the multicast flows to
0:52:01	be different which in that case, we'll look at techniques
0:52:05	with the static multicast routing and with multicast
0:52:07	BGP that we could have a different path selection
0:52:11	for unicast forwarding versus the multicast forwarding.
0:52:14	But by default we're going to choose whatever is the
0:52:17	IGP metric back to the source as the assert winner onto the segment.
0:52:29	So if we look at the rest of the debug on Router 3
0:52:31	it says that we were the winner of the assert
0:52:34	because basically we had the better metric to get back to the source.
0:52:38	Now regardless, we're pruning this link
0:52:42	because whoever's on the other side
0:52:46	doesn't actually want this traffic.
0:52:48	We can see that it said serial 1/2 we're changing
0:52:52	it from pruning to forwarding which means that we're flooding the
0:52:54	traffic out the link, but eventually we're going to
0:52:58	receive the prune message back in which is
0:53:09	going to come from Router 1
0:53:13	basically to say I don't want the traffic to come in that particular interface.
0:53:16	We can see that Router 5 is doing pruning
0:53:21	and we should also be receiving it in from Router 2
0:53:26	At this point, let's go to everyone and look at the show ip mroute
0:53:31	for 224.1.1.3 this is going to tell us what are the correct
0:53:35	incoming interfaces, what are the correct outgoing interfaces
0:53:40	and whether the group is actually forwarding or whether
0:53:42	it's being pruned.
0:53:46	So Router 1 right now it says that
0:53:48	if traffic comes in Fast Ethernet 0/0 I'm forwarding it out serial 0/1
0:53:57	but I'm not forwarding it out serial 0/1
0:54:04	So when we look at Router 1 in the topology, it says the packet is
0:54:07	coming in this way.
0:54:12	But additionally it's coming in serial 0/1
0:54:17	The way that Router 1 is choosing what is the
0:54:19	incoming interface is based on what here?
0:54:31	Because we know it's coming in both links because it's being
0:54:33	flooded everywhere throughout the topology.
0:54:36	How is Router 1 choosing to use the Ethernet as
0:54:39	the incoming link as opposed to the link to Router 3
0:54:48	It's going to be based on the IGP route to the source
0:54:51	which we can see in this output is denoted by what?
0:54:56	It's based on the RPF neighbor.
0:54:59	So essentially it means that the traffic should be coming in
0:55:01	from 6 because that's our route back to the source.
0:55:05	When we look at the same output on Router 3
0:55:07	Router 3 is going to say my route to the source is
0:55:10	via Switch 1
0:55:12	so that's where my incoming interface should be.
0:55:16	Some of these links are being pruned because people
0:55:18	on the other end they don't want them.
0:55:20	Some of them are forwarding like to Router 2
0:55:23	where Router 2 is saying the incoming interface is from Router 3
0:55:29	and the outgoing interface is going to Router 5
0:55:33	Router 5 depending on its route, Router 5 says the
0:55:37	incoming interface is from Router 3
0:55:40	The outgoing interface is the other links
0:55:44	so Router 5 is saying the outgoing is here
0:55:49	and here
0:55:51	but these are both being pruned because on the other
0:55:55	end, Switch 2 doesn't want the traffic.
0:55:58	Router 4 does want the traffic, but it doesn't want it
0:56:00	in that interface.
0:56:05	So basically, based on those two principles the RPF
0:56:08	lookup and the assert message
0:56:10	PIM dense mode is eventually going to figure out where the traffic is
0:56:13	supposed to come from and where it's supposed to go to
0:56:17	but the problem is it's a really inefficient forwarding mechanism
0:56:20	because again, not only is the traffic flooded everywhere in the network
0:56:24	all the devices in the topology they need to maintain the S,G state.
0:56:31	So as long as this source is active, every single router in the
0:56:35	PIM network is going to have to put it into the multicast routing table.
0:56:40	So one of the potential issues when you look at the security
0:56:44	of multicast networks is that if you don't protect against
0:56:48	who are the valid sources in the topology
0:56:51	you could essentially do a denial of service attack
0:56:54	against the control plane just by sending packets
0:56:58	in from random source addresses
0:57:00	or sending it to random destination addresses.
0:57:03	So let's say for example that I were to go to
0:57:07	some host that's connected to Router 5's LAN
0:57:11	if I send just single ping packets, it's only one packet
0:57:16	is going to need to do this, if I send it to every possible
0:57:20	multicast destination, what's going to happen to the network.
0:57:31	When Router 5 gets that in, it's going to have to flood it
0:57:33	everywhere, what are all the routers in the transit path going to do then?
0:57:40	They're going to have to install the separate S,G entries
0:57:45	for every single destination that I send the traffic to.
0:57:49	So we may potentially be talking about millions and millions of routes
0:57:52	so eventually the multicast routing table is going to get too big
0:57:56	and unless we set some limit on it, then we could end up in
0:58:01	memory allocation errors and the router is going to crash.
0:58:05	So typically in a real design you do want to make sure that
0:58:09	there are protection mechanisms against the control plane
0:58:12	so that the multicast routing table doesn't get too large
0:58:15	and if you already know exactly who your sources are
0:58:19	you would protect the network to say this guy is allowed to
0:58:22	send, but nobody else is
0:58:25	or this device is allowed to be the rendezvous point and no one else is.
0:58:31	In the case of dense mode this is a little bit harder to implement
0:58:34	we'll look at with sparse mode since the design is more flexible
0:58:37	it's a lot easier to control the security of who are the senders
0:58:41	who are the receivers, who are the rendezvous points
0:58:44	and then who are the routers that are valid for telling us who
0:58:48	the sources are in the network.
0:59:00	So additionally with dense mode we have one other message that
0:59:03	we care about which is known as the dense mode graft
0:59:07	which is essentially an un-prune message
0:59:10	from downstream going to upstream.
0:59:15	So from Switch 3's perspective right now, we are still sending traffic
0:59:18	towards that particular destination
0:59:21	which is 224.1.1.3
0:59:26	and when we look at Router 5
0:59:30	right now Router 5 says that this particular group
0:59:33	is pruned from my LAN interface
0:59:36	because Router 5 knows that right now
0:59:38	there's no one who is actually reachable out this link that wants the traffic.
0:59:44	So now the potential issue is that if someone actually comes
0:59:47	onto this segment and sends an IGMP join
0:59:51	there's going to be a bunch of latency as we're waiting for
0:59:53	the network to re-flood before that client can actually
0:59:58	receive the traffic.
1:00:01	So in dense mode to fix this
1:00:04	this is what the graft message is for
1:00:06	and it's technically not the same as a join because
1:00:09	a join is for PIM sparse mode. Basically the graft
1:00:13	is an un-prune saying that previously I had sent you a prune message for
1:00:18	this particular group, but now I have some client that
1:00:23	wants to receive it, so I'm going to tell you to stop
1:00:25	pruning my link and start flooding the traffic to me.
1:00:29	Where we would see this specifically if we were to
1:00:31	go to Router 5 and look at the debug ip pim
1:00:39	debug ip pim
1:00:50	then go down to Switch 4 and we'll use Switch 4 to
1:00:54	simulate a new client
1:00:57	so on Switch 4 is VLAN 10 interface we'll say ip igmp
1:01:01	join 224.1.1.3
1:01:04	what we should see is that Router 5 receives a graft
1:01:08	message saying essentially that Fast Ethernet 0/0
1:01:13	it needs to be un-pruned for the destination
1:01:17	224.1.1.3
1:01:21	Now if we look at the show ip mroute
1:01:24	we should see that Fast Ethernet 0/0 has been
1:01:26	updated to the forward state
1:01:29	where the other link serial 0/1/0 this is
1:01:32	still in the pruning state as it goes out to Router 4
1:01:37	So overall again, in the scheme of things, there's
1:01:40	not really that much complex design that goes into dense mode
1:01:44	the key is to understand first off how the adjacency happens
1:01:48	which is the same as it would be for sparse mode.
1:01:51	So we're using PIM going to 224.0.0.13
1:01:54	that's to figure out who are the neighbors to begin with.
1:01:57	Once we establish the adjacencies, then we flood the traffic everywhere.
1:02:01	For any links that are not wanted, those are going to be pruned.
1:02:06	If we happen to do want to un-prune the links
1:02:11	this is what the graft message is for
1:02:14	if we want to continue pruning, there's a message that is
1:02:17	the state refresh
1:02:19	which is essentially the device that's connected to the
1:02:21	source sends a state refresh out to say basically do you guys
1:02:29	still want these links to be pruned
1:02:31	instead of actually flooding the data feeds.
1:02:35	So the idea behind this is to optimize the flooding and pruning.
1:02:40	The problem is it's still not going to fix the problem with the
1:02:42	S,G entries
1:02:45	having to have their state installed in the routing table.
1:02:49	So in the dense mode network, it doesn't matter where you are in the
1:02:52	topology, you're always going to have all *,Gs and S,Gs
1:02:56	installed in your table for every particular sender that there is.

Now Viewing

CCIE Routing & Switching Advanced Technologies Class
Title:	CCIE Routing & Switching Advanced Technologies Class
Duration:	81h 59m
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!
$159/month	Add to Cart
Download this Course
$299.00	Add to Cart

PIM Dense Mode

Create Bookmark