RIP Multicast vs Broadcast

Unanswered Question
Feb 19th, 2009

1) In all books it is mentioned that one improvement of RIPv2 versus RIPv1 is the usage of multicast instead of broadcast, leading to a reduced network traffic.

In my view, the network traffic remains the same, it does not get reduced when switching from broadcast to multicast, so are the books wrong?

2) To understand that max hop count of 15 (fifteen) in case of RIP, does it mean that it implies max 16 (sixteen) routers in chain?

Ex: If Host A is connected to router R1, R1 to R2, then R2 to R3 and so on till R15 is connected to R16 and finally the Server B is connected to R16.

With RIP in place will Host A be able to connect to Server B ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Richard Burts Thu, 02/19/2009 - 19:11


Perhaps the books should be more careful about how they express this concept. On one hand you are quite correct that the amount of network traffic (how many packets) stays the same whether it is broadcast or multicast.

On the other hand the books are correct that the impact of the traffic is less when the RIP updates are sent as multicast. In RIPv1 where the updates are broadcast every host on the subnet (including every PC and every server as well as every router) receives the broadcast and must process it up the stack to see what to do with it. All the PCs and servers will discard the update because they are not running RIP. But every host had to expend processing cycles to determine that the packet should be discarded. With RIPv2 where the updates are sent as multicast only the routers process the packet up their stack. Every PC and every server that is not running RIP will ignore the multicast because they have not joined the multicast group for RIP. So the impact on PCs and servers is less when running RIPv2.



badalam_nt Fri, 02/20/2009 - 02:05

Thanks Rick.

Just to go on a bit with this discussion, also my understanding is that avoiding flooding RIP updates to PCs could be done as well with RIPv1 by setting "passive-interface". Would that broadcast & passive-interface be the same as having multicast?

And about the 2nd question, what is the max nb or routers in a chain in case of RIP: 16 or 15 ?

Richard Burts Fri, 02/20/2009 - 04:33


The combination of broadcast and passive-interface is quite different from having multicast. While it is technically correct to say that configuring passive-interface will lessen the impact of broadcast, it does this by supressing the sending of the broadcast. So the PCs on that segment will not be interrupted by the broadcast, but any router on that segment will get NO updates. Passive interface is appropriate only on segments where there are only PCs. If there is a router on the segment that you want to participate in the routing protocol then you need to not configure passive-interface.

15 is the max. When the advertised hop count is greater than 15 the destination becomes unreachable.



badalam_nt Fri, 02/20/2009 - 08:42

Just a remark:

I've just performed a test and with 16 routers, each running RIP, put in chain between the Host A and Host B, ping worked between the 2 hosts.

As regards to multicast, how does a PC proceed when it receives such a frame:

is the NIC that decodes the destination MAC address of the frame, sees that it is a multicast address and then discard it ? Is the decision to discard the multicast packet taken at L2 or at L3 or etc?

Joseph W. Doherty Fri, 02/20/2009 - 17:04

That depends on both the capabilities of the NIC and how the host has configured it. For instance, a NIC in promiscuous mode would pass all packets. A NIC that can filter Ethernet multicast would only accept frames for an Ethernet multicast address that it has been configured to accept (which include a small address block of IP multicast).

In other words, the NIC at L2 may, or may not accept a frame. If the frame is accepted, it's passed to the network stack which will determine whether to accept or reject. For instance, a multicast L2 might be rejected but since L2 Ethernet multicast includes multiple IP multicast, an accepted L2 frame could be rejected by L3.

Joseph W. Doherty Fri, 02/20/2009 - 04:38

To extend Rick's point that host stacks don't need to process multicast packets they are not interested in, on switches that support some type of multicast suppression, e.g. IGMP snooping, the host's NIC won't even have to physically process the multicast packet, the switch won't forward it to the host's port.


This Discussion