Posts from ‘IP Multicast’
Today launches the first of many of our new INE Video Blog series. Our first video covers the advanced design issues with running Multicast and Auto-RP over NBMA networks such as Frame-Relay Hub-and-Spoke. Specifically this video focuses on possible solutions such as sparse-dense mode, sparse-mode with auto-rp listener, sparse-mode with a default RP placement, and PIM Join issues related to point-to-point vs multipoint interfaces and their underlying IGP protocols.
In this short article we’ll take a look at Cisco IOS static multicast routes (mroutes) and the way they are used for RPF information selection. Multicast routing using PIM is not based on propagation of any type of multicast routes – the process that was used say, in DVMRP. Instead, router performs RPF checks based on the contents of unicast routing table, populated by regular routing protocols. The RPF checks could be classified as either data-plane or control-plane. Data-plane RPF check applies when router receives a multicast packet, to validate if the interface and upstream neighbor sending the packet match RPF information. For data-plane multicast, the packet must be received from an active PIM neighbor on the interface that is on the shortest path to the packet source IP address, or RPF check would fail. Control-plane RPF check is performed when originating/receiving control-plane messages, such as sending PIM Join or receiving MSDP SA message. For example, PIM needs to know where to send the Join message for a particular (S,G) or (*,G) tree, and this is done based on RPF lookup for the source IP or RP address. Effectively for PIM, RPF check influences the actual multicast path selection in the “reversed way”: it carves the route that PIM Join message would take and thus affects the tree construction. In both control and data-plane RPF check cases, the process is similar, and based on looking through all available RPF sources.
I recently received an email from a student with a question about an example I did in our multicast bootcamp. After an hour into testing and drafting my email response, I realized this commonly misunderstood multicast design would make a great blog writeup! The original question is as follows:
I am a customer of INE and bought the multicast bootcamp. Maybe I missed some important note, but I am confused related to the issue mentioned below. I am following the test bed you have shown in the presentation while describing the theory of sparse mode (Day 1 – Part 6) in which you have explained the RP Register, Join and SPT-Join.
Suppose the two trees are established, and traffic is flowing from the source to RP, and then RP to receiver. Also suppose that SPT-Join is disabled (e.g. threshold is infinity), and traffic always follows the shared trees.
Suppose that the multicast traffic flow is initiated from the source to the RP as follows:
R2 –> R4 –> R3 (RP)
Then traffic flows from the RP to receiver:
R3 –> R4 –>R5
When multicast traffic is coming from the RP on R4, will RPF check fail? I assume so, since multicast traffic is entering the interface in which RPF will be failed. Is there any other rule to follow if traffic is coming from RP?
After working with the December 2010 London Bootcamp on Multicast for the better part of Day 4 in our 12-day bootcamp, I returned to the hotel to find the following post on my Facebook page – “Multicast is EVIL!”
Why do so many students feel this way about this particular technology? I think one of the biggest challenges is that troubleshooting Multicast definitely reminds us of just what an “art” solving network issues can become. And speaking of troubleshooting, in the Version 4 Routing and Switching exam, we may have to contend with fixing problems beyond the scope of our own “self-induced” variety. This is, of course, thanks to the initial 2 hour Troubleshooting section which may indeed include Multicast-related Trouble Tickets.
Your very best defense against any issues in the lab exam regarding this technology – the new 3-Day Multicast technology bootcamp. Also, be sure to enjoy the latest free vSeminar from Brian McGahan – Troubleshooting IP Multicast Routing.
INE is proud to announce the release of our Multicast Class-on-Demand! Taught by myself, this 15-hour Class-on-Demand series covers IPv4 and IPv6 Multicast Routing on Cisco IOS, including both technology lectures and hands-on CLI examples. More information on the Multicast Class-on-Demand can be found here.
To celebrate the release of this new Class-on-Demand, I will be running a free vSeminar on Troubleshooting IP Multicast Routing this Thursday, October 14th, at 10:00 am PDT (17:00 GMT). This free seminar will run about an hour long, and will cover CLI examples of how to troubleshoot common IP Multicast problems, including RPF failure and the use of static multicast routes & mtrace. For those unable to attend, this vSeminar will be available in recorded Class-on-Demand format at a later date. The url to attend is http://ieclass.internetworkexpert.com/tshootipmulticast/
Click here to register for notifications about new upcoming vSeminars.
Hope to see you there!
When we ask students “what are your weakest areas” or “what are your biggest areas of concern” for the CCIE Lab Exam, we typically always here non-core topics like Multicast, Security, QoS, BGP, etc. As such, INE has responded with a series of bootcamps focused on these disciplines.
The IPv4/IPv6 Multicast 3-Day live, online bootcamp, and the associated Class On-Demand version seeks to address the often confounding subject of Multicast. Detailed coverage of Multicast topics for the following certifications is provided:
Cisco Certified Network Professional (CCNP)
Cisco Certified Design Associate (CCDA)
Cisco Certified Design Professional (CCDP)
Cisco Certified Design Expert (CCDE)
Cisco Certified Internetwork Expert Routing & Switching (CCIE R&S)
Cisco Certified Internetwork Expert Service Provider (CCIE Service Provider)
Cisco Certified Internetwork Expert Security (CCIE Security)
To purchase the live and on-demand versions of the course for just an amazing $295 – just click here. The live course runs 11 AM to 6 PM EST US on September 29,30, and October 1.
The preliminary course outline is as follows:
- Module 1 Introduction to Multicast
Lesson 1 The Need for Multicast
Lesson 2 Multicast Traffic Characteristics and Behavior
Lesson 3 Multicast Addressing
Lesson 4 IGMP
Lesson 5 Protocol Independent Multicast
- Module 2 IGMP
Lesson 1 IGMP Version 1
Lesson 2 IGMP Version 2
Lesson 3 IGMP Version 3
Lesson 4 CGMP
Lesson 5 IGMP Snooping
Lesson 6 IGMP Optimization
Lesson 7 IGMP Security
Lesson 8 Advanced IGMP Mechanisms
This publication illustrates some common techniques for troubleshooting multicast issues in IP networks. Common problems and their causes are discussed, troubleshooting techniques demonstrated. PIM Sparse mode is used for most of the examples, due to the fact that this is the most complicated mode of multicast signaling. The suggested troubleshooting approach separates control plane from data-plane troubleshooting and heavily relies on the mroute command for the control-plane verification. This publication requires solid understanding of intra-domain multicast routing technologies.
Common Reasons for Multicast Problems
In short, one common reason for all issues with multicast routing is the PIM and logical/physical topology incongruence. Ideally, multicast should be deployed in a single IGP domain with PIM enabled on all links running the IGP with all links preferably being point-to-point or broadcast multiple-access. If you have multicast running across the domain that has multiple IGPs, or you don not have PIM enabled on all links or finally you have NBMA links in the topology – you have open possibilities for a problem. Unfortunately, the “problem” conditions just described are very common in the CCIE lab exam environment.
The most common type of multicast issue is the RPF Failure. RPF checks are used both at the control and data plane of multicast routing. Control plane involves PIM signaling – some PIM messages are subject to RPF checks. For example, PIM (*,G) Joins are sent toward the shortest path to RP. Next, the BSR/RP address in the BSR messages is subject to RPF check as well. Notice that this logic does not apply to PIM Register messages – the unicast register packet may arrive on any interface. However, RPF check is performed on the encapsulated multicast source to construct the SPT toward the multicast source.
Data plane RPF checks are performed every time a multicast data packet is received for forwarding. The source IP address in the packet should be reachable via the receiving interface, or the packet is going to be dropped. Theoretically, with PIM Sparse-Mode RPF checks at the control plane level should preclude and eliminate the data-plane RPF failures, but data-plane RPF failures are common during the moments of IGP re-convergence and on multipoint non-broadcast interfaces.
PIM Dense Mode is different from SM in the sense that data-plane operations preclude control-plane signaling. One typical “irresolvable” RPF problem with PIM Dense mode is known as “split-horizon” forwarding, where packet received on one interface, should be forwarded back out of the same interface in the hub-and-spoke topology. The same problem may occur with PIM Sparse mode, but this type of signaling allows for treating the NBMA interface as a collection of point-to-point links by the virtue of PIM NBMA mode.
A pretty important topic that is very easy to overlook when studying multicast is the PIM Assert Mechanism. After working with the TechEdit Team in the IEOC it is obvious that more than just a handful of students are confused about what this mechanism does and how it works. In this blog post (the first of many dedicated to multicasting), we will examine the PIM Assert mechanism and put this topic behind us in our preparation in mastering multicast.
In Figure 1, R1 and R4 have a route to the source 188.8.131.52 (the multicast source), and share a multi-access connection to R6. R6’s FastEthernet0/0 interface has joined the multicast group 184.108.40.206.
I am updating Practice Exam 2 (In Progress) for the CCIE Written Exam Bootcamp in your Members’s Site. I will be adding questions over the next couple of weeks. Currently, you will find some new Multicast Addressing/IGMP/MLD questions in there for your entertainment.
I am focusing on Practice Exam 2 right now for two main reasons. 1) It is allowing me to address some deficiencies with Practice Exam 1 and the lectures, and 2) More and more students are using this bootcamp as a prep tool for the dreaded Core Knowledge section.
Let us examine one of the new questions and walk through my solution logic.
Q. How does a router respond after receiving an IGMP Leave Group message?
a. The router does nothing
b. The router responds with a Membership Report
c. The router responds with a Group Specific Query
d. The router responds with a General Query
Per our release schedule, the “Multicast” section of IEWB-RS VOL1 has been posted on the members site. IEWB-RS VOL1 is a collection of advanced technology-focused labs with detailed breakdowns and verifications, aimed to provide you with in-depth understanding of every networking technology needed to pass the CCIE lab. The new section is more than 150 pages in size. Here is the list of the topics covered:
PIM Dense Mode
Multicast RPF Failure
PIM Sparse Mode
PIM Sparse-Dense Mode
PIM Accept RP
PIM DR Election
PIM Accept Register
PIM NBMA Mode
Auto-RP – Multiple Candidate RPs
Auto-RP – Filtering Candidate RPs
Auto-RP and RP/MA Placement
Filtering Auto-RP Messages
PIM Bootstrap Router
BSR – Multiple RP Candidates
Filtering BSR Messages
Stub Multicast Routing & IGMP Helper
Multicast Helper Map
Multicast Rate Limiting
Source Specific Multicast
Multicast BGP Extension
Catalyst IGMP Snooping
Catalyst Multicast VLAN Registration
Catalyst IGMP Profiles
You may find a sample lab from the section posted on this blog at Understanding BSR Protocol. The remaining “BGP” section of IEWB-RS VOL1 in being updated and should be posted soon as well.