Archive
Configuring interfaces on Cumulus VX
Cumulus Linux is awesome, did you know that? I haven’t got deep in to it, really only looked at bridging so far, but here is how you configure interfaces…so I don’t forget.
Let’s keep it nice and simple. I have two Nokia 7750 VSRs that I want to bridge together, sros3 and sros8. Both have a single connection over port 1/1/1 to the VX switch. These connections are to connect the various VM ports to the VX from the host machines perspective.
What’s this swp stuff? This is what Cumulus will call your interfaces: switchport basically. The management interface of the VX is eth0 and then each connection to a VM is on an swp starting at swp1 and continuing up as needed. Port positioning/numbering is based on the sequence the bridge entries are placed in your VX XML file. The first bridge will be eth0, the second swp1, third swp2 and so on.
My XML config for the 7750s is straightforward enough, nothing fancy going on. This portion connects the VX to sros8 only. You need an entry in your XML file for each port.
<interface type=’bridge’>
<mac address=’00:00:77:50:01:02’/>
<source bridge=’sros8_vx1’/>
<model type=’virtio’/>
</interface>
The equivalent on the VX is:
<interface type=’bridge’>
<mac address=’00:00:03:16:02:25’/>
<source bridge=’sros8_vx1’/>
<model type=’virtio’/>
</interface>
You can configure the sros8_vx1 bridge using VMM if you wish. If you want to throw it in quickly you can add with brctl but it wont be persistent.
[keith@scamall-server1 ~]$ sudo brctl addbr sros8_vx1
[keith@scamall-server1 ~]$ brctl show sros8_vx1
bridge name bridge id STP enabled interfaces
sros8_vx1 8000.fe0003160225 no vnet200
vnet201
We then configure the bridge in the VX machine. This is the ‘VLAN’ internal to the VX and connects the external VMs (sros3 and sros8) to a common forwarding table using bridge sr3_sr8.
Interface configuration files are stored in /etc/network/interfaces so edit this file as follows:
auto sr3_sr8
iface sr3_sr8 inet static
bridge-ports swp41.38 swp43.38
bridge-stp off
address 10.3.8.254
netmask 255.255.255.0
swp41 is where sros8 connects and swp43 is where sros3 connects. The .38 is the tag I will accept for this bridge (similar configuration on the VSR). While I don’t need to put an IPv4 address here I can use it to test connectivity between the connected VM and the VX if there is a problem. FYI Cumulus VX comes with Nano as an editor, download VIM as quick as you can. Man I hate Nano 🙂
Finally bring up your new bridge on the VX
cumulus@cumulus:~$ sudo ifup sr3_sr8
You can also use sudo ifup -a to bring all interfaces up.
Now, where is that proof pudding for me to eat?
*A:sros8# ping 10.3.8.3 count 1
PING 10.3.8.3 56 data bytes
64 bytes from 10.3.8.3: icmp_seq=1 ttl=64 time=1.36ms.—- 10.3.8.3 PING Statistics —-
1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 1.36ms, avg = 1.36ms, max = 1.36ms, stddev = 0.000ms
Boom, super awesome. I really like these bridges, they’re simple enough to install and work with. What we have done is create two bridges, connected each VSR to the VX and then bridged these two host bridges together with sr3_sr8 on the VX. Note the VX has no bridge for sros3_vx2 or sros3_vx1
BTW the user guide is really, really good. See it here cumulus_ug
Segment routing basics on IOS XRv
Well the day has finally come, segment routing is in the land of the hardware-have-nots with the release of demo image 5.2.0 for IOS XRv. I was about to hit the hay last night when I saw the location appearing on the Twitter courtesy of @ciscoiosxr and my tiredness quickly left me. I have been waiting for something on SR for what seems like an eternity, imagine my sadness when the files started downloading at 200K, Santa was going to make me wait. Finally the vmdk downloaded and I was ready to go.
In this post I will show you a brief outline of how to configure SR in ISIS and some basic reachability. It’s pretty straightforward to get a base network up and running but unfortunately there is not a lot of documentation on it. Have a look here for some info on CRS 5.2.x which mentions it. Also for reference have a read of the draft here.
So, what does the topology look like?
Each router is running ISIS (process is called SR), there is no explicit MPLS configuration required in the traditional sense (mpls ldp, rsvp etc). XR1 and XR5 are PEs and have a VPNv4 session between each other. The customer VRF has one loopback defined on each PE which is redistributed in to VRF to prove the concept.
The only place we need to make changes from typical routing configuration is under the ISIS process:
RP/0/0/CPU0:XR3#sho run router isis SR Wed Jul 9 13:12:59.112 UTC router isis SR is-type level-2-only net 49.0001.0000.0000.0003.00 address-family ipv4 unicast metric-style wide segment-routing mpls ! interface Loopback0 address-family ipv4 unicast prefix-sid index 20003 ! ===snipiddy snip, nothing special here===
The only changes we had to make were to add in segment-routing mpls under the IPv4 unicast AF and set a prefix segment ID on the loopback address. Now from my reading of the draft the loopback should be a Node SID but that command doesn't seem to be available in this release. The number you choose for your SID will be altered by the OS and fit in to the actual range in use which is platform dependent. Here we support over 1 million labels so the configured prefix SID is added to 900000 with a max value of 65535 (more on that later). I chose 2000x where x is XRx from the node name. As an aside you cannot configure the prefix-sid index on a physical interface:
RP/0/0/CPU0:XR1(config)#router isis SR RP/0/0/CPU0:XR1(config-isis)#int g0/0/0/0 RP/0/0/CPU0:XR1(config-isis-if)#add ipv4 RP/0/0/CPU0:XR1(config-isis-if-af)#prefix index 30001 RP/0/0/CPU0:XR1(config-isis-if-af)#commit Wed Jul 9 14:31:37.859 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
Now let's have a look at the network and see what we can see. Again documentation isn't readily available so bear with me here...
We can see XR1 is sending us one VPNv4 prefix, which is 10.0.0.1/32, the loopback10 address from VRF CUST over yonder the network:
RP/0/0/CPU0:XR5#sho bgp vpnv4 uni summ | i 1.1.1.1 Wed Jul 9 13:29:31.354 UTC 1.1.1.1 0 65000 62 62 7 0 0 00:58:53 1 RP/0/0/CPU0:XR5#sho bgp vpnv4 uni vrf CUST 10.0.0.1/32 | b 1.1.1.1 Wed Jul 9 13:31:09.727 UTC 1.1.1.1 (metric 40) from 1.1.1.1 (1.1.1.1) Received Label 16000 Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 6 Extended community: RT:1:1 Source VRF: CUST, Source Route Distinguisher: 1:1 RP/0/0/CPU0:XR5#
And just to be sure this is what XR1 is sending
RP/0/0/CPU0:XR1#sho bgp vpnv4 uni labels | i 1/32 Wed Jul 9 13:36:07.657 UTC 10.0.0.1/32 0.0.0.0 nolabel 16000
We are receiving our label from XR1 of 16000, standard XR fare there. How about the MPLS forwarding table? Lets look from XR5 to XR1 via XR3 and XR2 (path via XR4 is costed out)
RP/0/0/CPU0:XR5#sho mpls for labels 920001 Wed Jul 9 13:38:23.908 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 920001 No ID Gi0/0/0/0 10.3.5.3 4585
RP/0/0/CPU0:XR3#sho mpls for labels 920001 Wed Jul 9 13:37:47.240 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 920001 No ID Gi0/0/0/0 10.2.3.2 5269
RP/0/0/CPU0:XR2#sho mpls for labels 920001 Wed Jul 9 13:38:47.046 UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 920001 Pop No ID Gi0/0/0/0 10.1.2.1 5868
And finally lets looks at the ISIS database on XR1
RP/0/0/CPU0:XR1#sho isis database verbose XR1.00-00 | b Seg Wed Jul 9 13:43:26.497 UTC Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535 Metric: 10 IS-Extended XR1.01 Metric: 10 IS-Extended XR1.03 Metric: 10 IP-Extended 1.1.1.1/32 Prefix-SID Index: 20001, R:0 N:0 P:0 Metric: 10 IP-Extended 10.1.2.0/24 Metric: 10 IP-Extended 10.1.4.0/24
Here we can see the Prefix SID is set to 20001 and also the range supported to 65535. We're all about the link state protocol so XR5 sees:
RP/0/0/CPU0:XR5#sho isis da ver XR1.00-00 | b Seg Wed Jul 9 13:44:42.612 UTC Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535 Metric: 10 IS-Extended XR1.01 Metric: 10 IS-Extended XR1.03 Metric: 10 IP-Extended 1.1.1.1/32 Prefix-SID Index: 20001, R:0 N:0 P:0 Metric: 10 IP-Extended 10.1.2.0/24 Metric: 10 IP-Extended 10.1.4.0/24
Now if we look at the CEF tables for the default VRF and the CUST VRF lets see what we have:
RP/0/0/CPU0:XR5#sho cef 1.1.1.1/32 | i label
Wed Jul 9 13:48:58.124 UTC
local label 920001 labels imposed {920001}
The BGP next hop will be using 920001 for the transport label and we know the VPN label issued by BGP over on XR1 will be 16000 so the label stack for VRF CUST on XR5 towards 10.0.0.1/32 on XR1 is...
RP/0/0/CPU0:XR5#sho ip cef vrf CUST 10.0.0.1/32 | i label
Wed Jul 9 13:51:29.064 UTC
next hop 10.3.5.3/32 Gi0/0/0/0 labels imposed {920001 16000}
Magic. Now does this work in the dataplane? We should see traffic MPLS'd via XR3 and XR2 and finally IPv4'd in the VRF at XR1
RP/0/0/CPU0:XR5#trace vrf CUST 10.0.0.1 so 10.0.0.5 Wed Jul 9 13:52:21.800 UTC Type escape sequence to abort. Tracing the route to 10.0.0.1 1 10.3.5.3 [MPLS: Labels 920001/16000 Exp 0] 39 msec 49 msec 29 msec 2 10.2.3.2 [MPLS: Labels 920001/16000 Exp 0] 29 msec 29 msec 39 msec 3 10.1.2.1 39 msec * 39 msec
Beautiful! As we can see the label stack stays consistent across the network as every node knows that 920001 is the label to reach 1.1.1.1/32, our BGP next hop from XR5.
In the opposite direction we should have a transport label of 920005 and the VPN label, which should be 16000 as well, coincidentally as there is only a single service and no other signalling protocols in play.
RP/0/0/CPU0:XR1#trace vrf CUST 10.0.0.5 so 10.0.0.1 Wed Jul 9 13:53:59.443 UTC Type escape sequence to abort. Tracing the route to 10.0.0.5 1 10.1.2.2 [MPLS: Labels 920005/16000 Exp 0] 119 msec 39 msec 39 msec 2 10.2.3.3 [MPLS: Labels 920005/16000 Exp 0] 39 msec 29 msec 29 msec 3 10.3.5.5 39 msec * 29 msec
One of the benefits of SR is being able to statically route your traffic without maintaining state associated with RSVP. I don't know if that feature is available in this release, I haven't found anything yet.
Pig iron time, can we configure a prefix SID higher than 65535? No would be the answer
RP/0/0/CPU0:XR3(config)#router isis SR RP/0/0/CPU0:XR3(config-isis)#int lo0 RP/0/0/CPU0:XR3(config-isis-if)#add ipv4 uni RP/0/0/CPU0:XR3(config-isis-if-af)#prefix index 65536 RP/0/0/CPU0:XR3(config-isis-if-af)#commit Wed Jul 9 13:26:46.825 UTC % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors RP/0/0/CPU0:XR3(config-isis-if-af)#prefix index 65535 RP/0/0/CPU0:XR3(config-isis-if-af)#commit Wed Jul 9 13:26:51.565 UTC RP/0/0/CPU0:XR3(config-isis-if-af)#do sho mpls for | i 655 Wed Jul 9 13:27:03.434 UTC 965535 Aggregate default: Per-VRF Aggr[V] \
I hope to write more on SR as more and more features become available, and interop stuff between vendors but for now enjoy the wonder that is the IGP delivered label.
Base Topology for Further Posts
I have been really busy trying to get stuff done in work so haven’t has a chance to post anything and any spare time goes on study or family so it’s time to rectify that.
This is the topology I will be using for most of the build I do here. If I need to add in other links or devices I will state that.
Naming and numbering conventions:
-Routers are called rx with r1-4 being SR1 chassis and r5 is a SR7.
-System addresses are x.x.x.x
-Interfaces are ‘torx’, e.g. the link from r5 to r2 is tor2
-Point to point addressing follows xy.xy.xy.x/24 where x is the lower numerical rx and y is the higher numeric rx, e.g. the above mentioned link is 25.25.25.2 on r2
I have some testers dotted around the place and a few Ciscos/Junipers connected for various bits I’m doing. I will point out where they are if I end up including them in a post.
First up, OSPF
SROS System Basics
Service Router OS is the operating system that runs on Alcatel-Lucent 7×50 and 7210 routers and switches. It’s a pretty handy OS and I just love it in the same way Kevin Keegan would love it if we beat them. It is well structured and very flexible and, once you get used to it, it kicks the pants off other vendors I have used, in my opinion.
There is a distinct lack of information that I have found on the Internet for configuring these boxes, especially considering the 7750 is apparently number 1 or 2 in the PE market in Europe. In this post I will cover some basic system configurations to get you going.
I will be using SR1 and SR7 routers for config throughout these posts although there are other models available, e.g. SR12. The SR1 has a single processor and line card with two daughter card slots (MDA) whereas the SR7/12 have dual processors and five and ten line card slots respectively.
In this post I will be using an SR7, its processor slots are named A and B and the line cards are numbered 1-5. The active processor is indicated by either A: or B: at the CLI prompt. Each daughter slot is labelled x/1 or x/2, e.g. slot 2 sub-slot 2 is MDA 2/2.
Each processor (SF/CPM) holds a male DB9 console connector (with DCE/DTE toggle switch), RJ45 Ethernet management port and three compact flash slots. The SROS image is stored in cf3 and cf1/2 can be used to store log files etc.
In order to boot the chassis we need to configure the Boot Options File (bof) to locate the image and config files.
To configure the image and config locations point the bof at the directory/file locations. The A: indicates we are on the processor slot A:
*A:7750#bof
*A:7750>bof# primary-image cf3:\TiMOS-9.0.R11
*A:7750>bof# primary-config cf3:/myconfig.cfg
We then need to set the console speed. SROS defaults to 115200 so let’s change it to 9600 because everybody loves that one:
*A:7750>bof# console-speed 9600
It’s also a good idea to enable persistent indexing between reboots, especially if you use SAM5620 to manage the devices (a reload is required for it to take effect):
*A:7750>bof# persist on
Finally, you may want to use the RJ45 port if you don’t have an async device available. It doesn’t register in the Global Routing Table so any configuration here won’t impact on the operation of the router. Lets set the speed, duplex and an address:
*A:7750>bof# address 1.2.3.4/24 active
*A:7750>bof# speed 10|100
*A:7750>bof# duplex full|half
And that’s pretty much it for the bof, just don’t forget to save your work. If you are in the bof context then it is simply save. If you are in any other context you can use /bof save where the use of / allows the subsequent command to be run from any context. This also applies to config and admin level commands too.
Finally a word on saving in general. If the card identifier has a * against it then configuration has not been saved since the last change. You save the ‘running config’ by parsing admin save, again the / allows the command to be run outside its usual context. If the * doesn’t disappear after either an admin save or bof save then you will have to parse the other save command. From the config context I will save both the running and bof configs, notice the * disappears:
*A:7750# configure
*A:7750>config# /admin save
Writing configuration to cf3:\myconfig.cfg
Saving configuration ... OK
Completed.
*A:7750>config# /bof save
Writing BOF to cf3:/bof.cfg ... OK
Completed.
A:7750>config#
So that’s it for my first post on this ALU craic. I plan to build up a network from here on starting at the physical basics all the way up to advanced service configuration.
Happy Christmas.
iamjeffvader's studymotron and rantatorium 