Hello my friend,
I wanted to write about AIGP for a long time but for some reasons I’ve postponed this article many times. Logically it’s related to seamless MPLS and intra AS VPN option C as it deals with complex BGP topologies. Well, it’s better to do it later than never.
1 2 3 4 5 | No part of this blogpost could be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical or photocopying, recording, or otherwise, for commercial purposes without the prior permission of the author. |
Brief overview
When you connect networks (especially in different ASes) by mean of BGP you lose the visibility of the internal routing in the adjacent network. In many cases it’s desirable as you can want to influence the traffic by the mean of the policies rather than allow it automatically chose the path. But if we speak about seamless MPLS deployments, where all parts of the network in your hands, it’s preferable to has such type of visibility.
AIGP allows BGP to add copy from IGP the metric to the BGP next-hop in the specific field (new PATH ATTRIBUTE – AIGP) and advertise it to the BGP peer. This attribute is transitive, meaning that is sent across AS boundaries, so that you can chose the better path inside the AS being outside of it. Though it might look like a distance vector approach, it’s better than nothing. Let’s see in the details
What are we going to test?
We’ll see the case, where we have suboptimal routing due to BGP being used to interconnect two ASes. Then I’ll show how AIGP helps to solve this issue.
Topology
We need at least four routers in order to test this feature. The good news that we have them with our standard physical topology:
With usage of VRFs/VPRNs we can reduce the amount of used device even to two, but their configuration will be much more complex then. For more information, refer to BGP article, where I’ve used already such approach.
The logical topology isn’t something very specific, as we have used it many times already:
Some description is worth to be done. The most important configuration is done at ASBRs as they have behavior changed from the default. Keeping in mind that we speak about seamless MPLS deployment, the prefixes are completely filtered between level 1 and level 2 as well as attached bit isn’t send in L1 LSPs. So, without BGP Nokia (Alcatel-Lucent) SR OS router SR1 has no single possibility to reach XR4, as well as XR4 doesn’t have any routes towards SR1. In Nokia (Alcatel-Lucent) SR OS we use standard route-policy, whereas in Cisco IOS XR we utilize specific command.
If you are not confident with route policies, I advise you read one of the recent articles.
At Nokia (Alcatel-Lucent) VSR we also add the possibility to advertise inactive BGP routes (it isn’t done by default). It’s necessary, because ISIS is more preferable routing protocol than BGP by default and SR2 has both SR1 system interface and XR4 loopback from ISIS.
At XR3, which is Cisco XRv 9000 router, we change the administrative distance for BGP as by default eBGP is more preferable than ISIS, what leads to the route flapping indicated by the following message:
|
RP/0/0/CPU0:XR3#RP/0/0/CPU0:Jun 6 10:54:05.191 : ipv4_rib[1147]: %ROUTING-RIB-7-SERVER_ROUTING_DEPTH : Recursion loop looking up prefix 10.1.255.1 in Vrf: “default” Tbl: “default” Safi: “Unicast” added by bgp |
Also we have added at Nokia (Alcatel-Lucent) SR OS devices support of ECMP and BGP multipath (the last one is also configured in Cisco IOS XRv) so that we can benefit of multiple routes, because by default these features are disabled.
At the beginning all the links have the same costs in IGP that is 10, but we’ll change cost at the several links later in order to show the hidden problems with inter-region BGP.
In the attachment you can find the initial configuration for the lab. It will help you to save the time, because the configuration is quite big:
Topology check
Configuration of new features is always exciting and interesting. But as says a lot of managers I’m dealing with currently “we need to be pragmatic”. It means that we need to understand, why we need this new feature and which problem it solves. Let’s check the routing table at Nokia SR OS router SR1::
|
A:SR1# show router route-table |
We see that SR1 has two BGP routes for loopback 0 IPv4 address of XR4. In the back direction we have the same picture at XR4 Cisco IOS XRv 9000 router:
|
RP/0/0/CPU0:XR4#show route ipv4 |
Brief test shows that SR1 and XR4 can reach each other:
|
RP/0/0/CPU0:XR4# traceroute 10.1.255.1 so 10.0.255.4 |
The actual path is chosen based on the hashing algorithm inside the platform, but you see that XR4 send the packets to SR1 over XR3 and in the back direction SR1 prefers to send packets to XR4 over SR2. Anyhow it works and let’s add some mess.
We change the topology so that it isn’t symmetric anymore. We increase the ISIS costs of the links in the following manner:
- SR1-XR3 cost is 100
- SR2-XR4 cost is 50
The IGP topology looks like a bit different now:
If our routers have a routes leaked between the ISIS levels at both our ASBRs (Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR), they will clearly chose SR1-XR. The configuration to achieve this is relatively easy.:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
What do we have no in the routing tables? Nokia (Alcatel-Lucent) SR OS router SR1 clearly chose one path over another one and explains why:
|
A:SR1# show router bgp routes 10.0.255.4 detail | match expression “^Network|^Next|^Tie” |
So the route from SR1 to XR4 is chosen over SR2, because it has a lower metric to its BGP next hop than XR3 does.
Cisco IOS XRv behavior is much more strange in this situation:
|
RP/0/0/CPU0:XR4#show bgp ipv4 unicast 10.1.255.1/32 |
Though XR4 understand that there is different metric to BGP next-hop, it still considers routes as equal and installs both of them into FIB:
|
RP/0/0/CPU0:XR4#show cef ipv4 10.1.255.1/32 |
After some playing with different types of multipathing, it seems to be that probably there is some bug, because if I change the type of multipathing to ibgp only (or for ebgp, but it isn’t our case), only one route is chosen:
|
RP/0/0/CPU0:XR4(config-bgp-af)#no maximum-paths eibgp 2 |
No we have the suboptimal routing, where path from SR1 to XR4 would have metric 60 in total and metric XR4 to SR1 would have metric 110. But as routers have no knowledge about metric in another level of ISIS, their choice seems the best for them.
Lack of visibility, lack of efficiency.
If there were two different networks, you would have to live with it or use some mechanisms like MED, origin or something else. It’s still an option, but what if the metric may vary based on some conditions (maintenance work, etc) or the topology in general much more complex than mine? You want the mechanism that will automatically update PATH_ATTRIBUTES in BGP update so that it takes into account these IGP issues. Here the AIGP, what stands for Accumulated IGP, comes in play.
AIGP configuration
What AIGP does, is very useful for inter-domain communication. Actually it takes the metric to BGP next hop of prefix (typically from routing table) and adds as new PATH_ATTRIBUTE to the BGP update. If AIGP PATH_ATTRIBUTE already exists, the new value is added to the existing one. That’s why it’s called “accumulated”. Based on that logic it’s similar to distance vector protocol, the only different that not hops but link costs are counted.
The configuration of AIGP is quite simple. You need to enable AIGP for the peer and set AIGP to certain prefixes with route-policy.
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
As soon as we add AIGP into configuration, we see that it’s negotiated:
|
RP/0/0/CPU0:XR4#show bgp ipv4 unicast neighbors 10.0.255.2 | include “^BGP|AIG$ |
Well, that is done. The next step is to trace, how changes AIGP metric of IPv4 prefix “10.1.255.1/32” in the direction from SR1 to XR4:
|
A:SR2# show router bgp routes 10.1.255.1/32 detail | match AIGP |
Point out the following moment regarding AIGP:
In Path-Selection algorithm AIGP is located quite high, just between local-preference and as-path.
You see that at the end, the total AIGP metric reflects all ISIS links cost so that both Cisco IOS XR router XR4 and Nokia (Alcatel-Lucent) SR OS router SR1 has the same path.
Let’s check the output at SR1. The output of BGP routes in Nokia (Alcatel-Lucent) SR OS is a bit long and misleading, beacause it doesn’t show at the end of the day the total AIGP metric, how Cisco IOS XR does. But, and what is more important, it calculates the whole AIGP metric, because it also chose the path XR4 over SR2:
|
A:SR1# show router bgp routes 10.0.255.4/32 detail | match expression “Network|AIGP|Flags|Next” |
That’s it. Now your BGP is smart enough to automatically update AIGP metric so that your inter-domain connectivity becomes more efficient.
Here you can find the final configurations of the device:
Lessons learned
I’ve been quite surprised with load-balancing issue in Cisco IOS XR with “eigbp” option. Brief screening of the command guide doesn’t show any information, so I’d say it’s bug. But we need to be careful so that we don’t get into trouble with this configuration caveat in production network
Conclusion
BGP is one of the most popular and widely used protocol in the world for decades. But contemporary for other old protocols, it is being continuously developed further, with new address families and new features, like AIGP for example. Recently I was asked, which routing protocol I like more than others. You can imagine, for sure it’s BGP. Take care and good bye!
Support us
BR,
Anton Karneliuk
