Profile 14 with Extranet option #2
Last updated
Last updated
Load profile.14.extranet.2.init.cfg
The basic IP addresses, L3VPN, and C-PIM between the PEs and CEs is pre-configured.
There are two VRFs: VRF A on PE1 and VRF B on PE3.
C1 has joined (10.1.3.10, 232.1.1.1). PIM-SSM is in use on both VRF A and VRF B.
Configure profile 14 using extranet so that C1 in VRF A receives the multicast stream that is sourced from VRF B.
PE3 should do SSC (source side chaining)
In this lab we will do source side chaining (SSC). The ingress PE will define the receiver mVPN VRF and stitch the traffic received on the source VRF into the receiver VRF.
Unfortuantely we cannot use a RPF topology fixup on IOS-XR to accomplish this. For this reason, this option is not quite supported, but we can use a routing trick to implement this setup.
First, we enable profile 14 for the receiver VRF, and define the receiver VRF on the ingress PE, PE3.
As before with option 1, there is nothing new here. This is just profile 14 configuration. On PE1 we see that PE3 has sourced a type 1 and type 3 route for the mVPN.
Next we need a static route in VRF A (the receiver VRF) for the source via VRF B (the source VRF). This is redistributed into BGP VPNv4 for the receiver VRF. Note that the static route must have both the outgoing interface and nexthop. This is required so that VRF A can find the RPF neighbor for the source.
On the egress PE, this now just looks like a normal source in the receiver VRF. PE1 joins a (S, G) via BGP route-type 7 and uses Lspvif0 as the incoming interface like usual.
The ingress PE is where the stitching is happening. We see the (S, G) in the receiver VRF, and that the RPF is via Extranet.
The RPF check on PE3 shows VRF B is used. Note that the static route needs the nexthop interface and address in order to complete the RPF check.
Since a route to the sender is present in the receiver VRF, the sender sees ICMP replies from the receiver.
