Hello my friend,

Some time ago I’ve already described the structure and components of service provider routers. Today I’m gonna show you how it’s applicable to virtual ones.

Brief overview

As you remember (or if you have read provided links just now), the service provider routers are modular, regardless of Nokia (Alcatel-Lucent), Cisco, Juniper or whatever else origin. Certainly there are some small devices, which have fixed configuration and are used, when limited amount of interfaces and media types is sufficient.

So far we were using in our lab only one 5-port line card in Nokia (Alcatel-Lucent) VSR (SR 7750) router and only one (very rarely two) ports at Cisco IOS XRv router. When we are speaking about pure routing technologies, it’s sufficient. But what if we need some additional functions, like NAT or IPSec? Here things become more complicated and currently the limitation exists.

What are we going to test?

We’ll review the structure of virtual router definition file for Nokia (Alcatel-Lucent) VSR (SR 7750). Since there are some major since in the newest release (R15.0), which was released the last month, I’ll cover both definition of previous version (R14.0) and the newest one (R15.0). At the end we’ll create virtual router definition (xml file), which will include more than one module for Nokia (Alcatel-Lucent)

For Cisco IOS XRv, I’ll provide you some insights and guidelines, how you can achieve the same functionaliy.

Topology

There is no particular topology for the current lab. Neither physical nor logical. Basically we just need possibility to launch virtual router and have access to definition files (xml).

Nokia (Alcatel-Lucnet) VSR R14.0 and older

The main document that provides information about staffing of Nokia (Alcate-Lucent) VSR is release notes. You can download them from the official website, but you need to have account. There are no any specific rights, so you can just create general access account you will have access to this documentation.

For your convenience I put release notes for Nokia VSR R14.0 directly here as well vsr-installation-and-setup-guide.

Important remark here is that we use integrated model, what means that all cards, modules and whatever else reside in single VM. It’s possible also to have a distributed model, where each VM plays role of separate card (2x VMs for CPM/SF, Nx VMs for IOM/IMM). The distributed model is used in real production deployments. Actually the main difference between Nokia (Alcatel-Lucent) VSR and Cisco IOS XRv is that Nokia is fully commercial product that can be used for production deployment for data plane. It’s performance linearly scale with adding VMs to distributed VSR.

In the sake of completeness, Cisco is going in the direction of distributes solution as well, but current IOS XRv 9000 deployment supports only single, so performance is limited to this single VM and assigned CPU Core/Memory/network interfaces.

Let’s back to our lab. Our task is to configure Nokia (Alcatel-Lucent) VSR with two MDA modules: one is 5-port MDA with 1GE interfaces and another one is MS-ISA that is used for all kind of services, like IPSec, NAT (Network Address Translation), LNS (L2TP Network Server) and so on.

To accomplish this task we need to put information in the xml file that defines KVM VM in Linux. Initial XML file for Nokia (Alcatel-Lucent) VSR R14.0 is here: vsr14-r1 (change the file type to xml).

In the beginning of the article series about Nokia (Alcatel-Lucent) and Cisco I explained how to map interfaces to virtual bridges in Linux in order to provide connectivity inside host OS and outside VMWare VM. Now we’ll make configuration in another part of the configuration which starts with TiMOS. But before we start any configuration, let’s start VSR and check which IOM/IMM and MDAs we can have in overall:

A:SR1>config>card# card-type
– card-type <card-type>
– no card-type
<card-type> :
iom2-20g|iom3-xp|imm48-1gb-sfp|imm48-1gb-tx|
imm8-10gb-xfp|imm4-10gb-xfp|imm5-10gb-xfp|
imm1-oc768-tun|imm1-40gb-tun|imm1-100gb-cfp|
imm12-10gb-sf+|iom3-xp-b|imm48-1gb-sfp-b|
imm3-40gb-qsfp|iom3-xp-c|iom4-e|imm-1pac-fp3|
imm-2pac-fp3|imm48-1gb-sfp-c|iom4-e-b
!
!
A:SR1>config>card>mda# mda-type
– mda-type <mda-type>
– no mda-type
<mda-type> :
isa-aa|isa-bb|isa-tms|isa-tunnel|isa-video|m1-10gb|
m1-10gb-dwdm-tun|m1-10gb-hs-xfp-b|m1-10gb-xfp|
m1-10gb-xp-xfp|m1-choc12-as-sfp|m1-choc12-ces-sfp|
m1-choc3-ces-sfp|m1-oc192|m10-1gb+1-10gb|
m10-1gb-hs-sfp-b|m10-1gb-sfp-b|m10-1gb-xp-sfp|
m12-1gb+2-10gb-xp|m12-1gb-xp-sfp|m12-chds3-as|
m16-atmoc3-sfp|m16-atmoc3-sfp-b|m16-oc12/3-sfp|
m16-oc12/3-sfp-b|m16-oc3-sfp|m2-10gb-xfp|
m2-10gb-xp-xfp|m2-oc192-xp-xfp|m2-oc48-sfp|
m20-100eth-sfp|m20-1gb-sfp|m20-1gb-tx|m20-1gb-xp-sfp|
m20-1gb-xp-tx|m4-10gb-xp-xfp|m4-atmoc12/3-sf-b|
m4-atmoc12/3-sfp|m4-chds3-as|m4-choc3-as-sfp|
m4-choc3-ces-sfp|m4-oc48-sfp|m4-oc48-sfp-b|
m48-1gb-xp-tx|m5-1gb-sfp-b|m60-10/100eth-tx|
m8-oc12/3-sfp|m8-oc3-sfp|vsm-cca|vsm-cca-xp

This are the MDAs that we can install in the modules above. There are also numerous CPM modules. And here we come to the most crucial point: not all combinations of chassis, CPM, IOM/IMM and MDA works together. In the release notes for Nokia (Alcatel-Lucent) VSR R13 I’ve found the following table:

072_net_01_r13_release_mda

If something is wrong, you can see the following message upon device boot:

sysVmBootStringGenerate: ERROR: failed parsing ‘mda/1=m5-1gb-sfp-b’

Then Nokia VSR will boot with default predefined template that is: chassis = SR-12, CPM = sfm4-12, IOM = iom3-xp-b and single MDA = m5-1gb-sfp-b.

Correct chain chassis-cfm-iom-mda is provided in release notes that you have already seen previously, but not everything is that easy. Even if you checked your module pattern with that documentation, it doesn’t mean that it will work for sure. Here are some outputs of my findings in Nokia (Alcatel-Lucent) VSR R14.04.

7750 SR-c4:

[root@localhost images]# cat vsr14-r1.xml | grep TIMOS
<entry name=’product’>TIMOS:address=192.168.1.101/24@active static-route=192.168.0.0/16@192.168.1.1 license-file=ftp://aaa:aaa@192.168.1.1/FTP/SR_OS_VSR-SIM_new_14.txt slot=A chassis=SR-c4 card=cfm-c4-xp mda/1=m5-1gb-sfp-b mda/3=isa-tunnel</entry>

Such configuration boots without problems and you can see that chassis type is appropriate:

A:SR1# show chassis | match Type
Type : 7750 SR-c4
!
!
A:SR1# show card
===============================================================================
Card Summary
===============================================================================
Slot Provisioned Type Admin Operational Comments
Equipped Type (if different) State State
——————————————————————————-
1 (not provisioned) up unprovisioned
iom-c4-xp
A cfm-c4-xp up up/active
===============================================================================
!
!
A:SR1# configure card 1 card-type “iom-c4-xp”
!
!
*A:SR1# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
——————————————————————————-
1 5 icm2-10gb-xp-xfp up provisioned
(not equipped)
===============================================================================
!
!
*A:SR1# show port
===============================================================================
Ports on Slot 1
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
1/5/1 Down No Ghost 8704 8704 – netw null xgige
1/5/2 Down No Ghost 8704 8704 – netw null xgige
===============================================================================
Ports on Slot A
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
A/1 Up Yes Up 1514 1514 – netw null faste MDI
===============================================================================

Unfortunately, besides proper chassis type there are no good news. You can’t influence IOM choice, so the predefined one is used that seems not to support requested MDAs (though release notes says, it must). There is one build-in MDA in slot 5, which has 2x 10GE ports. It is sufficient for all my labs, as I usually split the network port into sub interfaces, whereas another port is used as access one. The only limitation is that SR-c4 chassis doesn’t support d model.

As you may recall, chassis-type c or d is necessary for IPv6.

7750 SR-c12:

[root@localhost images]# cat vsr14-r1.xml | grep TIMOS
<entry name=’product’>TIMOS:address=192.168.1.101/24@active static-route=192.168.0.0/16@192.168.1.1 license-file=ftp://aaa:aaa@192.168.1.1/FTP/SR_OS_VSR-SIM_new_14.txt slot=A chassis=SR-c12 card=cfm-xp-b mda/1=m5-1gb-sfp-b mda/3=isa-tunnel</entry>

What do you think we get into our Nokia (Alcatel-lucent) VSR? The answer is a little bit unexpected:

A:SR1# show chassis | match Type
Type : 7750 SR-c12
!
!
A:SR1# show card
===============================================================================
Card Summary
===============================================================================
Slot Provisioned Type Admin Operational Comments
Equipped Type (if different) State State
——————————————————————————-
1 (not provisioned) up unprovisioned
iom-xp-b
A cfm-xp-b up up/active
B cfm-xp-b up down/standby
(not equipped)
===============================================================================
!
!
A:SR1# configure card 1 card-type “iom-xp-b”
*A:SR1# show card
===============================================================================
Card Summary
===============================================================================
Slot Provisioned Type Admin Operational Comments
Equipped Type (if different) State State
——————————————————————————-
1 iom-xp-b up up
A cfm-xp-b up up/active
B cfm-xp-b up down/standby
(not equipped)
===============================================================================
!
!
*A:SR1# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
——————————————————————————-
No Matching Entries
===============================================================================
!
!
*A:SR1# show port
===============================================================================
Ports on Slot A
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
A/1 Up Yes Up 1514 1514 – netw null faste MDI
===============================================================================
Ports on Slot B
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
B/1 Up No Ghost 1514 1514 – netw null faste
===============================================================================

We become nothing besides chassis. There is no single MDA active, meaning that we don’t have possibility to connect our virtual router to the network. Probably the reason is that requested MDAs aren’t supported with IOM “iom-xp-b” (or “iom-xp”, which I’ve also tested but don’t provide here for brivety).

7750 SR-7

The last attempt is to configure chassis type that relates to distributed model with the desire to get it working with proper MDA:

[root@localhost images]# cat vsr14-r1.xml | grep TIMOS
<entry name=’product’>TIMOS:address=192.168.1.101/24@active static-route=192.168.0.0/16@192.168.1.1 license-file=ftp://aaa:aaa@192.168.1.1/FTP/SR_OS_VSR-SIM_new_14.txt slot=A chassis=SR-7 card=sfm4-12 mda/1=isa-tunnel mda/3=m5-1gb-sfp-b</entry>

But as I’ve said before, if the configuration isn’t supported and you receive the error upon router boot, you are booted with default router modules:

sysVmBootStringGenerate: ERROR: failed parsing ‘mda/1=isa-tunnel’
!
!
A:SR1# show chassis | match Type
Type : 7750 SR-12
!
!
A:SR1# show card | match 1
1 iom3-xp-b up up
A sfm4-12 up up/active
B sfm4-12 up down/standby
!
!
A:SR1# show mda | match 1
1 1 m5-1gb-sfp-b up up
!
!
A:SR1# show port | match 1
Ports on Slot 1
1/1/1 Up Yes Up 8704 8704 – netw dotq xcme GIGE-LX 10KM
1/1/2 Down No Down 8704 8704 – netw null xcme GIGE-LX 10KM
1/1/3 Down No Down 8704 8704 – netw null xcme GIGE-LX 10KM
1/1/4 Down No Down 8704 8704 – netw null xcme GIGE-LX 10KM
1/1/5 Down No Down 8704 8704 – netw null xcme GIGE-LX 10KM
A/1 Up Yes Up 1514 1514 – netw null faste MDI
B/1 Up No Ghost 1514 1514 – netw null faste

Such router staffing I’ve used for all my labs actually, and it supports chassis-type d for IPv6 and so on.

Nokia (Alcatel-Lucnet) VSR R15.0

The newest (11.04.2017) version of VSR changes the rules of writing TIMOS. Now there is no mapping to physical devices and Nokia (Alcatel-Lucent) VSR is fully independent product. It has its own chassis type, IOMs and MDAs. Here is the example:

[root@localhost images]# cat vsr15-r1.xml | grep TIMOS
<entry name=’product’>TIMOS:address=192.168.1.151/24@active static-route=192.168.0.0/16@192.168.1.1 license-file=ftp://aaa:aaa@192.168.1.1/FTP/sr15.txt slot=A chassis=VSR-I card=cpm-v mda/1=m20-v mda/3=isa-tunnel-v</entry>

And the most pleasant thing for me is that it works as proper now:

A:VSR# show chassis | match Type
Type : VSR-I
!
!
A:VSR# show card | match 1
1 iom-v up up
!
!
A:VSR# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
——————————————————————————-
1 1 m20-v up up
3 isa-tunnel-v up up
isa-ms-v
===============================================================================
!
!
A:VSR# show port
===============================================================================
Ports on Slot 1
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
1/1/1 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/2 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/3 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/4 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/5 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/6 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/7 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/8 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/9 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/10 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/11 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/12 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/13 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/14 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/15 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/16 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/17 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/18 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/19 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/1/20 Down No Down 9212 9212 – netw null xlgige 40GBASE-LR4 *
1/3/1 Up Yes Up – accs dotq vport
1/3/2 Up Yes Up – accs dotq vport
===============================================================================
Ports on Slot A
===============================================================================
Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/
Id State State MTU MTU Bndl Mode Encp Type MDIMDX
——————————————————————————-
A/1 Up Yes Up 1514 1514 – netw null faste MDI
===============================================================================

Though interfaces are 40GE, they are fully compatible with built in Linux switch (brctl), so I can attach Cisco IOS XR at another side of the switch and make my labs further.

Frankly speaking, I haven’t seen the release notes for Nokia (Alcatel-Lucent) VSR R15.0 yet, so I’ve developed that stuffing myself. The CLI built-in help was the key:

A:VSR>config>card# card-type ?
– card-type <card-type>
– no card-type
<card-type> : iom-v
!
!
A:VSR>config>card# mda 1
A:VSR>config>card>mda# mda-type ?
– mda-type <mda-type>
– no mda-type
<mda-type> : isa-aa-v|isa-bb-v|isa-tunnel-v|m20-v

I’m not going to compare two releases, as for sure new release has more functions as the network technologies continues to develop. The only disadvantage that I see for me is that VSR R15.0 utilizes more computing resources and with one VSR running I have 6,5 Gbps CPU utilization, what means that I can run maximum one more Cisco IOS XR, so the scale of my lab is decreasing.

072_net_02_ram

So I’ll continue writing articles in VSR R14.0 using R15.0 for new features. Working xml for R15: vsr15-r1 (don’t forget to change type to xml).

Cisco virtual routers

Cisco XRv 9000 is predefined product and the only thing that you can tune is the number of interfaces that it has. You can do it either through modification of vmx file or just by adding them in your VM player:

072_net_03_xrv

Cisco XRv 9000 has only RSP besides interfaces, it means that it can perform all the function that doesn’t need specifics ASICs (like data plane for L2VPNs) or modules (ISM is needed for NAT/CGN, IPSec and etc). So, if you can’t add specific modules to Cisco XRv 9000, does it mean that you can’t have this functionality in virtual world? Then answer is “you can”.

When Nokia (Alcatel-Lucent) has the only product in virtual world (that is VSR), Cisco has a numerous products running different operation systems. There are the following products:

  • Cisco XRv 9000 running Cisco IOS XR is service provider router that we have used for all our labs
  • Cisco CSR 1000v running Cisco IOS XE is fully functional virtual version of Cisco ASR 1000 and is positioned as universal access gateway including all BNG/BRAS and IPSec functionality in addition to IP/MPLS stack
  • Cisco ASAv running Cisco ASA OS is firewall/DPI/VPN concentrator.
  • Cisco Nexus 1000v running NX-OS is limited version of Cisco Nexus Data Center switch

Such variety of products reflect also the landscape of Cisco hardware-based products, with all its pros and cons.

Lessons learned

Unfortunately, release notes aren’t 100 correct. I’ve tried to copy example from it and there was no success. So it’s was actually the root cause, why I’ve written this article. I had to spend a lot of hours finding working configuration with MS-ISA as I need to test some IPSec functionality in Nokia (Alcatel-Lucent) SR OS and the quickest and the cleanest option for me is to make it locally in my lab, though I have access to hardware Nokia boxes.

Conclusion

Each vendor has its own vision and strategy of development and implementation of virtual solutions (NFV). Nokia has a single product and provides possibility to add corresponding modules just as in physical device. In the latest version R15 Nokia (Alcatel-Lucent) VSR is even simpler than it was previously. Cisco has different products with each covering specific domain, what also is a reasonable approach. At the end of the day it’s just important that you can have necessary functionality at NFV and this functionality is interoperable between vendors. Take care and good bye!

Support us





BR,

Anton Karneliuk