This topic is to discuss the following lesson:
Hi Rene,
I think this topics should be also put in CCIE R/S since its on CCIE blue printer, not only under written…just a suggestion
Hello Samer
Thanks for the suggestion! @ReneMolenaar will take a look and when he gets a chance.
Thanks again!
Laz
Hi Rene
I really confuse about this, since R1 connected to R2 via internet, so MSDP can establish peering through global network which not enable multicast routing like internet ? and can we send multicast traffic from one site to one site through internet without using VPN ?
Sovandara
Thank you
Hello Heng
The important thing to note here is that multicast mechanisms are not being employed over the Internet itself. MSDP allows for two edge routers to share multicast information such that multicast traffic can be sent between them. Such multicast traffic is sent using PIM Sparse Mode, which means that multicast traffic traversing the internet is sent to the RP that is at the edge of the other autonomous system and is being used as the specific “next hop” of the multicast traffic. Remember, the RP knows about all the sources and receivers for any particular multicast group.
Note that no intervening routers on the Internet are employing multicast mechanisms.
More about MSDP can be found here:
I hope this has been helpful!
Laz
Hello René,
Great work, thank you.
I had a problem with your ACL that match also the source address deny ip 192.168.0.0 0.0.255.255 any, with this entry the filter will not work because the source is using 192.168.0.0/24 segment. could you confirm that please ?
regards,
Hello Zouhair
You don’t necessarily have to choose to filter all private addresses, you can filter only some, whichever ones you choose. Typically MSDP is used on a network where you have multiple LANs connected to each other through private WANs. It is over that private WAN that you would want to filter out some addresses, possibly the ones that you wouldn’t want to send over the WAN for purposes of saving bandwidth.
So although the example uses the private address space, it would not necessarily be so in a production network.
I hope this has been helpful!
Laz
I consider this an unimportant remark, but possibly still slightly mentionworthy:
From https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
“The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. Multicast routers should not forward any multicast datagram with destination addresses in this range, regardless of its TTL.”
Currently, I don’t know how to conjure up examples as to why this should not be filtered. If so, I’d like it to see examples mentioned.
Thank you for your article @René’s crew (including René, naturally).
Hello Sven
This range of multicast addresses 224.0.0.0/24 is called the local network control block. As suggested in the text you shared, it is non-routable and used for routing protocols and other control plane protocols. Indeed, OSPF uses the 224.0.0.5 and 224.0.0.6 addresses for its operation, and RIP uses 224.0.0.9, all of which are within this multicast range.
The statement “Multicast routers should not forward any multicast datagram with destination addresses in this range” simply means that routing devices must not and will not route this traffic. So traffic destined to any address within 224.0.0.0/24 will, by definition, remain within the subnet/network segment within which it originated, and will never be routed outside of that segment.
This is simply a declaration of how such traffic behaves, and that all routing devices must conform to this. You don’t actually have to filter such traffic, it is automatically done. Does that make sense?
You can find out more (including links) at the following NetworkLessons Notes page on the topic.
I hope this has been helpful!
Laz
1 Like
Hallo Laz,
na klar macht das Sinn. / Of course, that makes sense.
I just didn’t know that routers have this implicit behaviour coded in (similar to private network ranges). (Or: I got stuck on “should” in the IANA’s declaration.)
What does that mean for me?: “Ask yourself for possible implicit behaviour.”
(You have satisfied my curiosity.)
Dank u wel (also, for the reference onto this part of your pages).
1 Like
Hello, everyone.
When we are running MSDP, what IP address should our sources use? Rene says that we might want to filter those that use private IPs, so should multicast sources be assigned public IPs, then?
Also, what multicast groups should we use for Inter-AS? Rene again states that multicast groups in the administrative 239.0.0.0/8 range could be filtered.
Thank you
David
Hello David
What Rene is advocating here is not a general rule that states “filter private addresses.” Rather, MSDP is often used to exchange source-active information between multicast domains, sometimes across AS or administrative boundaries. In those cases, you normally do not want to advertise internal-only multicast state to remote MSDP peers.
For inter-domain multicast to work, the multicast source address must be reachable through unicast routing from the remote multicast domain. So if this is a public inter-AS design, the source would normally need to use a globally routable unicast IP address. If the source uses an RFC1918/private address, the remote domain will usually not be able to build a valid path back toward that source, unless this is a private/controlled environment where both sides intentionally route those private addresses.
So filtering SA messages for private source addresses is mainly a policy and reachability issue. It prevents leaking internal infrastructure information and avoids advertising sources that remote domains cannot realistically reach.
You would normally use globally scoped multicast group addresses, except for the link local range (224.0.0.0/24), which is not routable, and the administratively scoped range (239.0.0.0/8). These are the ranges that should not cross administrative boundaries and should thus be filtered between MSDP peers.
I hope this has been helpful!
Laz