Description

This article provides the information about the requirement of a loopback for MVPN in the routing instance and how MVPN multicast works in a multi-vendor environment.

Symptoms

In Junos, loopback is required in the routing Instance; whereas in other vendors, such as Cisco, it is not. Due to this behavior, the default MDT does not come up with other vendor routers, when running Rosen 6 for MVPN. 

CE1----PE1-----P-----PE2(other vendor)----CE2
  • PE1 and lo0.0 : 1.1.1.1

  • lo0.1 : 192.168.1.1

  • PE2 and lo0 : 2.2.2.2

  • P and RP : 3.3.3.3

Solution

By default, in Junos, the loopback is mandatory in a VPN routing instance to run MVPN and that loopback acts as the source address, when sending hello messages, join messages, and prune messages over multicast tunnel interfaces. But other vendor implementations may not require any loopback in the routing-instance and they can use the loopback address, which is configured in the global PIM instance, for all PIM, join, and prune messages over the multicast tunnel interface.

The following packet capture from Wireshark shows that the IP address being used by Juniper, when sending hellos/join/prune messages over MTI, is the loopback of routing instance of that domain. 

Frame 112: 104 bytes on wire (832 bits), 96 bytes captured (768 bits)
Juniper PPP
Point-to-Point Protocol
Internet Protocol Version 4, Src: 1.1.1.1 (1.1.1.1), Dst: 232.0.0.1 (232.0.0.1)
Version: 4
<>
Source: 1.1.1.1 (1.1.1.1)
Destination: 232.0.0.1 (232.0.0.1)

Generic Routing Encapsulation (IP)
Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst: 224.0.0.13 (224.0.0.13)
Version: 4

<>
Source: 192.168.1.1 (192.168.1.1) < 192.168.1.1 is lo0.1 IP in routing instance
Destination: 224.0.0.13 (224.0.0.13)

Protocol Independent Multicast
<>
But other vendors use the loopback address, which is configured in the global PIM instance; so other vendors may report RPF failure and the default MDT may not form. When you see pim neighborship over the tunnel interface on another vendor's router, it will report the RFP neighbor as the loopback of the routing-instance; but BGP next hop is the loopback address that is configured in the global instance. So, there is RPF failure being reported.

Here are the supporting logs from another vendor's router that shows the RPF neighbor and BGP next hop as different addresses; which results in RPF failure:

PE2#sh ip mroute vrf ABC 224.1.1.1 > cisco router
<>

(*, 224.1.1.1), 01:02:48/00:02:26, RP 172.168.33.33, flags: S
Incoming interface: Tunnel2, RPF nbr 1.1.1.1 > neighbour address and rpf neighbour address is different; 1.1.1.1 vs 192.168.1.1

Outgoing interface list:
GigabitEthernet0/0.114, Forward/Sparse, 01:02:48/00:02:26

<>

PE2#sh ip pim vrf ABC neighbor

<>

Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.1.1 Tunnel2 00:00:26/00:01:18 v2 1 / G > the neighbour and RPF neighbour addresses are different

  lab@PE1# run show pim neighbors instance ABC
Instance: PIM.ABC
<>
Interface IP V Mode Option Uptime Neighbor addr
mt-0/0/0.32777 4 2 HPG 02:38:14 2.2.2.2


Is a loopback required in the routing-instance? The answer is no.


The following solutions can be used to resolve this issue:

  • After Junos 10.1, the default-vpn-source knob is available under [edit protocols pim] . So, if this knob is used, there is no need to define the loopback in the routing-instance. But, it is mandatory to configure this knob on all the routers, which are involved in the Multicast VRF.
    set protocol pim default-vpn-source interface-name lo0.0
    By using this knob, All juniper routers in the multicast domain will use the loopback address, which is configured in the global PIM instance, as the tunnel source.

    The RPF neighbor will also be the same loopback address; this will prevent RPF failure being reported on other vendor routers. The following logs are from before and after the know was implemented.

    Before the knob:
    PIM mt-0/0/0.32777 SENT 192.168.1.13 -> 224.0.0.13 V2 Hello hold 105 T-bit LAN prune 500 ms override 2000 ms pri 1 genid 2737cc9a sum 0x61c7 len 34 PIM mt-0/0/0.32776 RECV 2.2.2.2 -> 224.0.0.13 V2 Hello hold 105 genid 7a9c8bce pri 1 opt 21 opt 65004 sum 0xd9f2 len 38
    After the knob:
    PIM mt-0/0/0.32777 SENT 1.1.1.1 -> 224.0.0.13 V2 Hello hold 105 T-bit LAN prune 500 ms override 2000 ms pri 1 genid 2737cc9a sum 0x61c7 len 34 PIM mt-0/0/0.32776 RECV 2.2.2.2 -> 224.0.0.13 V2 Hello hold 105 genid 7a9c8bce pri 1 opt 21 opt 65004 sum 0xd9f2 len 38
  • On the Juniper side, set the address on the local loopback, which is configured in a VPN routing instance, the same as that of loopback 0 of the Global instance. For example:


    Routing-instance PIM configuration :

    set routing-instances ABC protocols pim interface lo0.1 mode sparse
    set interfaces lo0 unit 1 family inet address 1.1.1.1/32

    Global PIM configuration :

    set protocols pim interface lo0.0
    set interfaces lo0 unit 0 family inet address 1.1.1.1/32
So, as per the above information,  you can see above that the same IP address is being used on lo0.1 and lo0.0 . So, if this knob is applied, you do not even have to define the loopback in the routing-instance.

This solution can be used when the Juniper router is running Junos code, prior to the 10.1 release.