Hello my friend,
Across my journey in the world of interoperability between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR I’ve many times mentioned route policies. Each time I was doing it in the context of the particular routing protocol, but this time I’m gonna do it for each protocol (or most of them) in the single place.
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. |
Disclaimer
Just two things before we jump into overview.
The first one is that it’s almost impossible to cover all actions and matching criteria of route policies. There are so many possibilities, where they can used, that I even don’t have everything in my mind. But I’ll show you general approach so that you’ll easily deploy required policy, even if you haven’t done it previously.
The second one is the name of the article. It’s inspired by the album “The book of souls” by Iron Maiden, so if you see some similarities, you are right 🙂
Brief overview
Route-policies are really widely used. You meet them when you configure redistribution (export operation in Nokia(Alcatel-Lucent) SR OS), filtering and so on. If we speak about BGP, it’s just impossible to configure this protocol without applying correct route policies in order to filter prefixes and modify path attributes of the routes that are sent to or received from peering router. BGP IP/MPLS VPNs, PIM, LDP… We can continue this list forever.
In general, the logic of route policies is very straightforward: based on some match condition we perform some actions. If you are familiar with scripting or programming, you can think about route policy as an “if-then” condition. Actually, in Cisco IOS XR you configure route policy exactly with “if-then” construction.
In Nokia (Alcatel-Lucent) SR OS you have usually just two points, where you can apply route policy: import or export. Import policy is used between protocol internal data structure (OSPF/ISIS LSDB, LDP/BGP RIB, etc) and routing table, so that import policies filter, what can be installed in route table. In case of BGP import policies are also used for modification of the path attributes in the incoming updates in order to influence best path selection.
In Cisco IOS XR there are other names rather than import/export, but the directions are the same. There is almost no difference in the logic for the import policies comparing to Nokia (Alcatel-Lucent) SR OS, but there is one significant in the “out” direction.
The following table summarizes main facts about route policies
| Route policy | Nokia SR OS | Cisco IOS XR |
| Import | Based on “from” entry perform “accept/drop” action between routing protocol data structure (RIB) and routing table. Route is saved in RIB. | Based on “if” entry perform “set/pass/drop” action between routing protocol data structure (RIB) and routing table. Route is saved in RIB. |
| Export | Based on “entry” entry take route from routing table and perform “accept/drop” action in the direction of protocol RIB and/or neighbor | 1st step is redistribution.
Based on “if” condition take route from routing table and perform “set/pass/drop” action in the direction of protocol RIB. 2nd step is output filtering. Based on “if” condition take route from protocol RIB and perform “set/pass/drop” action in the direction of neighbor. |
What are we going to test?
We will provide the scenario on which one routing protocol (IGP) is taken to export routes learned from multiple sources. Then we’ll explain the similarities and differences in working logic and configuration between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR.
Topology
Physical topology is as usual with two Nokia (Alcatel-Lucent) VSRs and Cisco IOS XRv 9000:
More information on the lab setup could be found in the very first article in this series.
Today the logical topology is simple chain of routers:
OSPF is launched between SR2 and XR3 with its simplest configuration. Both on links SR1-SR2 and XR3-XR4 two routing protocols (ISIS and BGP) are launched. Each protocol sends its own prefixes.
Here are the initial configuration files: initial_linux initial_sr1 initial_sr2 initial_xr3 initial_xr4
Routing policy configuration
Before we step into any configuration, let’s check the routing tables at our Nokia (Alcatel-Lucent) VSR SR2:
|
A:SR2# show router route-table |
And at Cisco IOS XRv router XR3:
|
RP/0/0/CPU0:XR3#show route ipv4 |
We see that each of them learn variety of routes from different sources, but what is important for now they learn only IPv4 prefixes in the range 10.0.0.0/24 from OSPF.
Now, we take OSPF as a routing protocol, where we are going to inject routes from those different sources in. The following tasks must be accomplished:
- Any IPv4 prefix in range 10.0.10.0/24 that is learned from BGP is to be imported into OSPF as E1 route with metric 100;
- Any IPv4 prefix in range IPv4 prefix 10.0.20.0/24 that is learned from ISIS is to be imported into OSPF with tag 1234;
- Any IPv4 prefix in range IPv4 prefix 10.0.30.0/24 that is learned from ISIS is not to be imported into OSPF;
- Any IPv4 prefix in range 10.0.0.0/16 that is learned from any routing protocol with prefix length 16-32 is to be redistributed into OSPF LSDB;
- All other prefixes are denied;
The task seems to be long, but it isn’t too complex. Let’s take a look into necessary configuration at our vendors of choice:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR2 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
The first point that you definitely spot is how sources of routes redistribution are configured. In Nokia (Alcatel-Lucent) SR OS you have single policy that covers everything, whereas in Cisco IOS XR (as well as Cisco IOS/IOS XE/NX-OS) you always define exact source of distribution and apply policy to that particular routing source. Both these logics have solid ground in my opinion:
- Nokia makes the control easier as you need to check and/or change the single policy;
- Cisco provides more reliable control as you always know from which particular protocol you do want to import something;
This difference is obvious in the realization of the 4th task. In Nokia (Alcatel-Lucent) SR OS we just configure and apply to the rule the prefix-list without mentioning routing protocol. In Cisco IOS XR we configure the same rule two times (one per routing policy). If we SR2 will somehow now about any new prefix in 10.0.0.0/16 range (like new configured interface, static route, ISIS, BGP, RIP, whatever else), it will distribute it to the peers, whereas Cisco IOS XR will distribute further prefixes learned only through BGP or ISIS.
But for the sake of completeness, we can achieve the same level of control in Nokia by splitting rule 40 into two new. Was:
|
A:SR1>edit-cfg# candidate view |
Become:
|
A:SR1>edit-cfg# candidate view |
Back to our configuration. There is one interesting moment in the configuration of Cisco IOS XR route-policies that is variables. Pay attention to the configuration of the route policy RP_BGP_TO_OSPF. You see that I put in brackets some name, which is used later in the script itself. It gives me possibility to use such route-policy in different contexts just by changing value that I put to this argument.
Let’s check, if we see at Cisco IOS XR router XR3 routes, which are exported at SR2:
|
RP/0/0/CPU0:XR3#show route ipv4 ospf |
At a glance all of the required routes are being received. Let’s start by checking the details. IPv4 prefix 10.0.10.1/32 is redistributed with OSPF metric type E1 and metric value 100 ( you see metric 101 which is redistributes metric 100 and 1 is metric from XR3 to SR2).
I haven’t adjusted reference-bandwidth for OSPF between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, though un production it’s necessary (link).
The next IPv4 prefix 10.0.20.1/32 should have tag 1234, which it has:
|
RP/0/0/CPU0:XR3#show route ipv4 10.0.20.1/32 |
As there were no interesting changes in IPv4 route 10.0.40.1/32 during redistribution, for us it’s just enough to see that it exists in the routing table.
Let’s check Nokia (Alcatel-Lucent) SR OS side that is SR2 in this case:
|
*A:SR2# show router route-table protocol ospf |
It’s not possible to define the route type and its parameters from the routing table so let’s see directly into LSA:
|
*A:SR2# show router ospf database type external 10.0.10.4 detail |
Here are the configuration files with what result our lab findings: final_sr2 final_sr1 final_xr4 final_xr3
Lessons learned
The devil is hidden in the details. I can also add that in the network world the devil is hidden the default behaviour.
When we don’t define any parameters for export of the route into OSPF, the following is happens:
- Nokia (Alcatel-Lucent) SR OS sets metric-type as E2 and copies original metric from route-table to be distributes in LSA5.
- Cisco IOS XR also sets metric-type as E2, but it sets metric value to 1 for routes originated from BGP and 20 for routes originated from all other routing protocols.
You will come to these results if will play with metric at Nokia (Alcatel-Lucent) SR OS side and redistribution sources at Cisco IOS XR. Based on this I always recommend to minimize the amount of default values and manually define all the parameters. Especially it’s important in multi-vendor scenarios
Conclusion
As I’ve said in the very beginning, route policies are one of the most important tool that is used in many different tasks in the router. Sometimes it’s mandatory, sometimes it’s optional, but in all the cases it gives you flexibility if you understand how it to deal with it. In the next article we’ll talk about policies in BGP in details. Take care and good bye!
Support us
BR,
Anton Karneliuk