Multicast helper map and how to verify multicast

The multicast helper map is an interesting feature. It can be used in scenarios where we want to transport broadcast. Routers don’t forward broadcast by default but we can convert this to multicast and transport it across our network and then convert it back to broadcast. Might not be that common in real life if you don’t work at a stock exchange but is fair game for the lab and a topic that we should not be surprised to see at the lab.

So the basic idea is to convert broadcast packets, transport them as multicast and then convert it back to broadcast. First lets look at our topology.

The idea here is to take broadcast coming from R1 in on R2 Fa0/0, convert it to multicast. Transport it to R3 which then converts it back to broadcast and sends it out to R4. Using this technology we can actually exchange routes between non adjacent routers, pretty cool?

You can download a .net file and initial configs for the routers here.

This is our assigned task:

Create a Loopback99 interface on R1 and assign it an IP address of 1.1.1.1/24; advertise this network on R1 using RIP v1 via FastEthernet0/0.

Configure R4 to receive the RIP advertisements from R1. You must use a multicast solution for this. In other words you may not configure solutions involving tunnel interfaces, enable RIP elsewhere than R1 and R4, use bridging, IPsec, magic, etc.

· Use PIM dense mode only.

· You may use a secondary IP address of 155.12.1.4/24 as part of your solution.

· Use access list 120 for any lists you need.

· You do not need to be able to ping 1.1.1.1 from R4

· Use the multicast group 224.9.9.9

So we start by configuring R1. RIP version 1 is broadcast only and it does not include the subnet mask. All we need to do on R1 is configure RIP. We simply announce the network and leave the default settings which is to announce with version 1 and receive version 1 or 2. All the magic will happen on R2 and R3.

Then we proceed to configure R2. This is where most of the magic happens. We need to enable PIM dense mode on both Fa0/0 and S0/0. To be able to process switch the UDP RIP packets coming in we need to configure ip forward-protocol udp rip. Then we will configure the multicast helper map. Lets have a look.

So broadcast coming in on Fa0/0 matching access-list 120 is converted to multicast with a destination of 224.9.9.9. We are running PIM dense mode so later we should be able to see (S,G) entries in the mroute table.

We proceed to configure R3. The config will be very similar to R2.

On R3 we convert back 224.9.9.9 to the broadcast address of the segment between R3 and R4. We need to turn on directed broadcast otherwise we will not be allowed to send this packet out.

On R4 we simply turn on RIP. We were allowed to create a second subnet but lets wait with that.

So now everything should be running. However, we will have some issues. I am not running any IGP between R2 and R3. R3 will not know how to reach the source 155.1.12.1 so we will have a RPF failure which you can see below.

We can also see this if we check the mroute counters.

So how can we fix the RPF failure? We have a few different options. Either we need to run an IGP between R2 and R3 or we could add a static route or we could add a static mroute. This time I chose to use a static mroute because it is easy. Lets add that.

Now the traffic should be reaching R4. However the RIP rout will not be installed. This is because RIP validates the update source. If we receive an update from a non locally connected source the update will not be accepted. We can configure RIP to not validate the update source or we can configure a secondary IP address in same subnet as the source (we were allowed to do this according to the task).

Now we have the route installed. What will the multicast routing table look like? Lets look at R2 and R3. Since we are running dense mode we should only have (S,G) entries.

R2 has the (S,G) entry as expected. It has a flag of T since it is a SPT tree. We don’t have an incoming RPF neighbor since R1 is not running PIM.

Now we will look at R3.

We have R2 as the incoming RPF neighbor. RPF is done via static mroute. We have no outgoing interface. This is usually bad but since we are converting back to broadcast this is OK. If we do a debug of mpacket we will see an error message that OIL is null.

We have completed our task and if this was the lab we would stop here. To take it to the next step lets think what we would need to be able to have reachability from R4 to R1 loopback.

As we can see route recursion fails since we don’t know how to reach 155.1.12.1. Earlier we used a hack to not validate the update source. Lets remove this and add the secondary subnet to R4 instead.

Now the route recursion is working. R4 is using outgoing interface Fa0/0. This is Ethernet so we need to encapsulate the packet and send it to R1 MAC address. Usually we would send ARP request but the devices are not locally connected. Lets try adding a static ARP entry.

Traffic should be able to reach R3. R3 will not know how to reach 1.1.1.1 though. I’ll add static routes on R3 and R2.

Finally I’ll also add a static ARP entry on R1.

Now lets try a ping. It didn’t work. No matter how I try by adding static ARP entries and the correct routes I could not get the ping to succeed. I even tried on R4 to source traffic from 155.1.12.4 but that did not work either. I could see the traffic leaving R4 but not entering on R3. Very strange. If you have any suggestions post them in the comments section.