In the Profile 0 post, CustA’s multicast crossed SP-A in GRE on a default MDT, and A-PE1 and A-PE2 ran PIM with each other over it. Profile 11 keeps the GRE default MDT and moves that PE-to-PE signalling into BGP. With BGP auto-discovery, each PE advertises its membership in the multicast VPN in a BGP route. With BGP customer multicast (C-multicast), a PIM join from a CE becomes a BGP route that only the PE toward the source or the RP imports.
In the Profile 0 post, A-PE1 listed A-PE2’s Loopback0, 10.1.0.6, as a PIM neighbor on Tunnel1. With Profile 11, the same command on A-PE1 lists only CustA-HQ, 10.1.10.2 on Gi4:
A-PE1#show ip pim vrf CustA neigh
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.10.2 GigabitEthernet4 6d23h/00:01:34 v2 1 / DR S P GTopology file: topology.clab.yml · Addressing: ipam.md · Stage configs, 5 nodes (A-PE1, A-PE2, A-RR, CustA-HQ, CustA-Br1): stage_configs/lab03-s5a-spa-mvpn-p11/
The PEs no longer send PIM hellos to each other on Tunnel1.
The Configuration
The change on A-PE1:
vrf definition CustA
address-family ipv4
no mdt default 239.1.10.1
mdt auto-discovery pim
mdt default 232.0.10.1
mdt overlay use-bgp
exit-address-family
!
router bgp 64501
no address-family ipv4 mdt
!
address-family ipv4 mvpn
neighbor 10.1.0.7 activate
neighbor 10.1.0.7 send-community extended
exit-address-family
!The full file is A-PE1.ios.
no mdt default 239.1.10.1 removes the default MDT group of Profile 0. mdt auto-discovery pim turns on BGP auto-discovery, with PIM and GRE still building the provider tunnel. The new default MDT group, 232.0.10.1, is in 232.0.0.0/8, which ip pim ssm default made the SSM range in the IP multicast core post. mdt overlay use-bgp moves the customer joins into BGP. The data MDT line from Profile 0, mdt data 232.1.10.0 0.0.0.255 threshold 1, stays.
In BGP, the IPv4 MVPN address family replaces IPv4 MDT. The multicast VPN routes in it carry route targets as extended communities, so IOS-XE needs send-community extended for A-RR. A-PE2 has the same configuration.
The PEs use five route types in this address family:
- Type 1, Intra-AS I-PMSI auto-discovery: membership. Each PE announces that it is in CustA’s multicast VPN and which default MDT it sends on.
- Types 6 and 7, C-multicast Shared Tree Join and Source Tree Join: customer joins. A PE turns a CE’s PIM (*,G) or (S,G) join into a BGP route for the PE behind the RP or the source.
- Type 5, Source Active auto-discovery: an active source. The PE behind the source announces that the source is sending to the group.
- Type 3, S-PMSI auto-discovery: a data MDT. The same PE announces that a flow moves to a data MDT.
A-RR makes the same swap and reflects the new address family to both PEs:
router bgp 64501
no address-family ipv4 mdt
!
address-family ipv4 mvpn
!
neighbor 10.1.0.5
no address-family ipv4 mdt
address-family ipv4 mvpn
route-reflector-client
!
neighbor 10.1.0.6
no address-family ipv4 mdt
address-family ipv4 mvpn
route-reflector-client
!IOS-XR sends extended communities to iBGP peers by default. Both PEs are up on the new address family, with three prefixes from each:
RP/0/RP0/CPU0:A-RR#show bgp ipv4 mvpn sum
Thu Jul 23 04:38:50.553 UTC
BGP router identifier 10.1.0.7, local AS number 64501
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0
BGP main routing table version 12
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 12 12 12 12 12 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 11077 10140 12 0 0 15:09:58 3
10.1.0.6 0 64501 11078 10139 12 0 0 15:06:06 3Adding an address family to a BGP session resets the session, with every address family on it.
A-PE2#show bgp vpnv4 unicast all sum
BGP router identifier 10.1.0.6, local AS number 64501
BGP table version is 133, main routing table version 133
15 network entries using 3840 bytes of memory
15 path entries using 2040 bytes of memory
9/8 BGP path/bestpath attribute entries using 2664 bytes of memory
2 BGP rrinfo entries using 80 bytes of memory
3 BGP AS-PATH entries using 88 bytes of memory
1 BGP community entries using 24 bytes of memory
12 BGP extended community entries using 956 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9692 total bytes of memory
BGP activity 55/13 prefixes, 138/96 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.7 4 64501 936 1013 133 0 0 15:05:41 6
10.1.12.2 4 64530 11079 11072 133 0 0 6d23h 1The Default MDT in the Global Table
A-PE1’s entries for the new default MDT group:
A-PE1#show ip mroute 232.0.10.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.0.6, 232.0.10.1), 14:58:34/stopped, flags: sTIZ
Incoming interface: GigabitEthernet2, RPF nbr 10.1.1.21, Mroute
Outgoing interface list:
MVRF CustA, Forward/Sparse, 14:58:34/00:01:25
(10.1.0.5, 232.0.10.1), 14:58:59/00:02:54, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse, 14:58:59/00:02:54Profile 0’s default MDT had a (*,G) entry through the RP 10.1.0.100. This group has two (S,G) entries, one per PE, both with s, the SSM Group flag. In SSM, a router joins a specific source, so each PE needs the other PE’s Loopback0 first, and the Type 1 routes carry it. (10.1.0.6, 232.0.10.1) is A-PE1 receiving from A-PE2 and passing the packets to the CustA VRF. (10.1.0.5, 232.0.10.1) is A-PE1 sending from its own Loopback0 out Gi2. Both trees run through A-P1 and A-P3:
Mroute after the RPF neighbor means that the RPF lookup for 10.1.0.6 still uses the static mroute from the IP multicast core post, toward A-P1 at 10.1.1.21:
A-PE1#show ip rpf 10.1.0.6
RPF information for ? (10.1.0.6)
RPF interface: GigabitEthernet2
RPF neighbor: ? (10.1.1.21)
RPF route/mask: 10.1.0.6/32
RPF type: multicast (static)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast baseThe default MDT no longer uses the anycast RP. On A-P1, one of the two RPs:
A-P1#show ip mroute 239.1.10.1
Group 239.1.10.1 not found
A-P1#show ip msdp sa-cache
MSDP Source-Active Cache - 0 entriesThe Customer RP
With Profile 11, CustA’s RP, 10.10.0.1 on CustA-HQ’s Loopback0, is static on HQ, on CustA-Br1, and in the CustA VRF on A-PE1 and A-PE2. On A-PE2:
A-PE2#show run | i ip pim vrf CustA rp-address
ip pim vrf CustA rp-address 10.10.0.1
A-PE2#show ip pim vrf CustA rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 10.10.0.1 (?)A PE turns a customer (*,G) join into a BGP route that names the RP and the group, so the PE needs its own RP mapping for the group. HQ and Br1 still have the Auto-RP configuration from Profile 0. HQ’s RP announcements did not reach CustA-Br1, the mapping agent, and Br1 has only the static entry:
CustA-Br1#show run | i ip pim rp-address
ip pim rp-address 10.10.0.1
CustA-Br1#show ip pim rp mapp
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s): 224.0.0.0/4, Static
RP: 10.10.0.1 (?)A-PE2’s RPF lookup for the RP resolves to Tunnel1 and A-PE1, 10.1.0.5, which advertises HQ’s Loopback0 in VPNv4. A-PE1 is the upstream PE for the shared tree:
A-PE2#show ip rpf vrf CustA 10.10.0.1
RPF information for ? (10.10.0.1)
RPF interface: Tunnel1
RPF neighbor: ? (10.1.0.5)
RPF route/mask: 10.10.0.1/32
RPF type: unicast (bgp 64501)
Doing distance-preferred lookups across tables
BGP originator: 10.1.0.5
RPF topology: ipv4 multicast base, originated from ipv4 unicast baseCustomer Joins in BGP
CustA-Br1’s Loopback0 is a member of 239.10.10.10, as in the Profile 0 post. Br1’s entries for the group:
(*, 239.10.10.10), 6d23h/stopped, RP 10.10.0.1, flags: SJCL
Incoming interface: Ethernet0/1, RPF nbr 10.1.10.5
Outgoing interface list:
Loopback0, Forward/Sparse, 6d23h/00:02:31, flags:
(10.10.0.1, 239.10.10.10), 00:19:27/00:02:06, flags: LJT
Incoming interface: Ethernet0/1, RPF nbr 10.1.10.5
Outgoing interface list:
Loopback0, Forward/Sparse, 00:19:27/00:02:31, flags:The (S,G) entry has T, SPT-bit set, so Br1 receives HQ’s traffic on the source tree. On A-PE2, show ip mroute vrf CustA 239.10.10.10:
(*, 239.10.10.10), 12:08:53/00:02:49, RP 10.10.0.1, flags: Sg
Incoming interface: Tunnel1, RPF nbr 10.1.0.5
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 12:08:53/00:02:49
(10.10.0.1, 239.10.10.10), 00:13:36/00:02:47, flags: TYgQ
Incoming interface: Tunnel1, RPF nbr 10.1.0.5, MDT:[10.1.0.5,232.1.10.0]/never
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 00:13:36/00:02:49g, Sent BGP C-Mroute, means that A-PE2 turned Br1’s joins into BGP C-multicast routes. On A-PE1, the same entries have G, Received BGP C-Mroute, and send HQ’s traffic from Gi4 into Tunnel1:
(*, 239.10.10.10), 12:04:00/stopped, RP 10.10.0.1, flags: SG
Incoming interface: GigabitEthernet4, RPF nbr 10.1.10.2
Outgoing interface list:
Tunnel1, Forward/Sparse, 12:04:00/stopped
(10.10.0.1, 239.10.10.10), 00:08:43/00:01:06, flags: TyGq
Incoming interface: GigabitEthernet4, RPF nbr 10.1.10.2
Outgoing interface list:
Tunnel1, Forward/Sparse, 00:08:43/stoppedA-PE1’s BGP table for the IPv4 MVPN address family:
A-PE1#show bgp ipv4 mvpn all
BGP table version is 78, local router ID is 10.1.0.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.1.0.5:10 (default for vrf CustA)
*> [1][10.1.0.5:10][10.1.0.5]/12
0.0.0.0 32768 ?
*>i [1][10.1.0.5:10][10.1.0.6]/12
10.1.0.6 0 100 0 ?
Route Distinguisher: 10.1.0.6:10
*>i [1][10.1.0.6:10][10.1.0.6]/12
10.1.0.6 0 100 0 ?
Route Distinguisher: 10.1.0.5:10 (default for vrf CustA)
*> [3][10.1.0.5:10][10.10.0.1][239.10.10.10][10.1.0.5]/22
0.0.0.0 32768 ?
*> [5][10.1.0.5:10][10.10.0.1][239.10.10.10]/18
0.0.0.0 32768 ?
*>i [6][10.1.0.5:10][64501][10.10.0.1/32][239.10.10.10/32]/22
10.1.0.6 0 100 0 ?
*>i [7][10.1.0.5:10][64501][10.10.0.1/32][239.10.10.10/32]/22
10.1.0.6 0 100 0 ?
A-PE1 lists A-PE2’s Type 1 route twice: under A-PE2’s RD, 10.1.0.6:10, as received, and under its own RD after importing it.
In steps 1 and 2, Br1 sends A-PE2 a PIM (,G) join toward the RP and a PIM (S,G) join toward the source. A-PE2 sends them on as BGP routes with next hop 10.1.0.6: the (,G) join as a Shared Tree Join, Type 6, and the (S,G) join as a Source Tree Join, Type 7. HQ is both the RP and the source, so both routes carry 10.10.0.1.
Both routes carry A-PE1’s RD, 10.1.0.5:10, and A-PE1’s AS, 64501, in the Source AS field. A C-multicast route takes both from the upstream PE’s VPNv4 route to the RP or the source, here A-PE1’s route to 10.10.0.1. Only A-PE1 imports the two routes, and it sends its own PIM joins toward HQ on Gi4 (step 3).
The Type 5 route goes from A-PE1 back to A-PE2 (step 4) and announces that HQ is sending to 239.10.10.10. A-PE1 originated it after A-PE2’s Type 7 made A-PE1 forward HQ’s (S,G) traffic into Tunnel1. The (S,G) entries show it as q, Sent BGP S-A Route, on A-PE1, and Q, Received BGP S-A Route, on A-PE2.
The Data MDT
On A-PE1, the source tree for the group forwards at 11 kbps, above the 1 kbps threshold:
A-PE1#show ip mroute vrf CustA 239.10.10.10 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 3194 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.10.10.10, Source count: 1, Packets forwarded: 396, Packets received: 396
RP-tree: Forwarding: 4/0/114/0, Other: 4/0/0
Source: 10.10.0.1/32, Forwarding: 392/1/1287/11, Other: 392/0/0A-PE1 moves the flow to the first group of the data MDT pool:
A-PE1#show ip pim vrf CustA mdt send
MDT-data send list for VRF: CustA
(source, group) MDT-data group/num ref_count
(10.10.0.1, 239.10.10.10) 232.1.10.0 1A-PE1 announces the move with the Type 3 route in its BGP table, [3][10.1.0.5:10][10.10.0.1][239.10.10.10][10.1.0.5]: the flow (10.10.0.1, 239.10.10.10) and A-PE1’s address, 10.1.0.5. A-PE2 learns the data MDT group from it and joins (10.1.0.5, 232.1.10.0):
A-PE2#show ip pim vrf CustA mdt receive
Joined MDT-data [group/mdt number : source] uptime/expires for VRF: CustA
[232.1.10.0 : 10.1.0.5] 00:09:15/stopped
A-PE1’s BGP table has no Type 4 Leaf auto-discovery route. A PE answers an S-PMSI route with a Leaf auto-discovery route only when the S-PMSI route sets the Leaf Information Required flag, for example for an RSVP-TE P2MP tunnel. With a PIM-SSM data MDT, A-PE2 joins the tree itself.
What’s Next
The next post keeps the BGP signalling and moves CustA’s default MDT from GRE to an mLDP MP2MP tree, Profile 13.
Leave a Reply