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
Static RPKI in Nokia SROS15
Here is a quick look at static RPKI on the Nokia 7×50.
Resource Public Key Infrastructure is a security measure which attempts to solve, or minimise, the impact of prefixes being disseminated from invalid source ASNs. This is where an AS will hijack and originate a prefix when it does not own it. Sure this can be because of a legitimate mistake but it can also be used for being naughty.
You can use dynamic or static mappings to confirm the legitimacy of the prefix origination. Here I will use static only.
To demonstrate this we will originate prefix 192.0.2.1/32 from ASN 64497 (legitimate owner) and ASN 64496 (naughty people). ASN 64498 will use static mappings to decide which is the source of truth. For reference sros1 is running release 14, sros3 is release 13 and sros8 is the all new release 15 router.
First we configure the loopback addresses and BGP sessions.
All we have done here is configure a loopback on sros1 of 192.0.2.1/32, set our ASN to 64496 and configured our BGP parameters for our session to sros8. We configure the equivalent BGP config on sros8
We then confirm sros8 is receiving and installing 192.0.2.1/32 as the best path.
Before we look at competing ASNs let’s enable prefix validation on sros8.
We can configure our dynamic relationship with a server under the rpki-session config context or we can configure statically. As I don’t have the option of using RPKI server mappings right now I choose static. Here we configure an entry that covers anything within 192.0.2.0/24 up to a prefix length of /32. This covers off the 192.0.2.1/32 prefix I am receiving from sros1. We then specify the ASN of the source and either tag it as valid or invalid. Here we are going invalid as we know AS64496 should not be originating this particular prefix.
If we look at our local database on sros8 we can see a flag of Static-I set. This means it is statically configured as invalid.
Now will BGP reject the prefix? 
No because we haven’t told the BGP process to do anything with the origin validation information yet. We need to enable origin validation within the BGP group context.
So now we have enabled origin validation with the BGP group config we still have one step to carry out. As shown above we need to tell the BGP process that anything marked as origin-invalid should be considered unusable. Once we make that change the path will no longer be considered in the best path selection process.
Now what if AS64497 starts legitimately advertising 192.0.2.1/32, will we allow this? One would hope so!
We now have our peering up to both sros1 and sros3, both of which are sending us 192.0.2.1/32.
On the prefix received from sros3 we have an origin validation state of NotFound, basically not explicitly valid or invalid. sros1 reports the state as invalid and, as we saw, it cannot be considered for best path determination.
iamjeffvader's studymotron and rantatorium 