Option A mVPN
Load russo.pl.course.inter-as.opt.a.mvpn.init.cfg
#IOS-XE
config replace flash:russo.pl.course.inter-as.opt.a.mvpn.init.cfg
#IOS-XR
configure
load bootflash:russo.pl.course.inter-as.opt.a.mvpn.init.cfg
commit replace
yL3VPN inter-AS option A is fully setup and working.
Enable mVPN using the following guidelines:
Use profile 1 in Globomantics (AS65001)
mVPN default MDT MP2MP, with PIM as the overlay
Use CSR7 as the root
Use profile 0 in Wired Brain (AS65002)
P-PIM default MDT using PIM-BiDir, PIM as the overlay
Use XR14 as the RP
PIM is already enabled on all core interfaces
On R1, join (192.0.2.1, 232.1.1.1) within vrf L3B and L3C. Ensure that when R1 pings this group, both 172.16.18.1 and 172.16.110.1 respond.
Answer
# Globomantics (AS65001)
#
#XR11, XR12
vrf L3A
vpn id 65000:101
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf L3A add ipv4
interface all enable
mdt so lo0
mdt default mldp ipv4 10.0.0.7
!
route-policy USE_MLDP
set core-tree mldp-default
end-policy
!
router pim vrf L3A add ipv4
rpf topology route-policy USE_MLDP
!
mpls ldp mldp
#R6
vrf definition L3A
vpn id 65000:101
add ipv4
mdt default mpls mldp 10.0.0.7
!
ip multicast-routing vrf L3A distributed
ip pim vrf L3A ssm default
!
int GigabitEthernet2.3016
ip pim sparse-mode
#R2
vrf definition L3A
vpn id 65000:101
add ipv4
mdt default mpls mldp 10.0.0.7
!
ip multicast-routing vrf L3A distributed
ip pim vrf L3A ssm default
!
int Gi2.233777
ip pim sparse-mode
# Wired Brain (AS65002)
#
#R3, R4, R8, R9, R10
ip multicast-routing distributed
int lo0
ip pim sparse-mode
ip pim bidir-enable
#XR13
multicast-routing add ipv4 int all en
#XR14
multicast-routing add ipv4 int all en
router pim add ipv4 bsr candidate-rp 10.0.0.14 bidir
router pim add ipv4 bsr candidate-bsr 10.0.0.14
#R3
ip multicast-routing vrf L3BC distributed
ip pim vrf L3BC ssm default
!
vrf definition L3BC
address-family ipv4
mdt default 239.0.0.1
!
int Gi2.233777
ip pim sparse-mode
int Gi2.3113888
ip pim sparse-mode
#R8
ip multicast-routing vrf L3B distributed
ip pim vrf L3B ssm default
!
vrf definition L3B
address-family ipv4
mdt default 239.0.0.1
!
int GigabitEthernet2.3018
ip pim sparse-mode
#R10
ip multicast-routing vrf L3C distributed
ip pim vrf L3C ssm default
!
vrf definition L3C
address-family ipv4
mdt default 239.0.0.1
!
int GigabitEthernet2.3110
ip pim sparse-modeExplanation
Inter-AS option A for mVPN works very much the same as option A for unicast L3VPN. First, we must have a working inter-AS L3VPN setup anyways, as the AS with the receivers will need routes back to the sources in the other AS in order for the RPF check to work. Once the unicast L3VPN is setup correctly, the ASBRs simply treat each other as CEs for multicast traffic. It is simply a matter of enabling PIM on the ASBR links.
First we setup the mVPN in each AS. AS65001 uses profile 1 which involves C-PIM in the overlay and mLDP MP2MP in the underlay. Given that C-PIM overlay is the default, all we need to do is configure the mLDP root on each PE. We also make sure to enable PIM on all PE-CE links, including links towards ASBRs (which are treated as CEs in option A).
#IOS-XR
vrf L3A
vpn id 65000:101
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf L3A add ipv4
interface all enable
mdt so lo0
mdt default mldp ipv4 10.0.0.7
!
route-policy USE_MLDP
set core-tree mldp-default
end-policy
!
router pim vrf L3A add ipv4
rpf topology route-policy USE_MLDP
!
mpls ldp mldp
#IOS-XE
vrf definition L3A
vpn id 65000:101
add ipv4
mdt default mpls mldp 10.0.0.7Next, AS65002 uses profile 0 with P-PIM in the underlay via PIM-BiDir, and C-PIM in the overlay via the multicast GRE tunnel.
#IOS-XE
ip multicast-routing vrf L3BC distributed
ip pim vrf L3BC ssm default
!
vrf definition L3BC
address-family ipv4
mdt default 239.0.0.1We can verify that mVPN is working within each AS. R7 should see a mLDP MP2MP tree rooted at itself with several interested receivers:
Any PE should see all other PEs as C-PIM neighbors.
Likewise in AS65002, we should see a PIM-BiDir tree rooted at XR14:
All PEs in AS65002 should also see each other as C-PIM neighbors:
At this point, all that is needed is for the ASBRs to enable PIM on the NNI:
Verifying multicast traffic
On R1, we’ll join (192.0.2.1, 232.1.1.1) within vrf L3B and L3C. Remember to enable IGMP v3 on the PEs.
#R8
int GigabitEthernet2.3018
ip igmp ver 3
#R10
int GigabitEthernet2.3110
ip igmp ver 3
#R1
int GigabitEthernet2.3018
ip igmp ver 3
ip igmp join-group 232.1.1.1 so 192.0.2.1
int GigabitEthernet2.3110
ip igmp ver 3
ip igmp join-group 232.1.1.1 so 192.0.2.1Within AS65002, the PIM Joins make their way to R3, as the source is known via R3. R3 uses the interface towards R2 as the RPF interface, as the best BGP route is via R2.
R2 receives the PIM Join from a “CE” and simply continues the process. R2 finds the best route is via XR12 (because R1 is setting MED high towards R6). The link to the ASBR/”CE” is added to the OIL. R2 has no idea that the “CE” is really an ASBR in another completely separate AS.
The (S, G) state makes its way to XR12, and the tree is successfully built. When R1 in VRF L3A pings the group, it receives replies from both hosts.
In summary, mVPN with Option A is simply a matter of enabling PIM on the L3 NNI. As long as mVPN is independently working in each AS, and unicast inter-AS is working, then mVPN should be working as well.
Last updated