cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9105
Views
8
Helpful
7
Replies

RIP Multicast vs Broadcast

badalam_nt
Level 1
Level 1

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 ?

7 Replies 7

Richard Burts
Hall of Fame
Hall of Fame

Petru

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.

HTH

Rick

HTH

Rick

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 ?

Petru

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.

HTH

Rick

HTH

Rick

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?

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.

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.

Switches include support for multicast group discovery protocols that make it possible for each station to tell the switch about the multicast group addresses that it wants to hear, so the switch will send the multicast packets only to the ports connected to stations that have indicated their interest in receiving the multicast traffic. However, lower cost switches, with no capability to discover which ports are connected to stations listening to a given multicast address, must resort to flooding multicast packets out all ports other than the port on which the multicast traffic was received, just like broadcast packets.

 

Spurgeon, C. and Zimmerman, J. (2013). Ethernet switches. Beijing: O'Reilliy.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: