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.
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 ?
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.
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.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...