RIP V2 Multicasting Appears as Broadcasting at IP 224.0.0.9

broadcasteigrpmulticastrip

In RIPv1 the packets are broadcasted out all ports with dest. IP 255.255.255.255. In v2 they are multicasted with dest. IP 224.0.0.9. In Packet Tracer, this v2 packet is transmitted over all interfaces at the same time which looks like broadcasting with an IP of multicasting.

When EIGRP uses multicasting it transmits packets to only one dest. at a time. It also tries to send EIGRP packets to an undesired host (PC, server, etc.) which drops it.

I have tried this only on Cisco Packet Tracer. So can someone please explain me why RIPv2 packet transmission looks like broadcasting with destination IP address as 224.0.0.9?

Thank you.

Best Answer

224.0.0.9 is a protocol standard multicast address, meaning that it is reserved for all RIPv2 speaking routers. This reduces unnecessary overhead, and only speaks to RIPv2 routers, instead of a full broadcast. Here is a portion from the RIPv2 RFC.

https://www.rfc-editor.org/rfc/rfc2453

4.5 Multicasting

In order to reduce unnecessary load on those hosts which are not
listening to RIP-2 messages, an IP multicast address will be used for periodic broadcasts. The IP multicast address is 224.0.0.9. Note
that IGMP is not needed since these are inter-router messages which
are not forwarded.

On NBMA networks, unicast addressing may be used. However, if a
response addressed to the RIP-2 multicast address is received, it
should be accepted.

In order to maintain backwards compatibility, the use of the
multicast address will be configurable, as described in section 5.1.
If multicasting is used, it should be used on all interfaces which
support it.

Related Solutions

Routing – RIP Update Packets

25 Routes can be carried by a RIP Update Packet.

Reference : Cisco Press

Why Can’t Ping Multicast Address 224.0.0.9 of RIP – Routing Insights

Damon, I'm afraid there is something wrong with your specific implementation. I, personally, can't think of an instance where a router doesn't respond to an icmp request on any of it's interfaces. Others, please chime in if that's inaccurate.

At any rate, I mocked it up in GNS3 to make sure there weren't any funky software bugs.

GNS3 Network Diagram

Basic configurations were set up on the interfaces with each router having it's router number as the lo0 interface address (i.e. R1 - 1.1.1.1). For verification, here's the rip routing table.

R1#show ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
R       3.3.3.3 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
     10.0.0.0/24 is subnetted, 3 subnets
R       10.2.2.0 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
                 [120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
R1#

When pinging the multicast address of 224.0.0.9, 3 replys came back; R2 sent a reply, R3 sent a reply, and R1 replied to itself because it is also listening for that address.

R1#debug ip icmp
ICMP packet debugging is on
R1#ping 224.0.0.9 source lo0 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.9, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

*Mar  1 00:15:41.163: ICMP: echo reply sent, src 1.1.1.1, dst 1.1.1.1
*Mar  1 00:15:41.163: ICMP: echo reply rcvd, src 1.1.1.1, dst 1.1.1.1   <--- R1 Response
*Mar  1 00:15:41.179: ICMP: echo reply rcvd, src 10.1.1.2, dst 1.1.1.1  <--- R2 Response
*Mar  1 00:15:41.179: ICMP: echo reply rcvd, src 10.3.3.3, dst 1.1.1.1  <--- R3 Response
Reply to request 0 from 1.1.1.1, 8 ms
Reply to request 0 from 10.3.3.3, 24 ms
Reply to request 0 from 10.1.1.2, 20 ms
R1#

Pinging a multicast address will generate a response from participants listening to that address.

Best Answer

Related Solutions

Routing – RIP Update Packets

Why Can’t Ping Multicast Address 224.0.0.9 of RIP – Routing Insights

Related Topic