Topology: L3vpn setup +--------------------+ +--------------------+et-2/0/2 +--------------------+et-2/1/2 +--------------------+ +--------------------+ | | | |192.168.10.1/30 | |192.168.11.1/30 | | | | | | | +--------------------+ +--------------------+ | | | | |lt-2/0/0.1 | | 192.168.10.2/30| | 192.168.11.2/30| |lt-2/0/0.2 (1000) | | | MX480-r070 – AS200 |172.168.11.1/30 | MX480-r070 – AS100 | et-2/0/2| MX480-r130 – AS100 | et-2/0/2| MX480-r131 – AS100 |172.168.10.2/30 | MX480-r131 – AS200 | | Blossom – LS – CE1 +--------------------+ Blossom | | Atticus | | Uranius - DUT +--------------------+ Uranius – LS – CE2 | | 11.11.11.11/32 | 172.168.11.2/30| 1.1.1.1 |et-2/0/5 | 2.2.2.2/32 |et-2/1/5 | 3.3.3.3/32 | 172.168.10.1/30| 22.22.22.22/32 | | | lt-2/0/2.2| |192.168.12.1/30 | |192.168.12.1/30 | | (1000) lt-2/0/0.1| | | | | +--------------------+ +--------------------+ | | | | | | | 192.168.12.2/30| | 192.168.12.2/30| | | | +--------------------+ +--------------------+ et-2/0/5+--------------------+ et-2/0/5+--------------------+ +--------------------+
Case 1: Without ‘vrf-table-label’ or VT-interface. When customer VRF is not configured with the ‘vrf-tabl-label’ or VT-interface, the VNP label is directly mapped to the CE interface inside VRF. When traffic hits the VPN label, a lookup happens for the VPN label in the master routing instance, and after the lookup, traffic is directly sent to the CE interface. ICMP Error Handling: In case of error handling like ICMP MTU exceed, the FPC microkernel need to send the reply for which it need to know the from which VRF the reply need to send. In this case the metadata along with the packet has only core interface as an incoming interface. Through this interface microkernel does not know the VRF details hence it cannot send the reply labroot@uranius-re0> show route advertising-protocol bgp 1.1.1.1 22.22.22.22 extensive L3VPN-CE2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) * 22.22.22.22/32 (1 entry, 1 announced) BGP group mpbgp type Internal Route Distinguisher: 100:1 VPN Label: 34 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] 200 I Communities: target:100:100 labroot@uranius-re0> show route label 34 mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 34 *[VPN/170] 00:00:14 > to 172.168.10.1 via lt-2/0/0.2, Pop
Case 2: With ‘vrf-table-lable’ When the routing instance is enabled with vrf-table-label, a LSI interface is created in software and mapped to the VRF. VPN label are directly mapped to the LSI. Basically,, we can think of the LSI interface as a tunnelled interface that has one end in the default routing instance and the other end in VRF. When traffic hits the VPN label, a lookup is done on the VPN label, and the mapped LSI interface of that VPN label is found. Now the traffic is switched directly to the VRF from default routing instance through LSI interface. When traffic comes inside the VRF, the second lookup happens and traffic is forwarded to the CE interface. ICMP Error handling : In this case, when error handling comes into play, the microkernel is able to send the traffic because, in this case, the packet’s metadata has the incoming interface details (basically LSI interface details) and the LSI interface is bound to the specific VRF. Since the microkernel knows about the VRF through this binding, it can create the ICMP reply and send it through that VRF (through LSI interface). labroot@uranius-re0> show route advertising-protocol bgp 1.1.1.1 22.22.22.22 extensive L3VPN-CE2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) * 22.22.22.22/32 (1 entry, 1 announced) BGP group mpbgp type Internal Route Distinguisher: 100:1 VPN Label: 33 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] 200 I Communities: target:100:100 labroot@uranius-re0> show route label 33 mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 33 *[VPN/0] 00:01:04 > via lsi.1280 (L3VPN-CE2), Pop
Case 3: With VT-Interface When the routing instance is enabled with VT interface, VT it’s hardware base interface inside the routing chip is created and mapped to the VRF. VPN label are directly mapped to the VT. Basically, we can think of VT interface as a tunnelled interface that has one end in the default routing instance and the other end in the VRF. When traffic hit the VPN label, a lookup is done on VPN label and mapped VT interface of that VPN label is found. Now the traffic is switched directly to the VRF from default routing instance through VT interface. When traffic comes inside the VRF, the second lookup happens and traffic is forwarded to the CE interface. ICMP Error Handling: In this case, when error handling comes into play, the microkernel is able to send the traffic because, in this case, the packet’s metadata has the incoming interface details (basically VT interface details) and VT interface is bound to the specific VRF. Since the microkernel knows about the VRF through this binding, it can create the ICMP reply and send it through that VRF (through VT interface). abroot@uranius-re0> show route advertising-protocol bgp 1.1.1.1 22.22.22.22 extensive L3VPN-CE2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) * 22.22.22.22/32 (1 entry, 1 announced) BGP group mpbgp type Internal Route Distinguisher: 100:1 VPN Label: 32 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [100] 200 I Communities: target:100:100 labroot@uranius-re0> show route label 32 mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 32 *[VPN/0] 00:01:36 > via vt-2/0/0.0, Pop