Ticket #15

Ticket #15

Network diagram


T15

IGP diagram


T15_igp

The problem:

R1 is using v2 RIP broadcast. The network was configured with multicast-helper to transport the RIP broadcast over the multicast network to R6. However, R6 do not see R1's Lo route in its routing table. Find and fix the problem.


The solution:


First, lets check R6's routing table for R1's Lo0 IP address.

On R6:

R6#sh ip route 7.15.0.1
% Subnet not in table

Indeed, the route is not there. Let make sure R1 is actually sending RIP V2 broadcast advertisements with its Lo0 route.

On R1:

R1#deb ip rip 
RIP protocol debugging is on
R1#
*Aug 13 20:36:59.699: RIP: sending v2 update to 224.0.0.9 via Loopback0 (7.15.0.1)
*Aug 13 20:36:59.699: RIP: build update entries
*Aug 13 20:36:59.699:   7.15.12.0/24 via 0.0.0.0, metric 1, tag 0
*Aug 13 20:36:59.699: RIP: ignored v2 packet from 7.15.0.1 (sourced from one of our addresses)
R1#
*Aug 13 20:37:03.487: RIP: sending v2 update to 255.255.255.255 via FastEthernet0/0 (7.15.12.1)
*Aug 13 20:37:03.487: RIP: build update entries
*Aug 13 20:37:03.491:   7.15.0.1/32 via 0.0.0.0, metric 1, tag 0
R1#un all
All possible debugging has been turned off

We can see that R1 is sending RIP V2 broadcasts.


Since there are no debug command that I know of for ip multicast-helper we will have to rely on checking configuration and general MCAST show commands and debugging. 


The best way to do multicast-helper TS is to just follow the configuration guide.


Here is a link for the configuration guide: IP multicast helper.


Lets first check R2 and then lets check R5.


We need to check the following things on R2:

  • An ACL is configured to capture the RIP packets.
  • ip multicast-helper is configured on the interface facing R1.
  • IP forwarding is enabled for RIP.

On R2:

R2#sh run | i forwa|access-list|interface|helper
interface Loopback0
interface FastEthernet0/0
interface FastEthernet0/1
 ip multicast helper-map broadcast 239.2.2.2 101
interface Serial1/0
interface Serial1/1
interface Serial1/2
interface Serial1/3
ip forward-protocol nd
ip forward-protocol udp rip
access-list 101 permit udp any any eq rip

Its all there. We can also checkout the ACL counter on ACL#101.

On R2:

R2#sh ip access-lists 
Extended IP access list 101
    10 permit udp any any eq rip (79 matches)

We can see that R2 is doing something with the RIP packets.


Lets check R5 for the following configurations:

  • An ACL is configured to capture the RIP packets.
  • ip multicast-helper is configured on the interface facing R2, with the correct ACL, multicast address and broadcast address (which should belong to the interface between R5 and R6)
  • IP forwarding is enabled for RIP.
  • ip directed-broadcast is configured on the interface facing to R6.

On R5:

R5#sh run | i forwa|access-list|interface|helper|direct

interface Loopback0

interface FastEthernet0/0

 ip directed-broadcast

interface FastEthernet0/1

 ip multicast helper-map 239.2.2.2 7.15.56.255 101

interface Serial1/0

interface Serial1/1

interface Serial1/2

interface Serial1/3

ip forward-protocol nd

ip forward-protocol udp rip

access-list 101 permit udp any any eq rip

R5#sh ip access-list

Extended IP access list 101

    10 permit udp any any eq rip


Its all there. But R5 ACL counters are not running, which means that R5 do not get any MCAST packets from R2.

Lets check the MCAST network, but tracing back from R5 to R2 checking the following parameters:
  • PIM neighbor
  • PIM RP mappings

On R5:

R5#sh ip pim neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
7.15.45.4         FastEthernet0/1          01:21:46/00:01:36 v2    1 / S P
R5#sh ip pim rp mapping
PIM Group-to-RP Mappings

R5#

We can see that R5 got a R4 as its PIM neighbor and that R5 do not know who the RP is, which can explain why R5 do not get any MCAST packets for 239.2.2.2.

Lets move on to R4.

On R4:

R4#sh ip pim neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
7.15.34.3         FastEthernet0/1          01:23:58/00:01:28 v2    1 / S P
7.15.45.5         FastEthernet0/0          01:23:58/00:01:26 v2    1 / DR S P
R4#sh ip pim rp mapping
PIM Group-to-RP Mappings

R4#

We can see that R4 got R5 and R3 as neighbors. But just like R5, it got no RP mappings.


Lets move on to R3.

On R3:

R3#sh ip pim neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
7.15.23.2         FastEthernet0/1          01:26:35/00:01:19 v2    1 / S P
7.15.34.4         FastEthernet0/0          01:26:32/00:01:26 v2    1 / DR S P
R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 7.15.0.2 (?), v2v1
    Info source: 7.15.0.2 (?), elected via Auto-RP
         Uptime: 01:15:07, expires: 00:02:23

We can see that R3 got both R2 and R4 as its PIM neighbors and that it got an RP mapping. R2 is the RP, and R3 learned about the RP address via AUTO-RP. 


If R3 learned about a RP via AUTO-RP by receiving discovery packets, then why R4 do not see the RP discovery messages as well?


To answer that, lets enable debugging on R3.

On R3:

R3#deb ip mpacket 
IP multicast packets debugging is on
R3#
*Aug 13 21:19:52.667: IP(0): s=7.15.0.2 (FastEthernet0/1) d=224.0.1.40 (FastEthernet0/0) id=3143, ttl=1, prot=17, len=48(48), mforward

We can see that R2 is sending the discovery packets and that the TTL is 1, which is the reason why the packet is not forwarded by R3 to R4.


Lets check how AUTO-RP is configured on R2.

On R2:

R2#sh run | i pim send
ip pim send-rp-announce Loopback0 scope 2
ip pim send-rp-discovery Loopback0 scope 2

We can see the the scope is too short. Lets change it to something high enough so R5 will get the discovery packets.

On R2:

R2(config)#ip pim send-rp-discovery Loopback0 scope 4

On R3:

*Aug 13 21:24:49.115: IP(0): s=7.15.0.2 (FastEthernet0/1) d=224.0.1.40 (FastEthernet0/0) id=3303, ttl=3, prot=17, len=48(48), mforward

On R5:

R5#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 7.15.0.2 (?), v2v1
    Info source: 7.15.0.2 (?), elected via Auto-RP
         Uptime: 00:00:53, expires: 00:02:06

Now R5 got a RP mapping. Lets check if R6 got the RIP route.

On R6:

R6#sh ip route 7.15.0.1
% Subnet not in table

The route is not there yet.

Lets check R2's mroute table for 239.2.2.2. We should see that R5 have joined the *,239.2.2.2 shared tree.

On R2:

R2#sh ip mroute 239.2.2.2
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.2.2.2), 01:54:33/00:03:14, RP 7.15.0.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:49:28/00:03:14

(7.15.12.1, 239.2.2.2), 01:54:33/00:03:02, flags: T
  Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:49:28/00:03:14

We can see two things: The first is that there is a shared tree towards R5 (F0/0 -> R3 -> R4 -> R5), the seconds is that R2 is actually sending something. Lets enable debuging on R2 and see what does it send.

On R2:

R2#deb ip mpacket 
IP multicast packets debugging is on
R2#
*Aug 13 22:16:58.283: IP(0): s=7.15.12.1 (FastEthernet0/1) d=239.2.2.2 (FastEthernet0/0) id=0, ttl=1, prot=17, len=52(52), mforward

TTL issue again! No surprise as RIP updates are sent with TTL=1. How can we fix that? We can use TTL rewrite!

On R2:

R2(config)#int f0/1
R2(config-if)#no ip multicast helper-map broadcast 239.2.2.2 101
R2(config-if)#ip multicast helper-map broadcast 239.2.2.2 101 ?
  ttl  TTL re-mapping
  <cr>

R2(config-if)#ip multicast helper-map broadcast 239.2.2.2 101 ttl ?
  <1-50>  TTL re-map value

R2(config-if)#ip multicast helper-map broadcast 239.2.2.2 101 ttl 5

Now lets check R6 for a RIP route from R1.

On R6:

R6#sh ip route 7.15.0.1
Routing entry for 7.15.0.1/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 7.15.12.1 00:00:00 ago
  Routing Descriptor Blocks:
  * 7.15.12.1, from 7.15.12.1, 00:00:00 ago
      Route metric is 1, traffic share count is 1

Success!


  _____                             _ 
 / ____|                           | |
| (___  _   _  ___ ___ ___  ___ ___| |
 \___ \| | | |/ __/ __/ _ \/ __/ __| |
 ____) | |_| | (_| (_|  __/\__ \__ \_|
|_____/ \__,_|\___\___\___||___/___(_)