After completing the previous stages, both providers have a working data plane: SP-A label-switches over LDP, SP-B over Segment Routing. However, nothing yet refers to customer prefixes, which RD they belong to, or which far-end PE to tunnel them toward. This part is covered by the control plane, in my case, it will be iBGP with a single Route Reflector per AS, carrying the VPNv4 and VPNv6 address families.
After the completion, every session should be “Established”, however, it will still carry zero prefixes. This is SP-B’s Route Reflector output once the stage is applied:
RP/0/RP0/CPU0:B-RR#show bgp vpnv4 unicast summary
Tue Jun 16 04:37:50.753 UTC
BGP router identifier 10.2.0.7, local AS number 64502
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0
BGP main routing table version 1
BGP NSR Initial initsync version 1 (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 1 1 1 1 1 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.2.0.5 0 64502 88 87 1 0 0 01:24:51 0
10.2.0.6 0 64502 88 88 1 0 0 01:24:54 0
10.2.0.8 0 64502 94 85 1 0 0 01:21:29 0Three clients, B-PE1 (.5), B-PE2 (.6) and B-ASBR (.8). There are no customer VRFs yet, I’ll add them later. That’s why BGP has nothing to advertise.
Topology file: topology.clab.yml · Addressing: ipam.md · Stage configs, all eight BGP nodes on both providers: stage_configs/lab01-s3-bgp/
The Architecture: One RR per AS, a BGP-Free Core
Both providers use the same control-plane design: a single Route Reflector per autonomous system, with PEs and the ASBR configured as clients. The P-routers run no BGP. In AS 64501, A-RR (XRd-CP) reflects for A-PE1, A-PE2, and A-ASBR. In AS 64502, B-RR (XRd-CP) reflects for B-PE1, B-PE2, and B-ASBR.
The RR is control-plane only and never appears in the forwarding path for customer traffic. It reflects NLRI and does not rewrite the BGP next-hop, so the data plane goes PE-to-PE over the LSPs.
A transit LSR swaps the top label of the stack imposed at the ingress PE and doesn’t check the VPN label beneath it or the VPNv4/v6 NLRI.
iBGP peers over Loopback0. The session needs IP reachability between the two loopbacks, that’s why I had configured OSPF and IS-IS in previous stages.
One Session for two Address Families
Each client has one TCP session to its RR between the IPv4 loopbacks, and both VPNv4 and VPNv6 ride on it. There is no separate IPv6 session: the address families are negotiated as MP-BGP capabilities when the session opens. On A-PE1 the two summaries show the same neighbor:
A-PE1#show bgp vpnv4 unicast all summary
BGP router identifier 10.1.0.5, local AS number 64501
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.7 4 64501 94 106 1 0 0 01:31:52 0
A-PE1#show bgp vpnv6 unicast all summary
BGP router identifier 10.1.0.5, local AS number 64501
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.7 4 64501 95 107 1 0 0 01:32:20 0The Route Reflector Config
Both RRs are XRd-CP. The output below is from A-RR; B-RR will look slightly different:
router bgp 64501
bgp router-id 10.1.0.7
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
neighbor 10.1.0.5
remote-as 64501
update-source Loopback0
password clear BGP_AUTH
address-family vpnv4 unicast
route-reflector-client
!
address-family vpnv6 unicast
route-reflector-client
!
!
! ... neighbors 10.1.0.6 and 10.1.0.8 identical ...
!The block above is trimmed to one neighbor, the full file is A-RR.ios.
On XR, route-reflector-client goes under the neighbor’s address-family, so each client carries it twice: once under vpnv4 unicast, once under vpnv6 unicast.
RP/0/RP0/CPU0:A-RR#show bgp vpnv4 unicast neighbors 10.1.0.5 | i Route-Reflector Client
Tue Jun 16 03:20:20.857 UTC
Route-Reflector Client
Route-Reflector ClientThe cluster-ID is not configured. It defaults to the RR’s router-id:
RP/0/RP0/CPU0:B-RR#show bgp vpnv4 unicast process | i Cluster ID
Tue Jun 16 04:40:36.958 UTC
Default Cluster ID: 10.2.0.7
Active Cluster IDs: 10.2.0.7The Client Config: XE and XR
IOS-XE client (A-PE1, A-PE2, A-ASBR, B-ASBR):
router bgp 64501
bgp router-id 10.1.0.5
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.1.0.7 remote-as 64501
neighbor 10.1.0.7 update-source Loopback0
neighbor 10.1.0.7 password BGP_AUTH
!
address-family vpnv4
neighbor 10.1.0.7 activate
neighbor 10.1.0.7 send-community extended
exit-address-family
!
address-family vpnv6
neighbor 10.1.0.7 activate
neighbor 10.1.0.7 send-community extended
exit-address-family
!no bgp default ipv4-unicast stops IPv4 unicast from being activated for the neighbor; the only address families on this session are the two VPN ones. send-community extended sends the route-targets, which are one of the extended communities. IOS-XE sends them on the VPN address families once the neighbor is activated there.
IOS-XR client (B-PE1, B-PE2):
router bgp 64502
bgp router-id 10.2.0.5
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
neighbor 10.2.0.7
remote-as 64502
update-source Loopback0
password encrypted 072D067C71282C313F
address-family vpnv4 unicast
!
address-family vpnv6 unicast
!
!
!No route-reflector-client, and no route-policy. IOS-XR requires an inbound and an outbound policy on eBGP neighbors only. On iBGP, the empty address-family is expected. IOS-XR also sends extended communities to iBGP peers by default, which is why this block has no send-community line.
Platform Difference: The MD5 Password Form
All sessions use the same key, BGP_AUTH. The form in which it is entered differs by platform:
| Node class | Entry form | What running-config shows |
|---|---|---|
| SP-A XR (A-RR) | password clear BGP_AUTH |
encrypted <type-7 string> (XR encodes it on commit) |
| SP-B XR (B-RR, B-PE1, B-PE2) | password encrypted 072D067C71282C313F |
encrypted 072D067C71282C313F |
| All XE (A-PE*, A-ASBR, B-ASBR) | password BGP_AUTH |
password BGP_AUTH – clear, since the CSRs run no service password-encryption |
072D067C71282C313F is the type-7 encoding of BGP_AUTH it decodes back to the same string. Type-7 is reversible and adds no strength over the clear form.
BGP-Free Core: Confirming the Absence
IOS-XE, on A-P1:
A-P1#show ip bgp summary
% BGP not activeIOS-XR, on B-P1, the only XR P-router in either core:
RP/0/RP0/CPU0:B-P1#show bgp vpnv4 unicast summary
Tue Jun 16 04:43:10.209 UTC
% BGP instance 'default' not activeWhy “0 Prefixes” ?
The empty sessions prove the config, authentication, AF negotiation and RR-client flagging. However there is nothing to reflect yet, no routes has been advertised.
route-reflector-client is confirmed under both AFs for every client, and the first real VRF in the L3VPN stage will confirm the reflection.
Verification Summary
Four things to check: the six client sessions are Established with 0 prefixes in VPNv4 and VPNv6; route-reflector-client is set under both AFs for every client; both RRs use their router-id as cluster-ID; the P-routers have no BGP process. The commands, on XR and on XE:
RP/0/RP0/CPU0:A-RR#show bgp vpnv4 unicast summary
RP/0/RP0/CPU0:A-RR#show bgp vpnv6 unicast summary
RP/0/RP0/CPU0:A-RR#show bgp vpnv4 unicast neighbors 10.1.0.5 | i Route-Reflector Client
RP/0/RP0/CPU0:B-RR#show bgp vpnv4 unicast process | i Cluster ID
RP/0/RP0/CPU0:B-P1#show bgp vpnv4 unicast summary
A-PE1#show bgp vpnv4 unicast all summary
A-PE1#show bgp vpnv6 unicast all summary
A-P1#show ip bgp summaryWhat’s Next
The next stage is a convergence: BFD on every IGP adjacency, and LFA extended to IPv6 where the platform supports it.
Yet another Blog 
Leave a comment