Hello my friend,
The last time we have started interesting discussion regarding configuration of unnumbered Ethernet interfaces. We have figured out that Cisco IOS XR has strange behavior and we’ll try to solve it in this part.
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. |
Instead of introduction
This article isn’t standalone. It’s continuation of the previous one, so we use the topology and existing configuration from that one. I advise you to read it beforehand, so you will be synchronized with the actual state, what we are talking about.
Change of IGP from ISIS to OSPF
As we have figured out in the end of the previous article, there Cisco IOS XR doesn’t generate information in MPLS TED (Traffic Engineering Database). Probably, it’s a bug or limitation of XRv itself or IOS XR version 6.1.2, I don’t know. I’ve started thinking, what I could do. I’ve tried a lot of different options on my Cisco IOS XRv routers like enabling/disabling RSVP on interfaces, playing with different MPLS-TE and Segment Routing parameters, but unfortunately it hasn’t brought anything that solves this issue. Then I decided to change routing protocol in my network, which my small service provide core actually, to OSPF. Let’s see how to do it:
| 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 |
After the network has reconverged, we briefly check the routing table to confirm that:
|
RP/0/0/CPU0:XR3#show route ipv4 |
The routing table looks so far good. Actually, in ISIS pure IPv4 routing was also working for unnumbered Ethernet interfaces without problems. What about packet forwarding? Let’s see:
|
A:SR1# ping 10.0.0.11 count 1 |
I won’t make the same configuration for OSPF to check LDP and Segment Routing, because it was working in ISIS. Maybe something changes here, but it will be again large amount of text. So I assume that that both these MPLS data plane technologies are working in OSPF as well, so I can focus solely on Traffic Engineering (first of all, Segment Routing Traffic Engineering).
For ISIS there were missing entries in MPLS TED from Cisco IOS XR side. Let’s see how it looks like now:
|
RP/0/0/CPU0:XR3# show mpls traffic-eng topology brief |
At a glance we see the improvement with the new configuration. Now we have full MPLS TED and theoretically should be able to build a Segment Routing Traffic Engineering LSP. Just of curiosity point of view, pay attention to IGP metric both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR routers. It has the maximum possible value, whereas TE metric is correct and is related to actual bandwidth.
Read this article to get understanding, how to make SR TE in general.
According to IGP calculation, the shortest path between SR1 and XR3 is SR1 <-> XR4 <-> XR3. Let’s configure SR-TE tunnel so that traffic takes path SR1 <-> SR2 <-> XR4 <-> XR3.
The following configuration we put on our service provide PE routers represented by Nokia (Alcatel-Lucent) VSR 7750 and Cisco IOS XRv 9000 (ASR 9000):
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
The configuration is pretty much the same as it was in the mentioned article. The only difference is that I have specified exact label stack rather than next-hop IPv4 addresses. We start checking configured MPLS SR TE LSP from Nokia (Alcatel-Lucent) SR OS router SR1:
|
A:SR1# show router mpls sr-te-lsp path detail |
The LSP is shown as up and running. As we figured out earlier, it is impossible to use mpls oam toolkit (at least now) to trace SR TE tunnel. So we’ll see later on in MPLS VPN output, how the label stack looks like. Cisco IOS XR router XR3 also should build LSP:
|
RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels |
It should, but unfortunately not. I omit outputs of all cases, though I tried to configure all possible options of explicit-path in Cisco IOS XR (next-labels node/adjacent, next-hop, IP/unnumbered). I figured out the following interesting moment. Let’s briefly recall MPLS TED:
|
RP/0/0/CPU0:XR4#show mpls traffic-eng topology brief | include “IGP|Intf” |
In my lab (with Cisco IOS XRv 6.1.2), Cisco router neither generate nor take into account Intf ID of neighbour in order to build SR TE LSP. Nokia (Alcatel-Lucent) SR OS does it automatically, and I assume that is the reason why it works there. I’ve tried to configure another type of explicit-path in Cisco IOS XR:
|
RP/0/0/CPU0:XR3#show conf |
As I don’t see Intf ID explicitly in MPLS TED, I’ve copied them from OSPF LSDB:
|
RP/0/0/CPU0:XR4#show ospf database router 10.0.0.33 |
Probably it’s wrong, but I haven’t found any other similar indicators. Anyway, SR TE LSP is down in Cisco IOS XR, but now for another reason:
|
RP/0/0/CPU0:XR3#show mpls traffic-eng tunnels |
So, despite the fact I have configured next-hop unnumbered addresses (actually, router-id), it still can’t be used.
Well, Nokia (Alcatel-Lucent) SR OS router has shown that it’s MPLS SR TE LSP is up and running. Let’s make a check by using ping in L3 VPN created in the previous part of this article. But before we need slightly modify the VPN configuration at SR1 so that next-hop is resolved to SR-TE tunnel rather than to “ordinary” Segment Routing label:
|
A:SR1>edit-cfg# candidate view |
Now we see that next-hop at SR1 is resolved to SR TE tunnel:
|
A:SR1# show router 10 route-table |
My assumption is that traffic from SR1 to XR3 will follow this SR TE tunnel and therefore it will have corresponding MPLS label stack. The backward traffic from XR3 to SR1 will be forwarded based on best-effort routing and therefore will have only on transport label (and one service on top for sure). What do you think? Is my assumption correct?
|
A:SR1# ping router 10 192.168.4.10 |
Ping between sites of our customer emulated by two interfaces is working, what is definitely good. But now it’s more important to understand details, how it’s working:
The output from Wireshark fully confirms my assumption. The following explanation is related to forward path from SR1 to XR3:
- You see that ICMP packet has 3 labels (2 transport + 1 service), when it leaves SR1.
- Then SR2 pops one label and forwards this packet to XR4 with only 2 labels (1 transport + 1 service).
- XR4 pops the only left transport label and sends this ICMP packet to XR3 with a single service label.
At the backward path from XR3 to SR1 we have “ordinary” Segment Routing operation:
- XR3 pushes 2 labels (1 transport + 1 service) on the packet and sends it to XR4.
- XR4 swaps topmost label, which is the transport one, and sends the packet according to its LFIB directly toSR1.
Configuration files are here: 084_config_final_sr1 084_config_final_sr2 084_config_final_xr3 084_config_final_xr4
Lessons learned
As usual, the devil is in detail. When something doesn’t work you have to dig much deeper than if everything is OK. It’s very time consuming, but in reality it’s very useful for us, engineers. Otherwise we won’t develop further,
Conclusion
Based on two parts of this article I can say that Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR has different implementations of SR TE. Probably it’s caused by virtual environment, as VSR is fully commercial product with full IP/MPLS stack support, whereas Cisco IOS XRv (at least my version) has numerous limitations. In general I have achieved all desired results in terms of usage of unnumbered Ethernet interfaces in Nokia (Alcatel-Lucent) SR OS routers and moderate results in Cisco IOS XR. I believe, colleagues from Cisco will solve it (or probably it’s already solved in hardware solution and/or another version of IOS XR). Take care and good bye!
Support us
BR,
Anton Karneliuk
