Entries Tagged as ''

NBMA Mode and GRE Tunnel on IP Multicast

There are two interesting topics in IP Multicast network to solve problem on Frame Relay network. Frame relay network is non-broadcast media access network type. However, it can perform “pseudo-broadcast” and performed at router’s CPU level. Frame relay network is also hub-spoke network type. So, here are two problems.

  1. Since IP multicast is perform RPF calcuation, how one spoke send multicast traffic to another spoke?
  2. If multicast source is on the top of Hub, since OIL (outgoing interface list) is only one serial interface, how the traffic is going to only the spoke which required multicast traffic, in stead of all spokes?

ip nbma-mode is one of the solutions. First, NBMA mode is ONLY working on PIM sparse mode. Second, if one serial interface enable NBMA mode, it automatically change OIL to the spoke IP address, not outgoing interface anymore. Thus, The traffic can only go to that spoke.

GRE tunnel is another way to solve spoke traffic to another spoke.

GRE Tunnel in Multicast

We can see from diagram above that, R4 is MA (Mapping Agent), R4 will advertise RP information to all 224.0.1.40 by using PIM dense mode. Remeber, Auto-RP is communicated by using PIM Dense Mode. RP will send advertised to 224.0.1.39, which is listened by MA. Then, MA send advertisement to all 224.0.1.40. The traffic will never go to R1 even though NBMA mode is enabled on R5. So, we need create a GRE tunnel between R4 and R1.

R4

interface tunnnel 0

tunnel source loopback 0

tunnel destination 150.1.1.1

ip unnumber loopback 0

ip pim sparse-mode

R1

interface tunnel 0

tunnel source loopback 0

tunnel destination 150.1.4.4

ip unnumber loopback 0

ip pim sparse-mode

However, when show ip pim rp mapping on R1, there is no RP shown. This is because RPF failure. When we show ip route 150.1.4.4 on R1, it point to serial interface, but Mapping Agenet is learned from tunnel interface. So, we need add a static mroute on the global.

ip mroute 150.1.4.4 255.255.255.255 tunnel 0

Getting Transit Packets on Router

If we use debug ip packet on Cisco router, we can only see the packets that originated on the router or destinated to the router. We cannot see any transit packets. The reason is, in the interface level, the command ip route-cache is enabled as default. We can define route-cache options to NetFlow or CEF. On the most cases, route-cache is using CEF because ip cef is enabled on the global.

Therefore, we need to type no ip route-cache in interface level to let all transit IP packet to pass through processor.

NAT Pool IP Address Need Participate IGP

In the NAT world, there are two terminologies that we used often, one is Inside Local, and the other is Inside Global. Inside Local is those IP address hidden behind NAT. Inside Global is virtual IP address pool that can be accessed from outside world. Before configuring NAT, we need to define an access-list for INSIDE_LOCAL to define which IP address participate NAT process. We also need to define an IP pool for INSIDE_GLOBAL. Then, we can enable NAT

ip nat inside source list INSIDE_LOCAL pool INSIDE_GLOBAL overload

However, we still can’t ping outside from inside. Why? because INSIDE_GLOBAL are virtual IP addresses that outside routers don’t have route to it. To solve this problem, we have two options.

  1. Create a loopback interface, assign IP address to the interface and let it running IGP in outside network.
  2. Create a static route on NAT router and point it to Null0 interface. Redistribute the static route to IGP in outside network.