Hello my friend,
This article will be quite long so make a cup of tea for you sit more comfortable. Though the configuration of any routing protocol (IGP) can be relatively quick and short, usually you have to tune many additional parameters to get desired level of speed and reliability. I won’t cover all the features of OSPF, as it’s just impossible, but I will provide more or less complete config, which is used in service provider network.
Topology
In previous articles we have used only one physical interface between our Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XRv. In the article about trunking I’ve shown how to configure trunk and sub interfaces between (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XRv, therefore it’s possible to create multiple logical interfaces which is useful for description of IGP’s work. Nevertheless in this article we’ll add one more physical link (if it’s possible to say so about fully virtual environment) between our SR1 and XR1, so our “physical” topology for the current lab is:
If you have forgotten how to do it or this article is the first one you read from my series, take a look to the first one for guidelines how to create additional link.
The next step is to create the logical topology for our lab. It isn’t very complex, though it provides us possibility to configure a lot of features:
Later I’ll add one interface to each router in order to configure redistribution. They aren’t shown at the image below in order not to mix them with area structure. Initial configuration of Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XR (ASR 9000) routers you can find here: SR1 and XR1.
Basic intra-area connectivity with not basic parameters
As usual I assume that you have understanding of OSPF’s operation.
First of let’s establish connectivity between SR1 and XR1. As you know, there are two main types of network (or interface, how it’s called in Nokia (Alcatel-Lucent) SR OS), which define whether the Designated Router (DR) is used or not. Let’s briefly compare available options:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR (IOS XE, NX-OS) |
| Broadcast – all routers send multicast packets to discover each other/maintain adjacency. DR/BDR is chosen Point-to-point – only two neighbors are possible at interface. Multicast packets are sent to discover each other/maintain adjacency. There is no DR/BDR |
Broadcast – all routers send multicast packets to discover each other/maintain adjacency. DR/BDR is chosen Point-to-point – only two neighbors are possible at interface. Multicast packets are sent to discover each other/maintain adjacency. There is no DR/BDR Nonbroadcast – static OSPF neighbors must be configured, unicast packets are sent then to establish/keep adjacency and exchange LSAs. DR/BDR is chosen Point-to-multipoint – Multiple neighbors in subnet though they establish adjacency only with central router (hub). Multicast packets are sent to discover each other/maintain adjacency. There is no DR/BDR Point-to-multipoint nonboradcast – Multiple neighbors in subnet though they establish adjacency only with central router (hub). Static OSPF neighbors must be configured, unicast packets are sent then to establish/keep adjacency and exchange LSAs. There is no DR/BDR Loopback – special type for loopback interfaces. No packets are sent, and prefix is always advertised as /32 despite of actually configured at interface |
For non broadcast interfaces Cisco IOS / IOS XR demands the configuration of static OSPF neighbor at least of one side of link. In Nokia (Alcatel-Lucent) SR OS I haven’t found such possibility.
In modern network only point-to-point and broadcast network types are used. The first type is usually used to interconnect routers with each other; whereas the latter one is used for connecting customer devices (i.E Radio Network Controller (RNC) in service provider network). In our lab we’ll configure both these types of networks in the following way:
| Interface type | SR1 – Nokia VSR | XR1 – Cisco IOS XRv |
| broadcast | toXR1_p1 | g0/0/0/0 |
| point-to-point | toXR1_p2 | g0/0/0/1 |
To see OSPF work in real time additional logging is configured at Nokia (Alcatel-Lucent) SR OS.
Let’s start the configuration our Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XRv (ASR 9000):
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1>config>router# ospf 1 |
RP/0/0/CPU0:XR1(config)#show conf |
I guess that you have some questions to the provided configuration, so let’s discuss it a little bit. Both routers have the possibility to automatically assign router ID (RID) to OSPF configuration:
- Nokia (Alcatel-Lucent) SR OS uses globally configured RID (Cisco has no such analog). If it isn’t configured then IP address of system interface.
- Cisco IOS XR use IP address of lowest loopback. If there is no loopback configured, then Cisco IOS XR use IP address of the lowest up physical interface.
The next point is authentication. Though both routers supports plain text authentication, it isn’t secure at all and we use MD5 authentication at both interfaces.
In configuration file the password is saved and shown in encrypted form. The password is provided in clear text above is just for your reference.
The last point here is the configuration of hello/dead intervals. By default they are 10/40 seconds respectively. Here is some difference in their configuration at Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR:
- If you change hello-interval in Cisco, the dead-interval is automatically adjusted to be four times bigger than configured hello-interval.
- If you change hello-interval in Nokia (Alcatel-Lucent) the dead interval isn’t adjusted automatically. So you need to change it manually as well.
So far we have discussed the configuration, let’s check whether OSPF adjacency has been established:
|
RP/0/0/CPU0:XR1#show ospf CORE neighbor |
Well, we see that adjacency hasn’t come up. One of interface is down, whereas the second one is stuck in EXSTART phase. Usually such stuck means that we have problem with MTU mismatch between peering routers:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1# show router interface detail | match expression “Name|MTU” |
RP/0/0/CPU0:XR1#sh ipv4 interface | utility egrep “Up|MTU” |
And that is one of the cornerstones. The default MTU at Cisco IOS XR is 1514 (IP MTU 1500), whereas Nokia (Alcatel-Lucent) VSR has MTU 8936 (IP MTU is 8922):
|
A:SR1# show port detail |
We have to make them equal, so I’ll increase the MTU size at Cisco IOS XR:
|
RP/0/0/CPU0:XR1(config)#show conf |
Just after applying the necessary changes to MTU at Cisco IOS XR, we see desired logs at both devices:
|
RP/0/0/CPU0:Jul 17 19:41:46.879 : ospf[1018]: %ROUTING-OSPF-5-ADJCHG : Process CORE, Nbr 10.0.255.1 on GigabitEthernet0/0/0/0 in area 0.0.0.0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 |
It’s what we need and now we can check the routing tables (RIB) at both routers. Cisco IOS XR shows:
|
RP/0/0/CPU0:XR1#show route ipv4 ospf |
And Nokia (Alcatel-Lucent) VSR (SR 7750) has the following RIB:
|
A:SR1# show router route-table protocol ospf |
Though in both RIBs we see the necessary routes, Nokia (Alcatel-Lucent) SR OS by default has only one path to the destination, whereas Cisco IOS XR has two. The reason for that is deactivated ECMP (equal cost multipath) feature in Nokia (Alcatel-Lucent) VSR (SR 7750). So we need to activate it:
|
A:SR1>config>router# ecmp 2 |
Now let’s align, let’s say, the vocabulary, which is used in RIB by our wonderful vendors. “Pref” (Preference) in Nokia (Alcatel-Lucent) SR OS has the same meaning as “AD” (Administrative Distance) in Cisco. It’s a local parameter, which allows choosing the same prefix across different protocols. Numerically they are different, but in general we don’t need to take care of it. We just need to check whether the same prefixes use the same protocol by Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. We’ll back to this parameter later in our article one more time.
The next important parameter is metric. At SR1 we have it with value “101” for 10.0.255.1/32 prefix, whereas at XR1 we have metric of “1” only. So huge difference is based on different reference bandwidth, which is used to calculate OSPF’s metric according to RFC 2328. According to this RFC 2328, which actually describes OSPFv2 being implemented both by Nokia (Alcatel-Lucent) and Cisco, cost of link is calculated as “10^8 / link_bw”, where “link_bw” is measured in bits per second. It means that for all interfaces with the bandwidth more than 100 Mbps, the link cost will be always 1, what is obviously not desired. Nokia (Alcatel-Lucent) doesn’t follow this RFC and uses (at least in current SR OS release) another reference metric:
|
A:SR1# show router ospf 1 status | match Reference |
So instead of “10^8” the value of “10^11” is used. This parameter must be the same across all the routers in the routing domain, so we’ll change it at Cisco IOS XR:
|
RP/0/0/CPU0:XR1(config)#show conf |
Upon applying the configuration we see that the result is almost the same, though isn’t equal:
|
RP/0/0/CPU0:XR1#show route ipv4 ospf |
The key to this difference can be found in LSDB (Link state database), which is the most important component of OSPF. Let’s check it at Nokia (Alcatel-Lucent) VSR (SR 7750):
|
A:SR1# show router ospf 1 database type router detail |
With bold the interesting parts of LSAs (Link State Advertisement) are mentioned, which leads us to the following rule:
By default Cisco IOS XR announces loopback with metric 1 and Nokia (Alcatel-Lucent) announces loopback (including system interface) with metric 0 despite of the reference bandwidth.
But it’s default rule, which can be changed. We can manually assign metric (or cost) to each interface as we want:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1# configure router ospf 1 area 0.0.0.0 interface “system” |
RP/0/0/CPU0:XR1(config)#show conf |
Let’s compare LSAs again:
|
RP/0/0/CPU0:XR1#show ospf CORE database router |
The latest output is significantly cut in order to save the space.
So far there were lots of commands and comparison, but I haven’t tested, whether connectivity works. Let’s do it now!
|
A:SR1# ping 10.0.255.2 source 10.0.255.1 |
It works. Now we can go to the second major block, which is inter-area connectivity.
Inter-area configuration
The router, which interconnects different areas and connects them to backbone (area 0), is called ABR (Area Border Router). Such functionality we’ll configure in this part. It makes sense to remind the topology in order not to scroll page back to the top:
The configuration of ABR is relatively easy. We just need to configure new area with the appropriate interfaces and that’s it:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1>config>router>ospf# info |
RP/0/0/CPU0:XR1(config)#show conf |
Before we goes further, take a look at the “passive” command, which means that interface is announced though no OSPF adjacency can be built there. Now Nokia (Alcatel-Lucent) VSR (SR 7750) clearly states that it is ABR:
|
A:SR1# show router ospf 1 status | match Border |
And Cisco IOS XR confirms that:
|
RP/0/0/CPU0:XR1#show ospf CORE border-routers |
Cisco doesn’t claim it somewhere that he is ABR, but it isn’t necessary. He is ABR, because he connects area 2 to area 0. Let’s review the RIB at Cisco IOS XR:
|
RP/0/0/CPU0:XR1#show route ipv4 ospf |
You see two additional routes, which are advertised by SR1. Flag “IA” means that this is inter-area route. Now it’s turn of our Nokia (Alcatel-Lucent) VSR (SR 7750) to show its RIB:
|
A:SR1# show router route-table ipv4 protocol ospf |
All the necessary routes present in SR1’s RIB, but there is no difference between intra-area and inter-area routes. Probably it isn’t necessary, as the best route is installed in RIB already, though the Cisco’s output more informative. Nevertheless we have possibility to check, where the route comes from:
|
A:SR1# show router ospf 1 routes |
Cisco has the same table, which is accessible via “show ospf CORE routes”
For inter-area routes there is separate LSA type (if you want to see the same detailed view as we have seen previously, just add “detail”):
|
A:SR1# show router ospf 1 database type summary |
Pay attention that there are different summary LSA per area. At Cisco IOS XR you can see either briefly overview all LSA all see the detailed view by categories. The following output is cut to provide only necessary info:
|
RP/0/0/CPU0:XR1#show ospf CORE database |
Now let’s test the connectivity between our inter-area routes:
|
RP/0/0/CPU0:XR1#ping 10.11.0.1 so 10.22.0.1 |
Very good, but it’s possible to optimize the RIB. In OSPF it’s possible to summarize routes only between areas. And if you have well designed IP address scheme, you can significantly review the amount of summary LSA and make RIB more compact and effective. Let’s configure the summarization at Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XR (ASR 9000):
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1>config>router>ospf# info |
RP/0/0/CPU0:XR1(config)#show conf |
Let’s review the result at SR1:
|
A:SR1# show router ospf 1 database type summary |
And the result is impressive, isn’t it? There are just 4 summary LSAs instead of 10, as it was in the beginning. Just one more fact I want to outline here. As you see, there are two prefixes announced into area 0.0.0.1: 10.0.0.0/8 and 10.22.0.0/16. Though the latter one is covered by the first one, the summarization is applicable only to local routes (learned from LSA1). SR1 learns route 10.22.0.0/16 through LSA3, which is generated by XR1 upon injecting routes from area 0.0.0.2 to area 0.0.0.0. That’s why SR1 doesn’t hide this route and would announce to routers in area 0.0.0.1 if they were. Routing table now looks more compact as well at both routers. Let’s first of all take a look at Nokia (Alcatel-Lucent) VSR (SR 7750):
|
A:SR1# show router route-table protocol ospf |
You see two additional routes, which points to next hop “Black Hole”. These are your aggregated routes, which are placed into RIB in order to avoid traffic loops. Cisco IOS XR also has such routes:
|
RP/0/0/CPU0:XR1#show route ipv4 ospf |
The last action in this part will be double check that connectivity still exists after summarization:
|
A:SR1# ping 10.22.0.1 source 10.11.0.1 |
Injecting the external routes
So far we have reviewed intra-area and inter-area communication, that’s why the third part of article is about redistribution of external routes to cover all possible types.
Comparing with the topology before we have two additional loopback interfaces per router. These loopback will be redistributed into OSPF with the following parameters:
- extLo11 at SR1 and Lo11 at XR1 will be redistributed into OSPF with metric-type 1 and cost 11;
- extLo12 at SR1 and Lo12 at XR1 will be redistributed into OSPF with metric-type 2 and cost 12.
To accomplish this task we need to do the following configuration at our routers:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
*A:SR1>config>router>policy-options# info |
RP/0/0/CPU0:XR1(config)#show conf end |
The configuration of loopback isn’t provided as I assume that you can do it without hints already.
Route policies (Policy statement in Nokia (Alcatel-Lucent) SR OS) are very similar between both vendors, so it’s easy to configure both of them even if you know the syntax of only one OS (Nokia(Alcatel-Lucent) SR OR or Cisco IOS XR, it doesn’t matter). Second, the logic of redistribution is also straightforward and similar:
Only routes in routing table (RIB) are redistributed. Routes in other protocols databases aren’t redistributed if they aren’t installed in RIB.
Now I t want to outline some differences in applying of these policies, which confuses me a lot at the beginning (as myself I have strong Cisco background). The first difference is that in Nokia (Alcatel-Lucent) SR OS you have to explicitly enable ASBR (Autonomous System Border Router) functionality by using “asbr” command. In Cisco IOS XR (IOS, IOS XE, NX-OS as well) there is no such command as well as the necessity to somehow mention ASBR-bility of router. At Nokia (Alcatel-Lucent) VSR (SR 7750) you can check, whether it’s applied or not by issuing the following command:
|
A:SR1# show router ospf 1 status | match Border |
Cisco IOS XR shows now that peering router also performs ASBR function:
|
RP/0/0/CPU0:XR1#show ospf CORE border-routers |
The information about external routes is distributed via LSA5. Let’s look into their content at our Nokia (Alcatel-Lucent) VSR (SR 7750):
|
A:SR1# show router ospf 1 database type external detail |
With the bold text the relevant parameters of OSPF metric-type and metric value are marked, and they fully align with our task, so we are good engineers 🙂
The next consideration is about applying of the route policy itself. In Cisco IOS XR the command structure is “redistribute FROM route-policy WHAT_EXACTLY”, where “FROM” is source of route in routing table and “WHAT_EXACTLY” is actually route-policy that makes both detailed filtering and setting of certain parameters. We can have many such redistribution entries under routing protocol configuration.
In Nokia (Alcatel-Lucent) SR OS you have only one import/export policy per OSPF configuration. Here are their description:
- Import policy is applied between route table (RIB) and OSPF database (LSDB) and import policy defines which routes will be imported from LSDB to RIB.
- Export policy is also applies between route table (RIB) and OSPF database (LSDB) but in opposite direction. Export policy defines which routes are exported from RIB to LSDB (besides routes learned from other OSPF neighbors and routes configured by “area x.x.x.x interface Y” command).
Think a little bit about it. A couple of times I’ve applied these import/export policies in the wrong direction and therefore completely deleted information in the RIB. The good thing is that it was in lab and no production traffic was affected. Possibly it’s easier to draw this explanation:
Another important consideration about route policies in Nokia (Alcatel-Lucent) SR OS is that you have to configure all type of redistribution in this policy, so take care of its configuration.
Let’s take a look into Cisco IOS XR’s RIB in order to check that now our route policy at SR1 is applied correctly:
|
RP/0/0/CPU0:XR1#show route ipv4 ospf |
All routes are here. Now it’s Nokia (Alcatel-Lucent) VSR (SR 7750) turn:
|
A:SR1# show router route-table protocol ospf |
Pay attention at Preference of external routes. It’s 150 whereas for internal routes it’s 10. If you compare it to Cisco IOS XR, the latter has the same AD for both types of routes.
This behavior can be changed at Cisco IOS XR with the following command “distance ospf intra-area 110 inter-area 110 external 150” under configuration of OSPF.
Everything looks good and now we can test our connectivity between external routes:
|
RP/0/0/CPU0:XR1#ping 172.16.11.1 so 192.168.11.1 |
Cisco IOS XR has one additional option, which allows to summarize external routes in the same way as we have done it for inter area prefixes. In Nokia (Alcatel-Lucent) SR OS unfortunately I have found such option neither in CLI nor in documentation. So I assume that it isn’t implemented, though I can be mistaken. Let’s configure Cisco IOS XR then:
|
RP/0/0/CPU0:XR1(config)#show conf |
Now we have only one LSA5 generated by XR1:
|
A:SR1# show router ospf 1 database type external |
In Cisco IOS XR RIB will be installed aggregated route to Null0 just as well as it was done for inter area aggregated route.
Final test of reachability from Nokia (Alcatel-Lucent) VSR (SR 7750):
|
A:SR1# ping 192.168.11.1 source 172.16.11.1 count 3 |
Fine tuning
In final part we’ll review some additional parameters that makes sense to configure across all you routers in the network. The first such parameter is timers. In order to provide predictable performance, they must be equal at all device in your network. Moreover they default configuration isn’t aggressive enough to provide fast convergence. Let’s compare these parameters:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1# show router ospf 1 status | match expression “Delay|Interval” |
RP/0/0/CPU0:XR1#show ospf CORE | utility egrep “[Tt]ime|[Ii]nterval|[Dd]elay” |
They are really huge, so I want to decrease them:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
*A:SR1>config>router>ospf>timers# info |
RP/0/0/CPU0:XR1(config)#show conf |
All the parameters are configured in milliseconds, so now we have quite fast network convergence. These timers aren’t the only that we have to configure to speed up the convergence, as it’s in general separate and big topic. Nevertheless these timers are on of its cornerstone.
The next feature is a little bit specific and used usually temporary, though there are some designs, where it’s used permanently. I’m talking about overload (In Cisco it’s called max-metric). Its logic is to configure the maximum metric at all its interfaces therefore exert the router from the traffic forwarding path. Temporary it’s used for maintenance or in router’s boot up. Permanently it’s used at BGP route reflectors in order not to pass data traffic. Let’s assume that I want the router to be out of traffic forwarding for 2 minutes upon boot up:
| SR1 – Nokia (Alcatel-Lucent) VSR (SR 7750) | XR1 – Cisco IOS XRv (ASR 9000) |
|
A:SR1>config>router>ospf# info |
RP/0/0/CPU0:XR1(config)#show conf |
There are also some additional features, which I’ll briefly mention. Unfortunately Cisco IOS XRv isn’t fully equivalent of ASR 9000 (at least now) in terms of supported features. The reason for that is architecture of Cisco ASR 9000 series routers. There are a lot of components that are offloaded to linecards CPU and NPU, whereas XRv is a control plane of RSP. BFD is implemented in hardware, that’s why I can’t provide you the configuration of BFD between Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XRv
Another useful feature isn’t implemented in Cisco IOS XR at all, though Nokia (Alcatel-Lucent) SR OS supports it. I’m talking about prefix suppression. In general you don’t need to know the IP addresses of interconnect links between routers at the distant routers. So it’s enough just to distribute information about loopbacks, which as typically used as next-hops in BGP / termination points for RSVP-TE tunnels. As Cisco IOS XR can’t do it for OSPF, I won’t show its configuration here.
The third not configurable feature is incremental spf (ispf). In Nokia (Alcatel-Lucent) you can configure its timers, so it seems to be implemented and you can’t deactivate it. In Cisco IOS XR it isn’t implemented at all. At Cisco’s forum I’ve found information, that it isn’t implemented and there is no plans to do it.
Lessons learned
As usually the devil is hidden in the details. The mismatch of default parameters across different vendors very often leads to problems in real environment, if they were not assessed and checked properly in advance. Always check the default configuration and explicitly configure parameters even if you don’t have any doubts.
Conclusion
In this article I tried to cover the most used and useful aspects of configuration of OSPF between Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XR (ASR 9000). For sure there are lots of other stuff, which I even haven’t mentioned. Nevertheless you can my configuration and explanation as a basis for your own experiments or production deployment. I hope you enjoy this article. I haven’t provided the configuration of OSPF for IPv6 as it’s fully separate protocol. And it’s the topic for my next article. Take care and good bye!
Support us
BR,
Anton Karneliuk
In control and management plane aspects, the vSim is functionally and operationally equivalent to an Alcatel-Lucent hardware-based SR OS router.
How can I redistribute directly connected and static routes on Alcatel-Lucent’s OSPF? Can you help me?
Hello Matues,
you need to create a route policy, which will do that for you. Please, refer to this article: https://karneliuk.com/2017/05/the-book-of-policies-vol-1-nokia-alcatel-lucent-sr-os-and-cisco-ios-xr/
Cheers,
Anton