CCIE R&S Advanced Technologies Class v4.5 - Bootstrap Router (BSR), Bidirectional PIM, Source Specific Multicast (SSM)

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:13	In our next section for multicast, we're going to look at the alternative
0:00:16	way to advertise dynamic rendezvous point information
0:00:19	with bootstrap router and then when we get into
0:00:22	IPv6 multicast, we'll also see that we support BSR for advertisement
0:00:27	of the dynamic information where auto RP is not implemented
0:00:31	in IPv6 since it is currently considered a legacy mechanism
0:00:35	of the advertisement since it's not part of the standardized
0:00:38	PIM version 2 specification.
0:00:40	Now again, BSR is essentially going to accomplish the same
0:00:45	functional goals as auto RP but behind the scenes and
0:00:49	looking at the protocol format, it's a little bit different than how
0:00:52	auto RP works.
0:00:54	In general this is much easier to apply to the design
0:00:58	since BSR is inside of the PIM version 2 packet itself
0:01:03	and we're assuming that all of the routers that are directly
0:01:05	connected RPM adjacent, we should therefore be able to exchange
0:01:09	the rendezvous point information without any of the hacks that we had
0:01:13	for auto RP.
0:01:16	Now we have two roles in the BSR domain similar to
0:01:19	auto RP, we have the RP candidate and we have the
0:01:22	bootstrap router
0:01:23	where the RP candidate is similar to the candidate RP
0:01:27	in auto RP, this is the device that is advertising
0:01:30	itself as the rendezvous point
0:01:34	but instead of using multicast in the data plane to exchange this information
0:01:38	it is going to send unicast PIM messages to the bootstrap router.
0:01:45	So this means that we first need to figure out who is the
0:01:48	bootstrap router, so whoever the RP candidates are can then
0:01:52	advertise themselves to the RP or to the BSR.
0:01:58	So the BSR is similar to the mapping agent in auto RP
0:02:01	this is going to be advertised on a hop by hop basis inside
0:02:05	of the PIM packet itself.
0:02:08	Now configuration wise, if we look at the configuration
0:02:11	guide for multicast, again the vast majority of the stuff
0:02:15	within the scope of routing and switching is simply going to
0:02:17	be in this first document under the multicast configuration guide
0:02:21	which is configuring basic IP multicast routing.
0:02:25	So if we look at the BSR configuration example
0:02:28	versus the auto RP configuration
0:02:36	the general logic of the syntax is pretty similar
0:02:41	where we're specifying instead of the RP discovery
0:02:47	which is for the mapping agent we're saying BSR
0:02:49	candidate, then we're saying ip pim rp candidate instead of
0:02:53	send rp announce.
0:02:56	Just like in auto RP we could do this on a per
0:02:59	group basis if we want a different candidate RPs
0:03:02	to be assigned to different groups to give us load balancing and to give us
0:03:05	redundancy and we also can have multiple BSRs.
0:03:11	So if we were to look at our configuration that we
0:03:13	currently have on Router 2 who is both the mapping agent
0:03:19	and the candidate RP if we show run include
0:03:25	pim
0:03:30	we have the send rp announce and the send rp discovery.
0:03:33	Now with BSR again, we do not need the ip pim auto RP listener
0:03:37	because the BSR information is going to be advertised
0:03:40	inside the PIM packet itself this means that we do not need
0:03:44	sparse dense mode and we do not need auto RP listener.
0:03:47	So we can run every single group in sparse mode
0:03:52	without worrying about the advertisements for BSR not getting
0:03:55	through, so on Router 2 I'm going to remove the ip pim
0:03:59	send rp announce
0:04:02	and remove the ip pim send rp discovery.
0:04:04	Additionally that tunnel that I had before to Router 5
0:04:08	I'm going to shut that down, that's no longer going to be
0:04:11	needed for the multicast routing.
0:04:15	So on Router 5 I'll shut this down as well.
0:04:19	Now on Router 2 we're going to advertise ourselves as the
0:04:21	BSR and as the RP candidate.
0:04:24	We'll say ip pim rp candidate.
0:04:31	Source address that we're using to advertise. We could also
0:04:34	specify how often we're advertising this, what is
0:04:37	our group to RP mapping list. If there are multiple
0:04:41	RP candidates, we can configure a priority value.
0:04:47	So this type of stuff you don't need to memorize as long as
0:04:50	you try it out once or twice and you know where it's located
0:04:52	in the command reference, it doesn't matter if we memorize
0:04:55	whether the higher priority value is better or the lower
0:04:58	priority value is better because I know we can just
0:05:00	go to the documentation, go to the IP multicast command reference
0:05:07	then this would be under the IP PIM
0:05:12	command. IP PIM
0:05:14	RP candidate
0:05:19	It says the priority value optional specifies the priority of
0:05:22	the candidate RP range is from 0 to 225, default to 0
0:05:25	and the BSR with the lower priority is preferred.
0:05:30	So if everyone is 0, then they're equal up to that point.
0:05:34	If we wanted to prefer one over the other, we basically have to
0:05:36	raise the ones that we do not want to be the RP candidate.
0:05:49	Next we'll specify what is the BSR candidate
0:05:52	I'll use the same loopback 0
0:05:57	This hash mask length for the RP selection
0:06:01	this is if we're trying to do load balancing between them
0:06:04	between different rendezvous points
0:06:06	if then you were to look at the command reference for
0:06:09	IP PIM BSR candidate
0:06:14	it says the hash length mask is length of a mask in 32 bits
0:06:18	that is to be ANDed with the group address before the
0:06:22	PIMv2 hash function is called
0:06:24	all groups with the same seed hash correspond to the same
0:06:26	rendezvous point for example if this value is 24, only the first
0:06:30	24 bits of the group address matter. The hash length
0:06:36	mask allows one RP to be used for multiple groups.
0:06:39	The default hash mask length is 0, so basically it means that
0:06:44	on a per RP basis by default you're allowed to use all groups.
0:06:50	So if we were to modify this, then this is ultimately going to
0:06:53	control what particular groups are mapped to that individual
0:06:55	rendezvous point.
0:07:00	So now if we were to look at the other routers in the topology
0:07:02	after we're advertising this, verification would be the same
0:07:06	we would want to say show ip pim rp mapping
0:07:11	and ideally we should see in all of the routers
0:07:15	even the ones that had to have the message go in Router 5's
0:07:18	interface and then back out, we should see Router 2
0:07:21	as the bootstrap router.
0:07:24	So Router 2 sees itself, Router 3 and 4 do not
0:07:28	yet, Router 5 does
0:07:30	6 does not
0:07:32	Switch 1 does not
0:07:36	Switch 2 let's show ip pim rp mapping
0:07:45	Switch 2 does
0:07:48	Switch 3 does not and Switch 4 does.
0:08:16	So it looks like we have the same possible situation as
0:08:20	before where the devices that are beyond Router 5
0:08:25	so let's look back at the diagram here.
0:08:28	So Router 2 right now is the rendezvous point
0:08:31	it's also the BSR.
0:08:35	These messages are being advertised to five
0:08:38	five is then getting them down to Switch 2 and
0:08:40	to Switch 4, but it doesn't look like yet it's getting
0:08:44	to 4, 1 and 3
0:08:47	and additionally I have the link between 2 and 3 disabled and the
0:08:50	link between 4 and 5 disabled.
0:08:54	So let's check one more time to see if this is just a
0:08:56	convergence issue
0:08:58	and it's not.
0:08:59	Ok, so on the spokes next thing we would want to look at
0:09:02	is inside the PIM debug am I actually receiving
0:09:06	the BSR advertisement.
0:09:08	So let's look at the debug ip pim
0:09:11	bsr
0:09:15	and let's look at this on all of the routers. So at this
0:09:18	point on Router 2 it might make sense to speed up the
0:09:21	convergence by setting the interval to be lower
0:09:27	so depending on what the default advertisement interval is, we might be
0:09:30	sitting here for a couple minutes waiting for it to actually show up in the output.
0:09:36	So Router 2 says it's building its candidate RP advertisement
0:09:42	bootstrap message for our loopback is originated.
0:09:45	So five should get this it says it's being forwarded on
0:09:48	Fast Ethernet 0/0 and it's being forwarded on
0:09:52	Fast Ethernet 0/1
0:09:54	so it's the same type of split horizon type problem
0:09:58	where the packet is not allowed to come in the interface
0:10:02	and then be advertised back out.
0:10:06	Now if we were to change this where Router 5 was the
0:10:09	BSR or some other placement in the network that we don't have
0:10:13	this type of Layer 2 transport problem
0:10:17	then it should not be an issue.
0:10:19	So on Router 5 on the loopback let's say ip pim sparse
0:10:23	then we'll advertise ourself as the BSR
0:10:33	If we look at the show ip pim rp mapping now
0:10:36	we can see now Router 1 is learning about both
0:10:39	five and two
0:10:42	because the candidate RP is being advertised
0:10:47	to us via Router 5
0:10:49	so notice now there's a difference between who
0:10:52	is the rendezvous point and who is the information source.
0:10:55	The issue is that the BSR message is not allowed to
0:10:58	come in on Router 5's interface and then go back out the same link.
0:11:02	So it's not necessarily a multicast problem per se
0:11:07	it's more of a Layer 2 design issue
0:11:09	that if the frame relay network was fixed
0:11:11	to be point to point subnets, then we would never have this problem
0:11:14	to begin with
0:11:16	so we could again do the workaround with the tunnel
0:11:19	between Router 2 and Router 5, but then ultimately
0:11:23	when we get to the data plane, we're still going to
0:11:24	have that problem where if there's an actual receiver
0:11:28	that is located on Router 2's LAN segment, so if the
0:11:33	IGMP client is here, there's going to be problems when
0:11:37	the sender goes from 4 to 5 and then 5 tries to
0:11:41	send it back to Router 2
0:11:43	so that packet is going to be dropped.
0:11:46	So again, the simple design solution here is simply to fix
0:11:49	frame relay. We could do the tunnel as a workaround
0:11:53	or we could move where the BSR and the RP candidate is located.
0:12:01	Now the vast majority of the other features that are
0:12:04	related to multicast within the scope of routing and switching
0:12:07	are mainly going to be just minor switches that we're
0:12:11	changing on top of the PIM that we've already covered up to this point.
0:12:15	So if you're very comfortable with the step by step procedure
0:12:20	of how PIM sparse mode works differently than dense mode
0:12:26	where in sparse mode first we need to figure out who is
0:12:29	the rendezvous point to register our sources with them
0:12:34	then the clients are going to send the join messages up towards the
0:12:37	RP, RP is then going to build the two trees where we're building
0:12:40	the shortest path tree from the RP back to the source
0:12:45	and we're building the shared tree from the receivers up to
0:12:48	the rendezvous point.
0:12:50	So in normal sparse mode we're going to have two
0:12:53	separate trees, one that goes from the receiver to the RP
0:12:55	second one that goes from the RP back to the source.
0:12:59	Now the potential issue with this is that it means that
0:13:03	for everyone in the transit path we have both the
0:13:06	*,G entry and the S,G entry
0:13:09	and in the case that the multicast application that we're
0:13:13	using is a many to many application
0:13:17	which it means that the sender is both the receiver
0:13:20	at the same time, then normal sparse mode is generally
0:13:23	not good for this.
0:13:25	So the typical real world design case that this is, is for financial
0:13:30	trading applications when they are receiving the
0:13:34	trades in from the other end hosts, but then also sending their
0:13:38	local data out, so they're both the multicast client and
0:13:42	the multicast server at the same time.
0:13:46	So this is what bidirectional PIM is designed to solve
0:13:49	the cases that there are too many S,G entries in the
0:13:52	routing table because we're essentially installing one
0:13:56	on a per host basis.
0:13:58	So if we have a 100 thousand end hosts that are doing the
0:14:01	trading application would mean that we'd have to have
0:14:04	a 100 thousand routes in the multicast routing table.
0:14:08	So bidirectional PIM solves this simply by stopping the installation
0:14:12	of the S,G entries
0:14:15	and only allowing the installation of the *,G entries.
0:14:20	Now when we do this, it also means that we're going to
0:14:22	change the reverse path forwarding rules
0:14:27	and there's two pretty good references for multicast
0:14:30	if you want to get some more information about these
0:14:33	advanced topics. One of them is the Cisco press
0:14:38	book on multicast that is I think it's developing IP
0:14:44	multicast networks. This one is pretty good, it is a little bit
0:14:48	dated, you can see it's from 1999, but there haven't been
0:14:51	real large changes in PIM dense and sparse mode since then
0:14:56	a lot of the stuff is the same.
0:14:59	Another one that is good is the interdomain multicast
0:15:05	routing with...
0:15:12	Interdomain multicast routing practical juniper networks and
0:15:15	Cisco system solutions. Now this one mainly talks about some
0:15:18	of the larger scale multicast designs like the MSDP
0:15:23	and the multicast BGP, but it does have a really good
0:15:26	introductory section about PIM in sparse mode.
0:15:30	I'm not a 100 percent sure if this book is on Safari
0:15:33	but if you're confused about multicast or you just want to get
0:15:37	more information about it, then I would definitely recommend
0:15:40	to take a look at this one.
0:15:44	Now configuration wise for a lot of these features like
0:15:47	bidirectional PIM or source specific multicast,
0:15:49	the syntax is very very simple.
0:15:56	And if we were to look at the configuration guide for this
0:16:00	under configuring basic IP multicast -- actually I think bidirectional
0:16:05	PIM is in a different document. It would be optimizing PIM sparse
0:16:12	mode in large IP multicast deployments.
0:16:21	It should be this one let's see.
0:16:28	No maybe it's still the first document.
0:16:37	Ok, it is under that first one that's the configuring basic
0:16:40	IP multicast routing.
0:16:41	But if you read through this document, there's some...
0:16:47	I believe they go through some diagrams here they do here, so
0:16:50	the difference in the building of the trees
0:16:52	with bidirectional PIM versus regular sparse mode or for
0:16:58	dense mode
0:17:00	where in the case of bidirectional PIM, you can go
0:17:04	both up and down the tree at the same time
0:17:06	because you're always forwarding based on the *,G
0:17:11	you're not installing any of the S,G entries, but implementation
0:17:14	wise when you look at the configuration here, it's basically
0:17:17	only two commands, so you specify that the
0:17:23	that bidirectional PIM is on, so you say globally
0:17:26	ip pim bidir-enable
0:17:30	then you specify what rendezvous point you're using
0:17:34	and if they support bidirectional groups.
0:17:39	So just these two commands and also you could do the bidirectional
0:17:42	advertisement either through auto RP or through BSR
0:17:51	but the key is the design difference of bidirectional is
0:17:54	that it's designed to not install the S,G entries
0:17:57	to make the routing table more scalable.
0:18:00	Now again, this would be the exact opposite of source
0:18:02	specific multicast that says you cannot install the *,Gs
0:18:08	you only must install the S,Gs
0:18:12	which means that you're never using the shared
0:18:16	tree or the rendezvous point tree. You are only using the
0:18:20	shortest path tree.
0:18:23	Now again, the implication of source specific multicast
0:18:28	is that the actual receivers need some sort of out of band
0:18:32	method to figure out who are the sources of the strings.
0:18:38	So in the case of applications like IPTV, that information would be
0:18:43	built into the application itself that's used to send the
0:18:46	traffic from the media server down to the client
0:18:50	where they're going to know if I want to change the channel
0:18:52	on my TV what particular media server that I'm supposed to send that to.
0:18:57	Now technically the RFC says that the range 232.0.0.0/8
0:19:02	is reserved for source specific multicast.
0:19:05	Implementation wise, you can tell the IOS to use whatever
0:19:09	range that you want, but again configuration for this
0:19:13	similar to bidirectional PIM is just going to be a couple commands.
0:19:17	So if we look at the source specific -- configuring source specific
0:19:20	multicast
0:19:23	SSM configuration examples
0:19:28	at the link level since we need to receive the S,G
0:19:32	join from the client
0:19:35	we need to say ip igmp version 3
0:19:38	because again, IOS runs version 2 by default.
0:19:44	Then the ip pim ssm default command
0:19:47	what this means is that you're using the default
0:19:49	range for source specific multicast which is
0:19:52	232.0.0.0/8
0:19:57	so in our particular design
0:19:59	if we wanted to configure this
0:20:02	the only thing that we would need to do is
0:20:04	tell the routers globally since we're already running
0:20:07	multicast routing and we're already running PIM in sparse mode
0:20:10	if we say ip pim ssm default
0:20:14	ssm default
0:20:17	this means we're using the range 232.0.0.0/8
0:20:24	then when we go to join a group with IGMP signaling
0:20:29	let's say we were to do this on Switch 3
0:20:32	VLAN 9
0:20:34	we'll say ip igmp join
0:20:37	232.0.0.1 and this version doesn't support it because the
0:20:44	the Catalyst IOS is older. Let's say this would be
0:20:47	on... Let's say on Router 4's Fast Ethernet 0/0
0:20:54	Router 4 we'll say ip igmp join
0:20:58	232.0.0.1
0:21:01	but specifically for this source.
0:21:04	So we'll say for the source 155.28.9.9
0:21:13	so now if I were to go to switch 2 and ping the address
0:21:18	232
0:21:20	232.0.0.1
0:21:26	this is going out my VLAN 58
0:21:29	coming from 155.28.8.8
0:21:36	We should see that Router 4 is not going to receive this traffic
0:21:40	because it has joined from the source 155.28.9.9
0:21:49	Now if we go to Switch 3 and do the same thing
0:21:51	we'll ping 232.0.0.1
0:21:57	this is going out VLAN 67
0:22:01	or not 67, this should be VLAN 79
0:22:06	79 and it's 155.28.9.9
0:22:15	we see that that traffic is getting to Router 4 because
0:22:18	it joined specifically from that one source.
0:22:23	Now if we look at the difference here
0:22:27	in the multicast routing table and we show ip mroute
0:22:30	what we should notice about that particular
0:22:33	group that is 232.0.0.1
0:22:37	is that it is only going to be installed in the devices
0:22:41	that are in the shortest path tree
0:22:46	from Switch 3 down to the destination.
0:22:49	And actually I need to keep sending packets because I only sent one.
0:22:53	I'll say ping 232.0.0.1 with a higher repeat count
0:23:00	going out VLAN 79 from 155.28.9.9
0:23:16	If we now look at the show ip mroute
0:23:22	Router 1 says that this is lower case s which is a
0:23:26	source specific multicast group
0:23:29	right now we are not forwarding the traffic because we are not
0:23:34	in the transit path for this. If we were to look at Router 6
0:23:37	who should be in that path
0:23:39	show ip mroute 232.0.0.1
0:23:44	it says it's coming in from Switch 1, it's going out to Router 4
0:23:49	but notice the difference here we don't have a *,G entry.
0:23:55	So there's only the exact match based on the S,G
0:24:00	we don't have a less specific match that we could fall back to
0:24:02	if the traffic was not coming from that particular source.
0:24:07	So it essentially means that the traffic that Switch 2 is sending
0:24:12	is getting dropped as soon as it is received from the
0:24:16	first hop router on its LAN.
0:24:21	It's only when someone actually builds the tree
0:24:24	back to that sender is the traffic going to flow.
0:24:27	Now we could see this on Router 4 if we were to add that additional source
0:24:31	if I said the source should also include 8.8
0:24:34	we should see that this is going to update
0:24:38	so now Switch 2 is getting the response back from Router 4
0:25:00	Ok, there's a question here, "Earlier you showed on your
0:25:03	blog about when the RP is skipped through the traffic flow
0:25:06	if you configure bidirectional PIM, will it still skip through the
0:25:10	RP as you showed on the blog?" Actually in bidirectional PIM
0:25:14	it will not. Now one of the differences between them
0:25:18	is that since we do not have the S,G entries
0:25:25	it means that we have no way to register the sources
0:25:28	with the rendezvous point.
0:25:32	So in normal PIM sparse mode when we hear about a new sender
0:25:35	in the network, we're going to tell the rendezvous point about
0:25:38	this by sending them a unicast register basically saying
0:25:41	I now know about this new S,G entry.
0:25:45	But in bidirectional PIM we're removing the ability to
0:25:47	install the S,G entries
0:25:51	so it means that we have no way to signal the rendezvous point
0:25:55	that that particular sender is now active in the network.
0:25:59	So the only solution to this is to constantly send the
0:26:03	traffic in the data plane up to the rendezvous point.
0:26:08	So even if there are no receivers, the rendezvous point
0:26:11	in bidirectional PIM is always going to be receiving the traffic.
0:26:16	Now we could see this in a quick example if we were to say
0:26:18	that Router 5 is the rendezvous point
0:26:22	and right now I already have it configured that way through
0:26:25	BSR, so Router 5 is advertising itself with BSR.
0:26:30	Let's say that we change its BSR advertisement
0:26:33	so that it is advertising itself as a bidirectional rendezvous point
0:26:39	the only thing we would need to do in order to enable that
0:26:43	would be to go to
0:26:46	essentially all the routers in global config
0:26:49	and say ip pim bidirectional-enable
0:26:58	so this should turn bidirectional PIM on.
0:27:04	Now additionally on Router 2 I want to remove the
0:27:08	previous BSR advertisements I was doing here
0:27:11	because I want to make sure that this is not overlapping.
0:27:20	So Router 2 is no longer the RP candidates, no longer the BSR candidate.
0:27:24	For Router 5's configuration similar to this, if we show run
0:27:28	include pim
0:27:33	For the RP candidate advertisement
0:27:36	if we say ip pim rp candidate loopback 0
0:27:40	this is a bidirectional rendezvous point.
0:27:45	Now what can be kind of confusing about this
0:27:47	is that the bidirectional keyword, it doesn't actually
0:27:51	show up until you turn bidirectional on globally.
0:27:59	So until I actually said ip pim bidir-enable
0:28:04	this argument would not show up in the context sensitive help.
0:28:12	But now let's look at this in the topology. Now previously
0:28:15	we looked at examples where Switch 3 was sending traffic
0:28:19	out into the network
0:28:21	and Router 1 was the rendezvous point.
0:28:24	When this occurred, Switch 1 who is the basically the
0:28:29	designated router here sent a registration message to
0:28:32	Router 1 to tell it about that particular source and group.
0:28:38	Router 1 then replied with the register stop
0:28:41	saying I now know that you told me about that particular source.
0:28:48	Now until we actually had receivers in the network
0:28:51	the only two devices that knew about the S,G
0:28:54	were Switch 1 who is the designated router
0:28:58	and Router 1 who is the rendezvous point.
0:29:02	But now in bidirectional PIM we have no way to signal
0:29:05	to the rendezvous point that there is a sender in the network.
0:29:10	So let's look at what happens when Switch 3 starts to send
0:29:13	traffic basically to any destination
0:29:17	and Router 5 is the rendezvous point that is advertising itself
0:29:21	as bidirectional.
0:29:35	So on Switch 3 I also need to say ip pim bidirectional enable
0:29:39	if we look at the show ip pim rp mapping
0:29:45	we should see that Router 5 is the rendezvous point and
0:29:47	it is a bidirectional rendezvous point.
0:29:53	On Switch 3 if I now send the ping
0:29:56	we'll say go to any address here we'll say 230.30.30.30
0:30:04	give it a high repeat count
0:30:06	this is going to come out my interface VLAN 79
0:30:14	and I'll source it from 155.28.9.9
0:30:26	so right now we have a sender, but we have no receivers.
0:30:31	From everywhere else in the network if we were to look at
0:30:33	the
0:30:37	show ip mroute for 230.30.30.30
0:30:48	Router 1 says it does know about the S,G state
0:30:53	where this is a bidirectional group for the rendezvous point
0:30:55	155.28.0.5
0:31:00	Router 2 does not know about that because it's not in the
0:31:02	transit path.
0:31:04	Router 3 likewise is not in the transit path.
0:31:07	Router 4 is
0:31:10	as is Router 5 because Router 5 is the rendezvous point.
0:31:14	Router 6, Switch 1 is in the transit path
0:31:19	Switch 2 is not going to be
0:31:21	Switch 4 is not going to be likewise, but
0:31:24	if I now were to go to Router 5 and look at the
0:31:27	debug ip mpacket
0:31:31	we should see that these pings that are being originated by
0:31:35	Switch 3, they're always going to be received
0:31:38	on Router 5
0:31:41	so if we say no ip mroute cache
0:31:46	and depending on what particular link that they're coming in
0:31:57	we should see that these are constantly going to be received, so
0:31:59	if we look at the show ip mroute count
0:32:05	we should see for 230.30.30.30
0:32:09	it says that the packets have been received.
0:32:13	If we look at the counter, eventually these are going to
0:32:15	keep going up
0:32:17	even though we do not have any receivers.
0:32:22	So the key point here being that since there's no way to
0:32:25	signal the rendezvous point who is sending
0:32:28	you simply basically always need to flood the traffic to the RP.
0:32:34	So it's an optimization of the control plane in the expense
0:32:39	of the less optimal data plane.
0:32:41	But if we have tons of senders and receivers, then maybe
0:32:46	it doesn't even matter that the traffic is always going up to the
0:32:48	RP, we just need to make sure that we don't have a 100 thousand
0:32:52	entries in the routing table.
0:32:54	Now if we were to tell someone to join
0:32:58	let's say we were to go to Router -- let's say Router 3
0:33:05	and on Router 3's LAN interface we'll join this group
0:33:13	on Fast Ethernet 0/0 ip igmp join 230.30.30.30
0:33:32	On Router 3 if we look at the debug ip mpacket
0:33:38	let's go to these interfaces and say no ip mroute cache
0:33:46	and we're still going to have the problem though of
0:33:49	forwarding in and out the same interface
0:33:55	so it's kind of a bad example to have Router 5 as the
0:33:58	RP here. The issue is that if the packets are being
0:34:03	forwarded this direction
0:34:07	then they're not going to be able to go back out the same link.
0:34:11	Now one way I could fix this would be to change the
0:34:14	underlying EIGRP routing
0:34:16	so let's say I were to go to Router 1
0:34:19	and if we go to Router 1 and look at what is my route to get to
0:34:23	150.28.5.5
0:34:27	because this is the RP.
0:34:29	Ok, right now I'm going directly over that frame relay interface.
0:34:33	But if I were to say from EIGRP's perspective
0:34:37	that basically this is the worst possible delay
0:34:40	Let's say the metric is just really high on this interface
0:34:44	and then Router 4 were to say the same thing
0:34:48	that we don't want to forward out that link because it's got
0:34:51	a really high delay.
0:34:54	What I essentially need to do -- let's say clear ip eigrp neighbors
0:34:59	is I need to try to get the traffic to come in on
0:35:05	Router 5's point to point link to Router 4
0:35:09	which might be shut down right now. Let's look at the
0:35:14	show ip interface brief, it is shut down.
0:35:17	So let me bring that interface up and the end result should be
0:35:22	that if I were to look at like Switch 1 who is in the transit path
0:35:26	tracing to Router 5 I want to get this to go over the
0:35:29	point to point link to Router 5
0:35:32	which now it is, so it should be OK for the traffic to
0:35:35	go basically this way
0:35:44	and if we now look at Router 3
0:35:46	it says the packets are coming in Fast Ethernet 0/0
0:35:58	so Switch 3 did get some of the packets to Router 3
0:36:03	now they're being dropped. Let's look at on
0:36:07	let's look at basic everyone else in the transit path let's look at the
0:36:10	debug ip packet or debug ip mpacket and see if we can
0:36:14	figure out where these are going, so on Router 6 let's
0:36:17	say show run include interface or mroute
0:36:26	so I need to say on my LAN interfaces
0:36:29	no ip mroute cache
0:36:33	Fast Ethernet 0/0.146 no ip mroute cache
0:36:40	There's a question here, "Would NBMA mode solve this?"
0:36:44	Actually it would solve it because the group is running
0:36:48	in sparse mode, so from Router 5's perspective when
0:36:53	we show ip mroute for 230.30.30.30
0:36:58	bidirectional PIM -- actually I'm not
0:37:00	a 100 percent sure if it's going to work for bidirectional PIM
0:37:03	because it's treated differently than a normal sparse group.
0:37:11	So it says the outgoing interface this is where we would forward now.
0:37:23	If it would work, the only thing you would need to do is say
0:37:25	ip pim nbma mode on Router 5
0:37:32	so let's see now on Router 6 let's look at the debug ip mpacket
0:37:46	and let's try this with a new group on
0:37:49	Switch 3 let's just do a regular ping let's say ping
0:37:53	230.1.1.1
0:38:00	then on Router 5 if we see that this is coming in
0:38:03	it's coming in serial 0/1/0
0:38:09	Right now the outgoing interface list is null because there's no
0:38:11	receivers. If I then were to say on Router 3
0:38:16	ip igmp join 230.1.1.1
0:38:22	Router 5 should receive these in serial 1/0
0:38:28	and then forward it down to Router 3
0:38:35	so what I didn't actually check first was if
0:38:40	everyone knew that Router 5 was the bidirectional rendezvous point
0:38:44	but if we look at Router 5 now notice that these are
0:38:47	still coming in serial 0/1/0
0:38:52	and Router 3 is receiving them in where?
0:38:58	-- receiving on Fast Ethernet 0/0
0:39:01	so the key is that the tree is built a little bit differently
0:39:05	than the normal PIM shared tree or the shortest
0:39:08	path tree because what's happening is that
0:39:11	Switch 3 sends the packet this way
0:39:14	Router 3 sent the PIM join message to Switch 1
0:39:18	so Switch 1 is able to send the feed this way and then
0:39:23	also up towards the rendezvous point
0:39:25	so this is why it's considered bidirectional.
0:39:29	So along the way up to the RP, we can drop the feed
0:39:32	off at those local interfaces. It doesn't necessarily have to
0:39:36	go all the way to them and then back
0:39:40	but the key is that since there's no registration process, Router 5 is
0:39:44	always going to receive this traffic.
0:39:55	So again, these type of minor features, the bidirectional
0:39:58	PIM, the source specific multicast as long as you
0:40:01	read through the configuration guides for them, you can try out
0:40:04	the examples just once or twice that if you needed to
0:40:07	reference this in the exam, you should be able to figure it out
0:40:09	pretty much verbatim from the examples that they're giving you
0:40:12	in the configuration guide.

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

Bootstrap Router (BSR), Bidirectional PIM, So...

Create Bookmark