Posts from ‘IP Multicast’
Multicast – PIM Assert Mechanism
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 150.1.5.5 (the multicast source), and share a multi-access connection to R6. R6’s FastEthernet0/0 interface has joined the multicast group 239.6.6.6.
Figure 1
Hello everyone!
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
Hi Everyone,
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 Assert
PIM Accept RP
PIM DR Election
PIM Accept Register
Multicast Tunneling
PIM NBMA Mode
Auto-RP
Auto-RP – Multiple Candidate RPs
Auto-RP – Filtering Candidate RPs
Auto-RP Listener
Auto-RP and RP/MA Placement
Filtering Auto-RP Messages
Multicast Boundary
PIM Bootstrap Router
BSR – Multiple RP Candidates
Filtering BSR Messages
Stub Multicast Routing & IGMP Helper
IGMP Filtering
IGMP Timers
Multicast Helper Map
Multicast Rate Limiting
Bidirectional PIM
Source Specific Multicast
DVMRP Interoperability
Multicast BGP Extension
MSDP
Anycast RP
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.
This post is an excerpt from the Multicast section of IEWB-RS VOL1 v5.0. The section itself should be posted a in few hours. Based on the workbook flow, the reader is assumed to have basic understanding of Auto-RP protocol prior to reading this section.
Bootstrap router or BSR is standard-based protocol available with PIMv2. The protocol performs the same function as Cisco’s proprietary Auto-RP, i.e. disseminates RP information. Both protocols use the concept of candidate RP, i.e the router that is announcing itself as a potential RP. Unlike Auto-RP, BSR does not use any dense-mode groups to flood candidate RP and RP mapping information. Instead, the information is flooded using PIM messages, on hop-by-hop basis. The flooding procedure utilizes reverse path forwarding: when a router receives a BSR message, it applies RPF check, based on the source IP address in the packet. If the RPF check succeeds, the message is flooded out of all PIM-enabled interfaces until all routers in the domain learn the information.
To set up a candidate RP in Cisco IOS, use the command ip pim rp-candidate
Continue Reading
Part 2 – The Arrival
Andrew Spruce emerged from the fourth floor elevator and checked the sign ahead for his room number.
He had taken the advice of many of his peers and he was in Raleigh, North Carolina two full days prior to his lab attempt. The plan was to study for the remainder of the evening, and then have a relaxing, casual, non-study kind of day tomorrow.
Today’s session of the CCIE R&S Open Lecture Series will be open for guest access, and will start at 1pm US Pacific time (GMT -8). Just follow this url to join: http://ieclass.internetworkexpert.com/r94413397/
Today’s session will last about 3 – 4 hours and will cover Advanced IP Multicast Design topics, focusing on identifying and troubleshooting problems with PIM, Auto-RP, NBMA networks, and shared (RPT) versus source (SPT) distribution trees.
I hope to see you all there!
In this post we will quickly discuss the use of most commonly needed IGMP timers. First, as we know, multicast routers periodically query hosts on a segment. If there are two or more routers sharing the same segment, the one with the lowest IP address is the IGMP querier (per IGMPv2 election procedure – as you remember, IGMPv1 let the multicast routing protocol define the querier).
For those of you that didn’t get the original invite there’s a free vSeminar on Troubleshooting IP Multicast starting right now via WebEx. The session will run about 2 hours and is starting now, 1:10pm Pacific time. You can login by clicking here. If you’re unable to attend make sure to check the schedule for upcoming seminars in the future.
Thanks!
Hi Brian,
I have a problem with the multicast helper topic, the case when a broadcast network is separated by a multicast network, and then again it continues. Can you discuss this topic?
Thanks,
Nizami
Hi Nizami,
The multicast helper-map command is similar in theory to how the unicast “ip helper-map” works. With the IP helper map feature, IP broadcast packets, such as UDP based DHCP requests, have their destination addresses translated to a unicast address, such as the DHCP server. With the IP multicast helper map feature, IP broadcast packets have their destination addresses translated to a multicast address.
The common design application of this feature is in financial trading networks where a legacy stock ticker application sends packets out as broadcast UDP. The router on the attached segment can then convert the broadcast destination to multicast, send the packet into the multicast transit network, and then on the last hop router attached to the receiver translate the multicast packet back to a broadcast. This allows the network to scale above a flat layer 2 design where all application senders and receivers are in the same IP subnet, to a hierarchical layer 3 routed multicast network, without the application itself being modified.
Configuration-wise the feature is implemented on two devices, the first hop router attached to the broadcast sender, and the last hop router attached to the broadcast receiver. The first hop router listens for broadcast packets to be received on the incoming interface attached to the sender. Based on an access-list match (usually the UDP port of the application), the router translates the destination address to a user defined multicast address, and forwards the packet out interfaces running PIM according to the multicast routing table. This design therefore assumes that the underlying PIM topology is built end-to-end. Once the last hop router receives the traffic on the incoming interface facing the multicast network, the traffic is again categorized by an access-list, and additionally by the multicast group used on the first hop. Based on the directed broadcast address defined on the last hop router the traffic is then dropped off on the LAN segment facing the receiver.
In our particular design the network looks like this:
SW1 — R4 -– R3 — R2 — R1 — SW2
SW1 is the broadcast sender (i.e. the source application), SW2 is the receiver (i.e. the destination application), R4 is the first hop router, and R1 is the last hop router. IGP and PIM adjacencies exist between R4 – R3, R3 – R2, and R2 – R1.
R4’s configuration, the first hop router, looks as follows:
R4# interface FastEthernet0/0 description TO SENDER APPLICATION – SW1 ip address 173.20.47.4 255.255.255.0 ip multicast helper-map broadcast 224.1.2.3 100 ! ip forward-protocol udp 31337 access-list 100 permit udp any any eq 31337
This configuration means that if R4 receives a UDP broadcast going to port 31337 inbound on Fa0/0 it will be translated to the multicast address 224.1.2.3. Note that the use of the “ip forward-protocol” command is necessary in order to process switch UDP traffic going to the port in question. Without process switching the helper-map feature can not correctly categorize and translate the traffic.
R1’s configuration, the last hop router, looks as follows:
R1# interface Serial0/0.102 point-to-point description TO R2 ip address 173.20.12.1 255.255.255.0 ip pim dense-mode ip multicast helper-map 224.1.2.3 173.20.18.255 100 frame-relay interface-dlci 102 ! interface FastEthernet0/0 description TO RECEIVER – SW2 ip address 173.20.18.1 255.255.255.0 ip directed-broadcast ! ip forward-protocol udp 31337 access-list 100 permit udp any any eq 31337
This configuration means that if R1 receives a UDP multicast going to the group address 224.1.2.3 at port 31337 inbound on S0/0.102 it will be translated to the directed broadcast address 173.20.18.255. Since the link 173.20.18.0/24 is directly connected and has the directed broadcast address of 173.20.18.255 by default, the configuration implies that traffic matching the helper map on S0/0.102 will be sent as a broadcast out Fa0/0.
Note the use of the “ip forward-protocol” command as before in order to process switch the UDP traffic. Additionally the “ip directed-broadcast” command is enabled on the last hop outgoing interface since in current IOS versions this is disabled by default for security purposes.
To verify the functionality of this feature we can use the IP SLA feature in the IOS to generate broadcast UDP traffic on the sender. This configuration on SW1 is as follows:
rtr 1 type udpEcho dest-ipaddr 255.255.255.255 dest-port 31337 source-ipaddr 173.20.47.7 source-port 12345 control disable timeout 0 frequency 5 rtr schedule 1 life forever start-time now
This config means that SW1 will generate a UDP packet sourced from the address 173.20.47.7 at port 12345 going to the address 255.255.255.255 at port 31337 every 5 seconds, and will not wait for a response back. The following debug on R4, the first hop router, verifies that the packet is received and is translated into multicast.
Rack20R4#debug ip packet detail
IP packet debugging is on (detailed)
IP: s=173.20.47.7 (FastEthernet0/0), d=255.255.255.255, len 44, rcvd 2
UDP src=12345, dst=31337
Rack20R4#undebug all
All possible debugging has been turned off
Rack20R4#debug ip mpacket
IP multicast packets debugging is on
IP(0): s=173.20.47.7 (FastEthernet0/0) d=224.1.2.3 (Serial0/0) id=0, ttl=254, prot=17, len=44(44), mforward
Rack20R4#undebug all
All possible debugging has been turned off
From the unicast “debug ip packet detail” we can see the packet is received in Fa0/0 from SW2 with the proper destination and port information. Next the multicast “debug ip mpacket” shows us that the packet has been translated to multicast address 224.1.2.3 and is forwarded out Serial0/0 towards R3.
As R4, R3, R2, and R1 receive the multicast packet the multicast routing table is populated as follows.
Rack20R4#show ip mroute 224.1.2.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.2.3), 01:24:42/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Dense, 01:24:42/00:00:00
(173.20.47.7, 224.1.2.3), 00:01:27/00:02:58, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Dense, 00:01:27/00:00:00
Rack20R3#show ip mroute 224.1.2.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.2.3), 01:25:36/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/1.312, Forward/Dense, 01:25:36/00:00:00
Serial1/0, Forward/Dense, 01:25:36/00:00:00
(173.20.47.7, 224.1.2.3), 00:02:22/00:02:54, flags: T
Incoming interface: Serial1/0, RPF nbr 173.20.0.4
Outgoing interface list:
Serial1/1.312, Forward/Dense, 00:02:23/00:00:00
Rack20R2#show ip mroute 224.1.2.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.2.3), 01:25:27/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0.213, Forward/Dense, 01:25:27/00:00:00
Serial0/0.201, Forward/Dense, 01:25:27/00:00:00
(173.20.47.7, 224.1.2.3), 00:02:12/00:02:54, flags: T
Incoming interface: Serial0/0.213, RPF nbr 173.20.23.3
Outgoing interface list:
Serial0/0.201, Forward/Dense, 00:02:13/00:00:00
Rack20R1#show ip mroute 224.1.2.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.2.3), 01:25:42/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0.102, Forward/Dense, 01:25:42/00:00:00
(173.20.47.7, 224.1.2.3), 00:02:27/00:02:57, flags: PLTX
Incoming interface: Serial0/0.102, RPF nbr 173.20.12.2
Outgoing interface list: Null
Once the packet is received on R1, the last hop router, the “debug ip mpacket” shows the packet coming in as multicast, while the “debug ip packet detail” shows that the packet being converted back into a broadcast. This is also verified by the “debug ip packet” output on SW2, the receiver of the packet.
Rack20R1#debug ip mpacket IP multicast packets debugging is on IP(0): s=173.20.47.7 (Serial0/0.102) d=224.1.2.3 id=0, ttl=251, prot=17, len=48(44), mroute olist null Rack20R1#undebug all All possible debugging has been turned off Rack20R1#debug ip packet detail IP packet debugging is on (detailed) IP: tableid=0, s=173.20.47.7 (Serial0/0.102), d=173.20.18.255 (FastEthernet0/0), routed via RIB Rack20R1#undebug all All possible debugging has been turned off Rack20SW2#debug ip packet IP packet debugging is on IP: s=173.20.47.7 (Vlan18), d=255.255.255.255, len 44, rcvd 2 IP: s=173.20.47.7 (Vlan18), d=255.255.255.255, len 44, stop process pak for forus packet Rack20SW2#undebug all All possible debugging has been turned off
This feature can also be used in the opposite manner, where a multicast packet is received, converted to broadcast, and then converted back to multicast. In either case the configuration depends on the design and functionality of the source and destination application.
Tags: broadcast, helper-map, multicast, pim
Brian,
When I use the debug ip mpacket command I’m not getting any output. Any idea why?
First off it’s important to understand that multicast traffic is fast switched with the exception of interfaces using X.25 encapsulation. Since the multicast traffic is fast switched it will not be sent to the processor which in turn means the debug will not “see” the multicast packets. You need to disable fast switching for multicast traffic under the interfaces where the multicast traffic will transit. You can do this by using the “no ip mroute-cache” interface level command.
The exception to this is when the router has an IGMP join configured (ip igmp join-group) for a particular group. Multicast traffic destined for the joined group will be process switched and in turn the debug will be able to “see” these packets.
Loading ...
