cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6326
Views
20
Helpful
4
Replies

Multicast joining process for OSPF

nimalrajphilips
Level 1
Level 1

Hello there,

As all know, OSPF uses 224.0.0.5 and 224.0.0.6 for DB updates. Once the OSPF n/w is converged, the 'show ip interface' command shows the multicast group the router has joined.

My question is, when ospf is enabled on a interface, will the router join the multicast groups of 224.0.0.5 and/or 224.0.0.6 as normal IGMP joining process? When i tried varios debug commands (debug ip ospf packets, debug ip ospf events, debug ip igmp), it doesnt show the IGMP joining process of router to the multicast address. It only shows the hello packets sent to 224.0.0.5 once the network is converged.

So, how this joining is heppening?

Note: I tried this in GNS3. Not sure whether the results relies on how GNS3 interprets the hardware platform.

Nimalraj

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Nimalraj,

You have a great question at hand!

To add to Jon's great answer, joining a multicast group is a multi-step process in an operating system. First, your IP stack must be instructed to accept packets addressed to the intended multicast IP address, and consequently, the network card must be also instructed to accept frames destined to the appropriate related multicast MAC address. This is done internally in an operating system as soon as an application subscribes to a multicast group. IGMP is not yet involved in this process, but after this stage has been completed, if the multicast arrived at your network card, it would be accepted and processed.

IGMP comes on top of all this, after the IP stack and NIC are set up to accept the multicast packets/frames, to advertise your willingness to receive that particular multicast group stream to a gateway so it knows it has receivers connected. Note that IGMP is not used to enable a station to receive multicast streams but rather to advertise it is already ready and waiting to receive them.

Most multicast applications operating in link-local address scope 224.0.0.0/24 including routing protocols do not subscribe into their multicast groups via IGMP. To be technically precise, it is not necessary, because link-local multicasts are never forwarded beyond a router, so it is not that useful to subscribe via IGMP to a multicast group whose traffic can only be originated on the local segment and can never be routed to you from behind a router. That is why you never see OSPF, EIGRP, RIPv2, VRRP, HSRP, GLBP, LDP, PIM, etc. subscribing to their groups via IGMP, because it is not really necessary.

If you are aware of IGMP Snooping on switches then you know that without receiving IGMP join messages, IGMP Snooping can not work, and would in fact prevent the routers from seeing each other in OSPF, for example. This is the reason that on Catalyst switches, the entire MAC address range 01:00:5E:00:00:xx into which the 224.0.0.0/24 directly maps is exempted from IGMP Snooping, and is always flooded.

Best regards,

Peter

View solution in original post

4 Replies 4

Jon Marshall
Hall of Fame
Hall of Fame

Nimalraj

I have never debugged it but i doubt you would see any routing protocol that uses multicast actually sending IGMP requests because there is no need. The specific multicast addresses used by OSPF are in the 224.0.0.x range which are link local ie. they are never routed between subnets.  In addition this particular range is always flooded to every port in the vlan and IGMP snooping does not filter them.

So because they are never routed and because even at L2 with IGMP snooping they are still not filtered ie. they are sent to every port in the vlan the multicast messages will always be seen by every router connnected to that LAN segment and so there is no need to use IGMP.

Jon

Peter Paluch
Cisco Employee
Cisco Employee

Hello Nimalraj,

You have a great question at hand!

To add to Jon's great answer, joining a multicast group is a multi-step process in an operating system. First, your IP stack must be instructed to accept packets addressed to the intended multicast IP address, and consequently, the network card must be also instructed to accept frames destined to the appropriate related multicast MAC address. This is done internally in an operating system as soon as an application subscribes to a multicast group. IGMP is not yet involved in this process, but after this stage has been completed, if the multicast arrived at your network card, it would be accepted and processed.

IGMP comes on top of all this, after the IP stack and NIC are set up to accept the multicast packets/frames, to advertise your willingness to receive that particular multicast group stream to a gateway so it knows it has receivers connected. Note that IGMP is not used to enable a station to receive multicast streams but rather to advertise it is already ready and waiting to receive them.

Most multicast applications operating in link-local address scope 224.0.0.0/24 including routing protocols do not subscribe into their multicast groups via IGMP. To be technically precise, it is not necessary, because link-local multicasts are never forwarded beyond a router, so it is not that useful to subscribe via IGMP to a multicast group whose traffic can only be originated on the local segment and can never be routed to you from behind a router. That is why you never see OSPF, EIGRP, RIPv2, VRRP, HSRP, GLBP, LDP, PIM, etc. subscribing to their groups via IGMP, because it is not really necessary.

If you are aware of IGMP Snooping on switches then you know that without receiving IGMP join messages, IGMP Snooping can not work, and would in fact prevent the routers from seeing each other in OSPF, for example. This is the reason that on Catalyst switches, the entire MAC address range 01:00:5E:00:00:xx into which the 224.0.0.0/24 directly maps is exempted from IGMP Snooping, and is always flooded.

Best regards,

Peter

Hello Pete, That was a wonderful explanation. Thanks alot.

Great explanation Peter. Very good query Nirmalraj. 

Review Cisco Networking products for a $25 gift card