BGP between Nokia (Alcatel-Lucent) SR and Cisco IOS XR
Anton Karneliuk
Hello my friend,
BGP is the routing protocol that I like most of all. Really, it’s possible to use solely BGP to cover all internal and external routing scenarios. BGP is so powerful and feature-rich that it’s impossible to cover all the topics in a single article that’s why in this article I’ll focus on usual IPv4 and IPv6 address families (sometimes it’s called vanilla BGP).
Topology
For those of you, who follow my series of articles, the physical topology is already familiar and probably it isn’t necessary to remind it. For those of you, who are reading my article for the first time, topology consists of Nokia (Alcatel-Lucent) VSR and Cisco IOS XRv:
On top of the physical topology some trunks are created in a creative way that forms the following logical topology:
You might be wondering, how it appears that we have only three physical (actually virtual, but it isn’t the case) devices and at the logical topology there are 5 routers. Well, I use simple trick that is called virtualization to create VRFs at Nokia (Alcatel-Lucent) VSR and at Cisco IOS XRv, which I used previously describing IPv6/OSPFv3. From routing point of view VRF is a fully independent router, what fits my idea to make BGP topology more interesting very well. The initial configuration files for the lab you can find here: linuxSR1_initialSR3_initialXR1_initial
Basic BGP connectivity for IPv4 unicast
I think you know BGP basics and theory of its operation, so I won’t explain its details. Take a look at the BGP topology below:
Before proceeding with the configuration, let’s briefly review, what we actually should configure. Three routers SR1 (Nokia (Alcatel-Lucent) SR OS), SR3 (Nokia (Alcatel-Lucent) SR OS) and XR1 (Cisco IOS XR) form AS 65000 and they have iBGP (internal BGP) peering in the following way:
SR3 is route reflector (RR) and it forms peering both with SR1 and XR1;
SR1 and XR1 forms peering only with SR3; they don’t form peering with each other;
iBGP peering is built between system interfaces and loopback 0 IPv4 addresses;
SR1 and XR1 changes next-hop path attribute to its system/loopback0 address, when they announce it to route reflector SR3 (next-hop-self);
Routers E65100 (VRF at Cisco IOS XR) and 65200 (VPRN at Nokia (Alcatel-Lucent) SR OS) are eBGP (external BGP) peers to AS 65000 and each resides in its own AS: E65100 in AS 65100 and VPRN 65200 in AS 65200. All eBGP sessions are built at directly connected IPv4 addresses.
In terms of prefix announcement (or more correct term for BGP is NLRI – Network Layer Reachability Information) each router announces public IPv4 address associated with its loopback interface (loopback1, loopback 65100 or loopback 65200). First of all we’ll configure internal BGP (iBGP):
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>router>policy-options# info
———————–
prefix-list “PL_IPV4_LO1”
prefix 192.0.2.0/26 exact
exit
policy-statement “RP_IPV4_AS65000_LO1_TO_BGP”
entry 10
from
protocol direct
prefix-list “PL_IPV4_LO1”
exit
action accept
exit
exit
entry 20
from
protocol bgp
exit
action accept
exit
exit
default-action reject
exit
———————–
*A:SR1>config>router# info
———————–
autonomous-system 65000
bgp
router-id 10.0.255.11
group “iBGP”
export “RP_IPV4_AS65000_LO1_TO_BGP”
neighbor 10.0.255.33
family ipv4
local-address 10.0.255.11
next-hop-self
peer-as 65000
exit
exit
no shutdown
exit
create redistribution profile for BGP routes, which we want to send/receive including redistribution of local loopback1 into BGP;
configure internal BGP peering (what is actually TCP session on port179) between routers in AR 6500;
apply redistribution profile to BGP configuration;
add cluster X.X.X.X command under group configuration in BGP at route reflector (configuration for route reflector in Cisco IOS XR is provided only for reference and it isn’t applied actually).
In the initial configuration of SR1 and SR3 you can see that we have enabled logging of BGP events to console. If you have questions how to do it, read this article.
When everything is configured properly, we’ll see immediately sessions coming up. Both Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XR (ASR 9000) inform us about it:
SR OS:
35 2016/09/08 08:49:36.24 UTC MINOR: BGP #2001 Base Peer 1: 10.0.255.33
“VR 1: Group iBGP: Peer 10.0.255.33: moved into established state”
!
!
IOS XR:
RP/0/0/CPU0:Jun 17 16:37:03.293 : bgp[1053]: %ROUTING-BGP-5-ADJCHANGE_DETAIL : neighbor 10.0.255.33 Up (VRF: default; AFI/SAFI: 1/1) (AS: 65000)
If logging isn’t configured or you have missed it somehow, use the following command for verification (actually BGP troubleshooting always start with it). For Nokia (Alcatel-Lucent) SR OS:
A:SR3# show router bgp summary
============================================================================
BGP Router ID:10.0.255.33 AS:65000 Local AS:65000
============================================================================
BGP Admin State : Up BGP Oper State : Up
Total Peer Groups : 1 Total Peers : 2
Total BGP Paths : 15 Total Path Memory : 2760
Total IPv4 Remote Rts : 2 Total IPv4 Rem. Active Rts : 2
Total McIPv4 Remote Rts : 0 Total McIPv4 Rem. Active Rts: 0
Total McIPv6 Remote Rts : 0 Total McIPv6 Rem. Active Rts: 0
Total IPv6 Remote Rts : 0 Total IPv6 Rem. Active Rts : 0
Total IPv4 Backup Rts : 0 Total IPv6 Backup Rts : 0
—————————————————————————-
Total Supressed Rts : 0 Total Hist. Rts : 0
Total Decay Rts : 0
—————————————————————————-
Total VPN Peer Groups : 0 Total VPN Peers : 0
Total VPN Local Rts : 0
Total VPN-IPv4 Rem. Rts : 0 Total VPN-IPv4 Rem. Act. Rts: 0
Total VPN-IPv6 Rem. Rts : 0 Total VPN-IPv6 Rem. Act. Rts: 0
Total VPN-IPv4 Bkup Rts : 0 Total VPN-IPv6 Bkup Rts : 0
—————————————————————————-
Total VPN Supp. Rts : 0 Total VPN Hist. Rts : 0
Total VPN Decay Rts : 0
—————————————————————————-
Total L2-VPN Rem. Rts : 0 Total L2VPN Rem. Act. Rts : 0
Total MVPN-IPv4 Rem Rts : 0 Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0 Total MDT-SAFI Rem Act Rts : 0
Total MSPW Rem Rts : 0 Total MSPW Rem Act Rts : 0
Total RouteTgt Rem Rts : 0 Total RouteTgt Rem Act Rts : 0
Total McVpnIPv4 Rem Rts : 0 Total McVpnIPv4 Rem Act Rts : 0
Total MVPN-IPv6 Rem Rts : 0 Total MVPN-IPv6 Rem Act Rts : 0
Total EVPN Rem Rts : 0 Total EVPN Rem Act Rts : 0
Total FlowIpv4 Rem Rts : 0 Total FlowIpv4 Rem Act Rts : 0
Total FlowIpv6 Rem Rts : 0 Total FlowIpv6 Rem Act Rts : 0
============================================================================
BGP Summary
============================================================================
Neighbor
Description
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
—————————————————————————-
10.0.255.11
65000 355 0 02h56m59s 1/1/3 (IPv4)
358 0
10.0.255.22
65000 350 0 02h53m17s 1/1/3 (IPv4)
349 0
—————————————————————————-
You can spot here a lot of valuable information. Mainly everything is 0 as we have configured only one address family (IPv4 unicast). Actually you this information in the end of output, where neighbors and activate families are listed. For Cisco IOS XR each summary are address family specific, so you have to mention it, when you want to check peering status:
RP/0/0/CPU0:XR1#show bgp ipv4 unicast summary
BGP router identifier 10.0.255.22, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 17
BGP main routing table version 17
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 17 17 17 17 17 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.0.255.33 0 65000 598 598 17 0 0 03:00:03 2
BGP has quite complex state machine that describes different state of adjacency. In general if you see something besides timers in column “Up/Down”, it’s bad. It’s bad, because it means that adjacency isn’t established. Sometimes it might be desired behavior if you have manually disabled the neighbor (it will be as Admin down or idle).
Now we come to the point of fundamental difference in BGP implementation between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. To be honest, as I has grown up together with Cisco, its outputs seems to me more logical and less confusing. But probably it’s just the matter of taste. So, let’s take a look at BGP RIB at Cisco IOS XR:
RP/0/0/CPU0:XR1#show bgp ipv4 unicast
BGP router identifier 10.0.255.22, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 17
BGP main routing table version 17
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i – internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i192.0.2.0/26 10.0.255.11 100 0 i
*> 192.0.2.64/26 0.0.0.0 0 32768 ?
*>i192.0.2.128/26 10.0.255.33 100 0 i
Processed 3 prefixes, 3 paths
You see here 3 IPv4 prefixes announced by SR1, XR1 and SR3 routers. Prefix “192.0.2.64/26” is locally redistributed by route policy and it has next hop of “0.0.0.0” and weight 32768.
For those of you, who aren’t familiar with Cisco, weight is Cisco proprietary path attribute that is local to the router (not announced to anyone) and considered with the topmost priority in path selection process (prior to RFC based local preference).
Also point out that upon redistribution Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR set different origin codes to routes (SR OS – igp and IOS XR – incomplete). Cisco has another mechanism of prefix announcement besides redistribution, which sets origin to igp as well. I’ll describe it later. Now let’s see in the Nokia (Alcatel-Lucent) SR OS BGP RIB at SR3:
A:SR3# show router bgp routes ipv4
============================================================================
BGP Router ID:10.0.255.33 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked
Origin codes : i – IGP, e – EGP, ? – incomplete, > – best, b – backup
============================================================================
BGP IPv4 Routes
============================================================================
Flag Network LocalPref MED
. Nexthop (Router) Path-Id Label
. As-Path
—————————————————————————-
u*>i 192.0.2.0/26 100 None
. 10.0.255.11 None –
. No As-Path
u*>? 192.0.2.64/26 100 0
. 10.0.255.22 None –
. No As-Path
—————————————————————————-
That’s what makes me crazy. In BGP RIB in Nokia (Alcatel-Lucent) SR OS you see only received routes from other peers. It doesn’t show BGP routes that you originate locally. So actually the output below corresponds to Adj-RIB-In (database with incoming routes from other routers) If you don’t know this fact, you will spend a lot of time troubleshooting BGP at this platform. You can see local routes only in Adj-RIB-Out table per specific neighbor:
A:SR3# show router bgp neighbor 10.0.255.22 advertised-routes
============================================================================
BGP Router ID:10.0.255.33 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked
Origin codes : i – IGP, e – EGP, ? – incomplete, > – best, b – backup
============================================================================
BGP IPv4 Routes
============================================================================
Flag Network LocalPref MED
. Nexthop (Router) Path-Id Label
. As-Path
—————————————————————————-
i 192.0.2.0/26 100 None
. 10.0.255.11 None –
. No As-Path
? 192.0.2.64/26 100 0
. 10.0.255.22 None –
. No As-Path i 192.0.2.128/26 100 None . 10.0.255.33 None – . No As-Path
—————————————————————————-
Routes : 3
As per RFC4271 there are 3 RIB: Adj-RIB-In, Adj-RIB-Out and Loc-RIB. Reference this RFC for more details.
So take care about this difference as it’s very important. Also such difference has another important consequence, which is obvious at SR1:
A:SR1# show router bgp routes
============================================================================
BGP Router ID:10.0.255.11 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked
Origin codes : i – IGP, e – EGP, ? – incomplete, > – best, b – backup
============================================================================
BGP IPv4 Routes
============================================================================
Flag Network LocalPref MED
. Nexthop (Router) Path-Id Label
. As-Path
—————————————————————————- i 192.0.2.0/26 100 None . 10.0.255.11 None – . No As-Path
u*>? 192.0.2.64/26 100 0
. 10.0.255.22 None –
. No As-Path
u*>i 192.0.2.128/26 100 None
. 10.0.255.33 None –
. No As-Path
—————————————————————————-
Routes : 3
============================================================================
You see that Nokia (Alcatel-Lucent) router SR1 see its own route in BGP RIB reflected by SR3:
A:SR1# show router bgp routes 192.0.2.0/26 detail
============================================================================
BGP Router ID:10.0.255.11 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked
Origin codes : i – IGP, e – EGP, ? – incomplete, > – best, b – backup
============================================================================
BGP IPv4 Routes
============================================================================
Original Attributes
—————————————————————————-
Network : 192.0.2.0/26
Nexthop : 10.0.255.11
Path Id : None From : 10.0.255.33
Res. Nexthop : 10.0.255.11
Local Pref. : 100 Interface Name : system
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
AIGP Metric : None
Connector : None
Community : No Community Members Cluster : 10.0.255.33 Originator Id : 10.0.255.11 Peer Router Id : 10.0.255.33
Fwd Class : None Priority : None
Flags : Invalid IGP
Route Source : Internal
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: NotFound
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 06h04m41s
—————————————————————————-
Modified Attributes
—————————————————————————-
Network : 192.0.2.0/26
Nexthop : 10.0.255.11
Path Id : None From : 10.0.255.33
Res. Nexthop : 10.0.255.11
Local Pref. : 100 Interface Name : system
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
AIGP Metric : None
Connector : None
Community : No Community Members Cluster : 10.0.255.33 Originator Id : 10.0.255.11 Peer Router Id : 10.0.255.33
Fwd Class : None Priority : None
Flags : Invalid IGP
Route Source : Internal
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: NotFound
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 06h04m42s
============================================================================
As you can imagine Cisco IOS XR has very similar command to check details of the routes:
RP/0/0/CPU0:XR1#show bgp ipv4 uni 192.0.2.0/26
BGP routing table entry for 192.0.2.0/26
Versions:
Process bRIB/RIB SendTblVer
Speaker 24 24
Last Modified: Jun 17 22:43:53.660 for 00:04:46
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.0.255.11 (metric 10) from 10.0.255.33 (10.0.255.11)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 24
Originator: 10.0.255.11, Cluster list: 10.0.255.33
The main differences between these two outputs is that Nokia (Alcatel-Lucent) SR OS shows the original path attributes of incoming IPv4 prefix and path attributes after processing by ingress route-policy (we don’t have it configured, so they are equal).
Let’s configure external BGP (eBGP). Here is the image for your reference:
VRF at Cisco isn’t fully separated instance, because it inherits AS number from parent BGP context. That’s why in order deceive peering BGP routers, we configure local-as 65100 for BGP peering at E65100 router. On the other hand we have also to deceive E65100 logic by configuring local-as 65535 at SR1 in direction of E65100. In Nokia (Alcatel-Lucent) it’s easier: we just configure AS number under VPRN configuration at SR3. Such tricks are needed only due to VRF usage as eBGP neighbors.
The implication of the explanation above is to make the router think that he peers with router in another AS rather than AS, where the router really resides. It also changes the AS PATH attribute of the BGP routes. Besides this fact, other configuration is very straightforward. Just pay attention that Cisco IOS XR requires to have both ingress and egress route policies configured for eBGP neighbors (there is no such requirement for iBGP). We’ve configured md5 authentication between all external BGP neighbors in order improve security.
Let’s check the routing table at different routers. Nokia (Alctel-Lucent) VSR (SR 7750) in AS 65200 has the following BGP Adj-RIB-In:
Due-to local-as 65535 configurations at SR1 in direction of E65100 some routes seem to be originated from or passing by AS 65535 instead of real AS 65000.
You see that 65200 (VPRN at SR3) has in its BGP RIB three copy of each route, sourcing from XR1, SR1 and E65100. Nevertheless only one route is marked with “u” meaning that this route is installed in routing table:
A:SR3# show router 65200 route-table protocol bgp
============================================================================
Route Table (Service: 65200)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
192.0.2.0/26 Remote BGP 01h28m14s 170
192.0.2.252 0
192.0.2.64/26 Remote BGP 01h28m14s 170
192.0.2.252 0
192.0.2.128/26 Remote BGP 01h28m14s 170
192.0.2.252 0
203.0.113.0/24 Remote BGP 01h37m31s 170
198.51.100.255 0
—————————————————————————-
No. of Routes: 4
The BGP RIB and routing table for E65100 (vrf at XR1) looks as follows:
RP/0/0/CPU0:XR1#show bgp vrf E65100 ipv4 unicast
Status codes: s suppressed, d damped, h history, * valid, > best
i – internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 203.0.113.1:65100 (default for vrf E65100)
*> 192.0.2.0/26 192.0.2.250 0 65535 i
*> 192.0.2.64/26 192.0.2.250 0 65535 ?
*> 192.0.2.128/26 192.0.2.250 0 65535 i
* 198.51.100.0/25 192.0.2.250 0 65535 65200 i
*> 198.51.100.254 0 65200 i
*> 203.0.113.0/24 0.0.0.0 0 32768 i
Processed 5 prefixes, 6 paths
!
!
RP/0/0/CPU0:XR1#show route vrf E65100 ipv4 bgp
B 192.0.2.0/26 [20/0] via 192.0.2.250, 01:54:37
B 192.0.2.64/26 [20/0] via 192.0.2.250, 01:54:37
B 192.0.2.128/26 [20/0] via 192.0.2.250, 01:54:37
B 198.51.100.0/25 [20/0] via 198.51.100.254, 01:43:37
In order to reduce the length of the article I put connectivity test in the separate file. You can refer to it, if you want to check it:
Comprehensive theory about route policies in BGP
In both Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR route policies are actively used for almost all tasks. For example, route redistribution, modification of path attributes and filtering of incoming/outgoing prefixes, filtering what is to install into routing table and many other things. But there is a significant difference how these routing policies work. Let’s start with Nokia (Alcatel-Lucent) SR OS.
Route policy in Nokia (Alcatel-Lucent) SR OS
In Nokia (Alcatel-Lucent) we have just two route policies, which control whole operation of BGP. It’s export and import policy:
Export policy chooses appropriate prefix from routing table (not BGP RIB) based on selection criteria (configured under “from” section) and apply action to the route (configured under “action” section). If the action is “reject”, then such route isn’t sent to neighbor. If the action is “allow”, the route is sent and you have possibility to modify its path attributes.
Import policy is used for modification of path attributes for incoming routes and filtering their installation in routing table. In any case the routes will be in BGP RIB (Adj-RIB-In, actually).
There are three possible points (Cisco IOS XR calls it attach point), where you can apply routing policy:
In case of BGP configuration mode these policies will be used for prefixes send/receiving to/from all BGP neighbors.
In case of group sub mode in BGP these policies will be used for prefixes send/receiving to/from BGP neighbors within this group
In case of neighbor sub mode in BGP group these policies will be used for prefixes send/receiving to/from particular BGP neighbor
Pay attention that there is no inheritance between policies. Only one export and one import policy will be used (for all address families), meaning that actions from only one policy per destination will be applied to the prefix. The order of applying is from more specific to less specific:
neighbor’s import/export policy;
group’s import/export policy;
global BGP’s import/export policy.
Due to the fact that only one policy is used, you should be very careful with filtering what and how you want to announce.
There is also possibility to influence path attributes of outgoing prefixes in Nokia (Alcatel-Lucent) SR OS by configuring certain parameters under group or neighbor configuration sub modes.
Route policy in Cisco IOS XR
Contemporary to Nokia (Alcatel-Lucent) SR OS, Cisco IOS XR has strong decoupling between:
population of Loc-RIB by local routes;
filtering prefixes and manipulation their attributes during sending/receiving them to BGP peers;
filtering what should be installed in routing table.
One way of population of Loc-RIB in BGP is done via redistributing with route-policy or with network statement. Another way is via getting prefixes from BGP neighbor. In this case you can use ingress route policy for filtering routes and modification of their path attributes before adding them to Loc-RIB. Such route policy is applied per neighbor (or per group of neighbors) per address-family.
If the prefix is got from BGP neighbor, after installing it in BGP Loc-RIB it will be analyzed in order to be installed in routing table. Here filtering can be done using table-map route policy. If it satisfies criteria and it is the best route, it will be installed in routing table then.
Best routes are also advertised to BGP neighbors. The egress policy route is used for filtering and modification of path attributes for routes being advertised. Such route policy is also applied per neighbor (or per group of neighbors) per address-family.
On the examples further (during configuration of IPv6 unicast address family or upon traffic engineering) pay attention to the differences in configuration of route-polices.
BGP connectivity IPv6 unicast
So far we have reviewed IPv4 unicast operation of BGP and how in general route policies work. Both these knowledge are necessary for us right now in order to configure IPv6 unicast address family. We’ll configure it simultaneously for all BGP peering (internal and external). The task is the same of what we have in IPv4 in terms of policies and peering.
Before we proceed with the configuration, just briefly review one important point. BGP peering is established over TCP session. For TCP session some IP addresses are used (we have used IPv4 in the part above). So you have two options how to add IPv6 routing to BGP:
Add IPv6 unicast address family to existing IPv4 peering. In this case you have to manipulate next-hop with route policies, as it isn’t adjusted automatically.
Establish new TCP session (new BGP neighbor) between IPv6 addresses for IPv6 unicast address family
Both of these options have advantages and drawbacks. The first option reduces the number of sessions, but increase complexity of route policies for next hop control. The second option makes IPv4 and IPv6 completely independent, but increases the number of sessions that need to be managed.
In our task we’ll configure separate IPv6 peering for external BGP and reuse existing IPv4 peering for internal BGP applying appropriate route maps.
Pay attention that adding new address family to existing BGP peering leads to reestablishment of the peering for IPv4 unicast address family as well. Be very careful upon configuring it in production network.
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>router>policy-options# info
———————–
prefix-list “PL_IPV6_LO1”
prefix 2001:db8:192:1::/64 exact
exit
prefix-list “PL_IPV6_ALL_ADDRESSES”
prefix ::/0 through 128
exit
policy-statement “RP_IPV4_AS65000_LO1_TO_BGP”
entry 15
from
protocol direct
prefix-list “PL_IPV6_LO1”
exit
action accept
next-hop fc00::10:0:255:11
exit
exit
entry 16
from
protocol bgp
prefix-list “PL_IPV6_ALL_ADDRESSES”
exit
action accept
next-hop fc00::10:0:255:11
exit
exit
exit
policy-statement “RP_IPV6_eBGP_OUT”
entry 10
from
protocol direct
prefix-list “PL_IPV6_LO1”
exit
action accept
exit
exit
entry 20
from
protocol bgp
prefix-list “PL_IPV6_ALL_ADDRESSES”
exit
action accept
exit
exit
exit
———————–
A:SR1>config>router# info
———————–
bgp
group “iBGP”
neighbor 10.0.255.33
family ipv4 ipv6
exit
exit
group “v6_eBGP”
family ipv6
authentication-key Int3r_@$
export “RP_IPV6_eBGP_OUT”
neighbor 2001:db8:192:ffff::1
local-as 65535 no-prepend-global-as
peer-as 65100
exit
neighbor 2001:db8:192:ffff::3
peer-as 65200
exit
exit
exit
———————–
RP/0/0/CPU0:XR1(config)#show conf
!
route-policy RP_IPV6_BGP_NHS
set next-hop fc00::10:0:255:22
end-policy
!
route-policy RP_IPV6_AS65000_LO1_TO_BGP
if destination in (2001:db8:192:2::/64) then
pass
endif
end-policy
!
router bgp 65000
address-family ipv6 unicast
redistribute connected route-policy RP_IPV6_AS65000_LO1_TO_BGP
!
neighbor 10.0.255.33
address-family ipv6 unicast
route-policy RP_IPV6_BGP_NHS out
!
!
neighbor 2001:db8:192:ffff::5
remote-as 65200
password Int3r_@$
address-family ipv6 unicast
route-policy PASSALL in
route-policy PASSALL out
!
!
!
end
SR3
E65100 (vrf at XR1)
*A:SR3>config>router>policy-options# info
———————–
prefix-list “PL_IPV6_LO1”
prefix 2001:db8:192:3::/64 exact
exit
policy-statement “RP_IPV4_AS65000_LO1_TO_BGP”
entry 15
from
protocol direct
prefix-list “PL_IPV6_LO1”
exit
action accept
next-hop fc00::10:0:255:33
exit
exit
exit
———————–
A:SR3>config>router# info
———————–
bgp
group “iBGP”
neighbor 10.0.255.11
family ipv4 ipv6
exit
neighbor 10.0.255.22
family ipv4 ipv6
exit
exit
exit
———————–
*A:SR3>config>router>policy-options# info
———————–
prefix-list “PL_IPV6_LO65200”
prefix 2001:db8:198:51::/64 exact
exit
policy-statement RP_IPV6_AS65200
default-action reject
entry 10
from
protocol direct
prefix-list “PL_IPV6_LO65200”
exit
action accept
exit
exit
entry 20
from
protocol bgp
exit
action accept
exit
exit
exit
———————–
A:SR3>config>service# info
———————–
vprn 65200
bgp
group “v6_eBGP”
export “RP_IPV6_AS65200”
neighbor 2001:db8:192:FFFF::2
peer-as 65000
family ipv6
authentication-key Int3r_@$
exit
neighbor 2001:db8:192:FFFF::4
peer-as 65000
family ipv6
authentication-key Int3r_@$
exit
neighbor 2001:db8:198:FFFF::1
peer-as 65100
family ipv6
authentication-key Int3r_@$
exit
exit
exit
exit
———————–
The configuration part was quite long due to bug amount of configuration entries. Stay here for a while, as here you can see the huge difference that was described previously in route policy theory. In Nokia (Alcatel-Lucent) SR OS you have one route policy for all address families per attach point. That’s why we necessary entries in route policy, which was used for IPv4 previously. In Cisco IOS XR you configure route policy per address family separately, and for me it seems easier. Also you can find that besides IPv6 address in neighbor statement, there is no difference in configuration of BGP for IPv6 address family.
During applying of the configuration you will see that IPv6 or IPv4/IPv6 BGP peering comes up:
SR OS:
15 2016/09/14 11:34:22.78 UTC MINOR: BGP #2001 Base Peer 1: 10.0.255.33
“VR 1: Group iBGP: Peer 10.0.255.33: moved into established state”
!
19 2016/09/14 11:35:37.30 UTC MINOR: BGP #2019 Base Peer 1: 2001:db8:192:ffff::1
“VR 1: Group v6_eBGP: Peer 2001:db8:192:ffff::1: moved into established state”
!
!
IOS XR:
RP/0/0/CPU0:Jun 18 06:06:14.107 : bgp[1053]: %ROUTING-BGP-5-ADJCHANGE_DETAIL : neighbor 10.0.255.33 Up (VRF: default; AFI/SAFI: 1/1, 2/1) (AS: 65000)
!
RP/0/0/CPU0:Jun 18 06:12:00.334 : bgp[1053]: %ROUTING-BGP-5-ADJCHANGE_DETAIL : neighbor 2001:db8:192:ffff::5 Up (VRF: default; AFI/SAFI: 2/1) (AS: 65200)
For IPv4 AFI (Address Family Indicator) is 1 and for IPv6 AFI is 2. SAFI (Sub Address Family Indicator) 2 means “unicast”. For more information attend to IANA
Pay attention that Nokia (Alcatel-Lucent) VSR (SR 7750) doesn’t tell you for which AFI/SAFI the neighboring comes up. You can check it in the BGP summary table:
At the output above with the bold marked the follofing:
BGP peering between SR1 and SR3 for IPv4 and IPv6 unicast is built on top of IPv4 session. So there is one TCP session for which two AFI/SAFI groups are negotiated
BGP peering between SR1 and E65100 consists of two different TCP sessions (actually there are two different BGP neighbors), where each session is used for only one AFI/SAFI.
In Cisco IOS XR the BGP summary table is built per AFI/SAFI, so you should use two commands to check it:
Next important part of network operation (and for IPv6 as well) is RIB. Let’s see what we have there at Nokia (Alcatel-Lucent) SR OS router in routing table:
A:SR1# show router route-table ipv6 protocol bgp
============================================================================
IPv6 Route Table (Router: Base)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
2001:db8:192:2::/64 Remote BGP 00h07m06s 170
fe80::3:1301-“toXR1” 0
2001:db8:192:3::/64 Remote BGP 00h28m15s 170
fe80::2:1101-“toSR3” 0
2001:db8:198:51::/64 Remote BGP 00h00m00s 170
fe80::3:1301-“toXR1” 0
2001:db8:203::/64 Remote BGP 00h27m24s 170
2001:db8:192:ffff::1 0
—————————————————————————-
No. of Routes: 4
Take a look at next-hop field. It’s resolved to IPv6 link local address of the peer, if the prefix is learned from internal BGP (iBGP) neighbor. Nevertheless in BGP RIB you see original next hop, what is advertised by neighbor:
A:SR1# show router bgp routes ipv6 2001:db8:192:2::/64
============================================================================
BGP Router ID:10.0.255.11 AS:65000 Local AS:65000
============================================================================
Legend –
Status codes : u – used, s – suppressed, h – history, d – decayed, * – valid
l – leaked
Origin codes : i – IGP, e – EGP, ? – incomplete, > – best, b – backup
============================================================================
BGP IPv6 Routes
============================================================================
Flag Network LocalPref MED
. Nexthop (Router) Path-Id Label
. As-Path
—————————————————————————- u*>? 2001:db8:192:2::/64 100 0 . fc00::10:0:255:22 None – . No As-Path
? 2001:db8:192:2::/64 None None
. 2001:db8:192:ffff::3 None –
. 65200 65000
? 2001:db8:192:2::/64 None None
. 2001:db8:192:ffff::1 None –
. 65100 65535
—————————————————————————-
Routes : 3
So Nokia (Alcatel-Lucent) SR OS automatically makes RIB optimization in order to improve packet forwarding and simplify RIB/FIB lookup. If we’ll take a look into FIB, what is actually used for traffic forwarding, you’ll see the same picture in terms of next hop:
RP/0/0/CPU0:XR1# show route ipv6 bgp
B 2001:db8:192:1::/64
[200/0] via fc00::10:0:255:11, 00:02:27
B 2001:db8:192:3::/64
[200/0] via fc00::10:0:255:33, 00:02:27
B 2001:db8:198:51::/64
[20/0] via 2001:db8:192:ffff::5, 00:01:18
B 2001:db8:203::/64
[20/0] via 2001:db8:192:ffff::5, 00:01:18
You see that next hop in routing table is just the same as it’s in BGP RIB:
RP/0/0/CPU0:XR1# show bgp ipv6 unicast 2001:db8:192:3::/64
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
2001:db8:192:ffff::5
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
2001:db8:192:ffff::5
Local
fc00::10:0:255:33 (metric 10) from 10.0.255.33 (10.0.255.33)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 14
Nevertheless Cisco IOS XR makes the FIB optimization as well, where you see actual information for packet forwarding:
RP/0/0/CPU0:XR1#show cef ipv6 2001:db8:192:3::/64 detail
2001:db8:192:3::/64, version 462, internal 0x5000001 0x0 (ptr 0xa13e14f4) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jun 18 09:50:47.825
local adjacency fe80::2:1201
Prefix Len 64, traffic index 0, precedence n/a, priority 4
gateway array (0xa12753ac) reference count 1, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x48501 (0xa13100f4) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Jun 18 09:50:47.825
LDI Update time Jun 18 09:50:47.825
via fc00::10:0:255:33/128, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa13e1274 0x0] next hop fc00::10:0:255:33/128 via fc00::10:0:255:33/128
Load distribution: 0 (refcount 1) Hash OK Interface Address 0 Y GigabitEthernet0/0/0/0.12 fe80::2:1201
In order to reduce the length of the article I don’t provide the output of ping tests. You can perform them yourself. Don’t forget to mention correct source, which is advertised via BGP.
Prefix aggregation in BGP
Usually you don’t want that external neighbors see the details of your network. Another important point here is that the there is strict regulation in Internet routing, what states that the maximum prefix length in Internet routing table must be 24. All routes with longer prefixes must be aggregated at least to /24 subnet. Let’s advertise from SR1 (Nokia (Alcatel-Lucent) SR OS) and XR1 (Cisco IOS XR) only aggregated IPv4 192.0.2.0/24 and IPv6 2001:db8:192::/48 prefixes to their external BGP (eBGP) neighbors:
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>router>policy-options# info
———————–
prefix-list PL_IPV4_AGG_AS65000
prefix 192.0.2.0/24
exit
prefix-list PL_IPV4_FILT_AS65000
prefix 192.0.2.0/24 through 32
exit
prefix-list PL_IPV6_AGG_AS65000
prefix 2001:DB8:192::/48
exit
prefix-list PL_IPV6_FILT_AS65000
prefix 2001:DB8:192::/48 through 128
exit
policy-statement RP_IPV4_eBGP_OUT
default-action reject
entry 10
from
prefix-list “PL_IPV4_AGG_AS65000”
protocol aggregate
exit
action accept
exit
exit
entry 20
from
prefix-list “PL_IPV4_FILT_AS65000”
exit
action reject
exit
entry 30
from
protocol bgp
exit
action accept
exit
exit
exit
policy-statement RP_IPV6_eBGP_OUT
default-action reject
entry 10
from
prefix-list “PL_IPV6_AGG_AS65000”
protocol aggregate
exit
action accept
exit
exit
entry 20
from
prefix-list “PL_IPV6_FILT_AS65000”
no protocol
exit
action reject
exit
entry 30
from
protocol bgp
exit
action accept
exit
exit
exit
policy-statement “RP_IPV4_AS65000_LO1_TO_BGP”
entry 11
from
prefix-list “PL_IPV4_AGG_AS65000”
protocol aggregate
exit
action accept
exit
exit
entry 17
from
prefix-list “PL_IPV6_AGG_AS65000”
protocol aggregate
exit
action accept
exit
exit
exit
———————–
*A:SR1>config>router# info
———————–
aggregate 192.0.2.0/24
aggregate 2001:db8:192::/48
bgp
group “eBGP”
export “RP_IPV4_eBGP_OUT”
exit
group “v6_eBGP”
export “RP_IPV6_eBGP_OUT”
exit
exit
RP/0/0/CPU0:XR1(config)#show conf
!
route-policy RP_IPV4_BGP_ONLY_AGG
if destination in (192.0.2.0/24 ge 25 le 32) then
drop
else
pass
endif
end-policy
!
route-policy RP_IPV6_BGP_ONLY_AGG
if destination in (2001:db8:192::/48 ge 49 le 128) then
drop
else
pass
endif
end-policy
!
router bgp 65000
address-family ipv4 unicast
aggregate-address 192.0.2.0/24
!
address-family ipv6 unicast
aggregate-address 2001:db8:192::/48
!
neighbor 192.0.2.255
address-family ipv4 unicast
route-policy RP_IPV4_BGP_ONLY_AGG out
!
!
neighbor 2001:db8:192:ffff::5
address-family ipv6 unicast
route-policy RP_IPV6_BGP_ONLY_AGG out
!
!
!
end
Both Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR have possibility to add key “summary-only” to aggregation command. It will effectively filter from announcement all routes that fit aggregation subnet and therefore only aggregated route will be announced. It will filter also actual Lo1 prefix from advertisement to iBGP neighbors and will create partial traffic drop (when traffic to Lo1 of SR1 will come to XR1, for example). In our case we don’t want it, so we don’t issue it. Also pay attention that in Nokia (Alcatel-Lucent) SR OS you choose “protocol aggregate”, which differs from the protocol that you have used before.
Let’s check the routing tables at E65100 (vrf at XR1) before implementing the configuration above and after that:
Before aggregation at SR1/XR1:
RP/0/0/CPU0:XR1#show route vrf E65100 ipv4 bgp
B 192.0.2.0/26 [20/0] via 192.0.2.250, 00:09:25
B 192.0.2.64/26 [20/0] via 192.0.2.250, 00:08:57
B 192.0.2.128/26 [20/0] via 192.0.2.250, 00:09:25
B 198.51.100.0/25 [20/0] via 198.51.100.254, 00:08:57
!
RP/0/0/CPU0:XR1#show route vrf E65100 ipv6 bgp
B 2001:db8:192:1::/64
[20/0] via 2001:db8:192:ffff::, 00:09:39
B 2001:db8:192:2::/64
[20/0] via 2001:db8:192:ffff::, 00:09:12
B 2001:db8:192:3::/64
[20/0] via 2001:db8:192:ffff::, 00:09:39
B 2001:db8:198:51::/64
[20/0] via 2001:db8:198:ffff::, 00:08:22
!
!
After aggregation at SR1/XR1:
RP/0/0/CPU0:XR1#show route vrf E65100 ipv4 bgp
B 192.0.2.0/24 [20/0] via 192.0.2.250, 00:02:50
B 198.51.100.0/25 [20/0] via 198.51.100.254, 00:25:29
!
RP/0/0/CPU0:XR1#show route vrf E65100 ipv6 bgp
B 2001:db8:192::/48
[20/0] via 2001:db8:192:ffff::, 00:03:12
B 2001:db8:198:51::/64
[20/0] via 2001:db8:198:ffff::, 00:24:59
The same picture you can observe at 65200 (VPRN at SR3):
Before aggregation at SR1/XR1:
A:SR3# show router 65200 route-table ipv4 protocol bgp
============================================================================
Route Table (Service: 65200)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
192.0.2.0/26 Remote BGP 00h10m57s 170
192.0.2.252 0
192.0.2.64/26 Remote BGP 00h09m58s 170
192.0.2.252 0
192.0.2.128/26 Remote BGP 00h10m26s 170
192.0.2.252 0
203.0.113.0/24 Remote BGP 00h10m34s 170
198.51.100.255 0
—————————————————————————-
No. of Routes: 4
!
A:SR3# show router 65200 route-table ipv6 protocol bgp
============================================================================
IPv6 Route Table (Service: 65200)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
2001:db8:192:1::/64 Remote BGP 00h11m40s 170
2001:db8:192:ffff::2 0
2001:db8:192:2::/64 Remote BGP 00h10m36s 170
2001:db8:192:ffff::2 0
2001:db8:192:3::/64 Remote BGP 00h11m09s 170
2001:db8:192:ffff::2 0
2001:db8:203::/64 Remote BGP 00h10m31s 170
2001:db8:198:ffff::1 0
—————————————————————————-
No. of Routes: 4
!
!
After aggregation at SR1/XR1:
A:SR3# show router 65200 route-table ipv4 protocol bgp
============================================================================
Route Table (Service: 65200)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
192.0.2.0/24 Remote BGP 00h02m45s 170
192.0.2.254 0
203.0.113.0/24 Remote BGP 00h17m49s 170
198.51.100.255 0
—————————————————————————-
No. of Routes: 2
!
A:SR3# show router 65200 route-table ipv6 protocol bgp
===============================================================================
IPv6 Route Table (Service: 65200)
=============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
2001:db8:192::/48 Remote BGP 00h12m01s 170
2001:db8:192:ffff::4 0
2001:db8:203::/64 Remote BGP 00h25m47s 170
2001:db8:198:ffff::1 0
—————————————————————————
No. of Routes: 2
You can see that right now only the aggregated routes (one for IPv4 and one for IPv6) present in routing table at external BGP (eBGP) neighbors for AS 65000, whereas at SR3, which is internal BGP (iBGP) neighbor, you see both aggregated routes and original Lo1 prefixes from SR1 and XR1.
A:SR3# show router route-table ipv4 protocol bgp
============================================================================
Route Table (Router: Base)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————
192.0.2.0/24 Remote BGP 00h15m07s 170
10.0.0.3 0
192.0.2.0/26 Remote BGP 00h04m23s 170
10.0.0.0 0
192.0.2.64/26 Remote BGP 00h27m50s 170
10.0.0.3 0
198.51.100.0/25 Remote BGP 00h04m23s 170
10.0.0.0 0
203.0.113.0/24 Remote BGP 00h04m23s 170
10.0.0.0 0
—————————————————————————-
No. of Routes: 5
!
A:SR3# show router route-table ipv6 protocol bgp
===============================================================================
IPv6 Route Table (Router: Base)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
2001:db8:192::/48 Remote BGP 00h15m54s 170
fe80::3:1201-“toXR1” 0
2001:db8:192:1::/64 Remote BGP 00h05m11s 170
fe80::1:1101-“toSR1” 0
2001:db8:192:2::/64 Remote BGP 00h28m37s 170
fe80::3:1201-“toXR1” 0
2001:db8:198:51::/64 Remote BGP 00h05m11s 170
fe80::1:1101-“toSR1” 0
2001:db8:203::/64 Remote BGP 00h05m11s 170
fe80::1:1101-“toSR1” 0
—————————————————————————-
No. of Routes: 5
BGP path selection algorithm
BGP has a numerous path attributes that influence selection of the best route, which is installed in the routing table. These attributes are processed in the strict order, described in RFC4271.
In addition to RFC Cisco IOS XR (as well as Cisco IOS, IOS XE and NX-OS) has two more steps. The very first step in Cisco IOS XR called “weight”, what is Cisco-specific path attributes. This attribute is set to 32768 to routes that is originated by route (via network, redistribution or aggregation) and 0 to routes learned from BGP neighbors. The route with the biggest numerical number is chosen as the best one. Weight is local to the router and isn’t advertised to the peers.
Another Cisco-specific step is called “Locally originated”. Cisco IOS XR prefers routes that are originated locally to routes learned from neighbors. This step comes between local-preference and AS_PATH. Take a look at Cisco BGP path selection attribute.
Each of BGP path attributes can be installed with route-policy either in incoming or outgoing direction. Make yourself feel comfortable with this algorithm in order to understand why certain routes are chosen as the best one.
To show the example of this algorithm we’ll configure the following routing policy in AS 65000:
All traffic destined to AS 65200 must pass link between XR1 and 65200 (VPRN at SR3).
All traffic destined to AS 65100 must pass link between SR1 and E65100 (VRF at XR1).
To achieve the desired task we need to apply the following configuration to our routers:
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>router>policy-options# info
———————–
as-path “FROM_AS65100” expression “^65100$”
policy-statement “RP_eBGP_AS65100_IN”
entry 10
from
as-path “FROM_AS65100”
exit
action accept
local-preference 200
exit
exit
default-action accept
exit
exit
———————–
*A:SR1>config>router# info
———————–
bgp
group “eBGP”
neighbor 192.0.2.251
import “RP_eBGP_AS65100_IN”
exit
exit
group “v6_eBGP”
neighbor 2001:db8:192:ffff::1
import “RP_eBGP_AS65100_IN”
exit
exit
exit
RP/0/0/CPU0:XR1(config)#show conf
!
route-policy RP_eBGP_AS65200_IN
if as-path in (ios-regex ‘^65200$’) then
set local-preference 200
else
pass
endif
end-policy
!
router bgp 65000
neighbor 192.0.2.255
address-family ipv4 unicast
route-policy RP_eBGP_AS65200_IN in
!
!
neighbor 2001:db8:192:ffff::5
address-family ipv6 unicast
route-policy RP_eBGP_AS65200_IN in
!
!
!
end
What we are doing in these route policies is filtering increasing the local-preference BGP path attribute of the prefixes are originated in neighboring AS based on the task above. Let’s check the routing table at Nokia (Alcatel-Lucent) SR OS router SR1 for BGP routes:
A:SR1# show router route-table ipv4 198.51.100.0/25
============================================================================
Route Table (Router: Base)
============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
—————————————————————————-
198.51.100.0/25 Remote BGP 00h06m38s 170
10.0.0.5 0
—————————————————————————-
No. of Routes: 1
You see that now route to IPv4 prefix 198.51.100.0/25 points to XR1, though it has a direct link to AS 65200. In BGP RIB at SR1 you can see that there are several possible next hops for IPv4 prefix 198.51.100.0/24 and the best one is chosen by the highest local preference:
The same picture for prefixes from AS 65100 you can see at Cisco IOS XR:
RP/0/0/CPU0:XR1#show route ipv6 bgp
B 2001:db8:192::/48
[200/0] via ::, 00:26:19, Null0
B 2001:db8:192:1::/64
[200/0] via fc00::10:0:255:11, 00:38:35
B 2001:db8:192:3::/64
[200/0] via fc00::10:0:255:33, 00:38:35
B 2001:db8:198:51::/64
[20/0] via 2001:db8:192:ffff::5, 00:08:31 B 2001:db8:203::/64 [200/0] via fc00::10:0:255:11, 00:03:23!
!
RP/0/0/CPU0:XR1#show bgp ipv6 unicast 2001:db8:203::/64
Paths: (2 available, best #1)
Advertised to peers (in unique update groups):
2001:db8:192:ffff::5
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
2001:db8:192:ffff::5
65535 65100 fc00::10:0:255:11 (metric 10) from 10.0.255.33 (10.0.255.11) Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 20
Originator: 10.0.255.11, Cluster list: 10.0.255.33
Path #2: Received by speaker 0
Not advertised to any peer
65200 65100
2001:db8:192:ffff::5 from 2001:db8:192:ffff::5 (198.51.100.1)
Origin IGP, localpref 100, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Local-preference is applied usually to the incoming route updated and influences the egress traffic from your network. You can see that in routing table of 65200 IPv4 prefix 192.0.2.0/24 is accessible via oldest stable route:
To influence ingress traffic from the peering AS to your network other path attributes must be used (AS_PATH prepending, ORIGIN or MED) with route-policy in outbound direction. Usually AS_PATH manipulation is used, because it’s the strongest path attribute across all the rest. I won’t provide any example here, but in the next session you will see the example how else it’s possible to influence.
BGP Communities
BGP has very powerful tool for traffic engineering (and not only) that is called communities. In a few words we can describe BGP community as a tag, which is added to certain routes, when they are advertised to the neighbors. On the receiving side you can match routes by this tag and apply necessary actions. It’s much more convenient than matching routes solely by IPv4/IPv6 prefix, because you can create more flexible and simple route policies.
In Cisco IOS XR you can set community also during redistribution of routes into Loc-RIB from routing table.
There are two main different types of communities: standard and extended. Extended communities are used for all types of BGP/MPLS VPN solutions (both L2 and L3). The most widely used extended community is route-target, which is corner stone of BGP/MPLS VPN. Standard communities are used for all types of address families and don’t have any specific function. So their use is totally up to engineers.
In this article I’ll cover one example of using standard community path attribute. This application is described in RFC1998 and provides the way for the customer to influence incoming traffic for the customer.
This RFC isn’t mandatory so it might be not implemented by your peering BGP AS. Check with your ISP if it’s implemented and how it’s implemented, before making any configuration in live network!
To make it shorter, mentioned RFC provides the way of setting the local-preference based matching standard community in ingress route-policy. In such a way customer can influence how traffic from its ISP should come into customer’s network. So it’s possibly to perform maintenance work at routers without any traffic disruption by smoothly rerouting the traffic between your routers.
We’ll implement the following routing policy at E65100 and 65200:
Prefixes coming with community x:60 become local-preference 60;
Prefixes coming with community x:70 become local-preference 70;
Prefixes coming with community x:80 become local-preference 80;
Prefixes coming with community x:90 become local-preference 90;
*A:SR3>config>router>policy-options# info
———————–
community “CL_COM_TO_LP_60” members “.*:60$”
community “CL_COM_TO_LP_70” members “.*:70$”
community “CL_COM_TO_LP_80” members “.*:80$”
community “CL_COM_TO_LP_90” members “.*:90$”
policy-statement “RP_RFC1998_eBGP_IN”
entry 10
from
community “CL_COM_TO_LP_60”
exit
action accept
local-preference 60
exit
exit
entry 20
from
community “CL_COM_TO_LP_70”
exit
action accept
local-preference 70
exit
exit
entry 30
from
community “CL_COM_TO_LP_80”
exit
action accept
local-preference 80
exit
exit
entry 40
from
community “CL_COM_TO_LP_90”
exit
action accept
local-preference 90
exit
exit
default-action accept
exit
exit
———————–
*A:SR3>config>service# info
———————–
vprn 6500
bgp
group “eBGP”
import “RP_RFC1998_eBGP_IN”
exit
group “v6_eBGP”
import “RP_RFC1998_eBGP_IN”
exit
exit
exit
RP/0/0/CPU0:XR1(config)#show conf
!
route-policy RP_RFC1998_eBGP_IN
if community matches-any (ios-regex ‘.*:60$’) then
set local-preference 60
elseif community matches-any (ios-regex ‘.*:70$’) then
set local-preference 70
elseif community matches-any (ios-regex ‘.*:80$’) then
set local-preference 80
elseif community matches-any (ios-regex ‘.*:90$’) then
set local-preference 90
else
pass
endif
end-policy
!
router bgp 65000
vrf E65100
neighbor 192.0.2.250
address-family ipv4 unicast
send-community-ebgp
route-policy RP_RFC1998_eBGP_IN in
!
!
neighbor 2001:db8:192:ffff::
address-family ipv6 unicast
send-community-ebgp
route-policy RP_RFC1998_eBGP_IN in
!
!
neighbor 198.51.100.254
address-family ipv4 unicast
send-community-ebgp
route-policy RP_RFC1998_eBGP_IN in
!
!
neighbor 2001:db8:198:ffff::
address-family ipv6 unicast
send-community-ebgp
route-policy RP_RFC1998_eBGP_IN in
!
!
!
!
end
In Nokia (Alcatel-Lucent) SR OS sending and receiving of communities is configured by default. Cisco IOS XR sends community to iBGP neighbors by default, and for eBGP neighbors you have to configure it explicitly. In order to check whether our solution work, let’s configure the distribution of IPv4 aggregate route from AS 65000 with community 65000:60 from SR1 and 65000:80 from XR1:
Nokia (Alcatel-Lucent) VSR (SR 7750)
Cisco IOS XR (ASR 9000)
SR1
XR1
*A:SR1>config>router>policy-options# info
———————–
community “65000:60” member “65000:60”
policy-statement “RP_IPV4_eBGP_OUT”
entry 10
action accept
community add “65000:60”
exit
exit
exit
RP/0/0/CPU0:XR1(config)#show conf
!
route-policy RP_eBGP_AS65200_IN
if as-path in (ios-regex ‘^65200$’) then
set local-preference 200
else
pass
endif
end-policy
!
router bgp 65000
neighbor 192.0.2.255
address-family ipv4 unicast
route-policy RP_eBGP_AS65200_IN in
!
!
neighbor 2001:db8:192:ffff::5
address-family ipv6 unicast
route-policy RP_eBGP_AS65200_IN in
!
!
!
end
Pay attention that in Nokia (Alcatel-Lucent) SR OS you configure community entry and in route-policy you mention that entry. In the case above they are the same but the first “65000:60” is name of the entry and the latter is the actual numeric value of the community.
You can see that the traffic to IPv4 prefix 192.0.2.0/24 will be sent to XR1 now and this decision is precise (not sporadic):
In the details of this prefix you see how local preference is changed based in the community value:
A:SR3# show router 65200 bgp routes ipv4 192.0.2.0/24 detail | match expression “Comm|Local|Original|Modified”
BGP Router ID:198.51.100.1 AS:65200 Local AS:65200
Original Attributes
Local Pref. : n/a Interface Name : toXR1_65000
Community : 65000:80
Last Modified : 00h27m02s
Modified Attributes
Local Pref. : 80 Interface Name : toXR1_65000
Community : 65000:80
Last Modified : 00h27m02s
Original Attributes
Local Pref. : n/a Interface Name : toSR1_65000
Community : 65000:60
TieBreakReason : LocalPref
Last Modified : 00h14m13s
Modified Attributes
Local Pref. : 60 Interface Name : toSR1_65000
Community : 65000:60
TieBreakReason : LocalPref
Last Modified : 00h14m13s
Original Attributes
Local Pref. : n/a Interface Name : toE65100
Community : 65000:60
Last Modified : 00h07m07s
Modified Attributes
Local Pref. : 60 Interface Name : toE65100
Community : 65000:60
Last Modified : 00h07m07s
In general from E65100 traffic to 192.0.2.0/24 should go through 65200 (VPRN at SR3), but due to the fact that it’s just VRF with parent BGP process in AS 65000, it just drops routes originated in AS 65000, therefore advertisement from 65200 is dropped at E65100.
The main lessons learned for me was the difficulty to make the article compact. There are lots of interesting books about BGP written by Alcatel-Lucent, Cisco, Juniper and other vendors that in depth explain the operation of the protocol and configuration in that vendor’s OS. I advise you to find any book with BGP theory and then attend to my article if you have difficulties with BGP theory.
Conclusion
BGP is very good and useful protocol in modern network. In SDN environment it even tends to remove all other routing protocols due to its unprecedented flexibility caused by path attributes and address families. Probably my review was quite brief, but my target isn’t teaching you BGP basics. I want to share with you configuration pattern from basic to advanced level in multi vendor environment. In my series in the future I’ll cover other BGP features that also very useful and used in current networks. Take care and good bye.
