Next chapter
I’m giving up the consultants life and starting a real job next week in Riot Games. In the meantime I’ll be working on the JNCIE and will link to any videos I do. Most likely here. https://www.youtube.com/channel/UCYokd2B0yiDopbAZn_0Vz4g
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.
Loophole the BOF
If you have a lab and you want to connect to your SROS routers mgmt interface from wherever, you may know you cannot configure a 0/0 static route. Want to get around it? Configure something like the below.
#### Don’t do this in production! Don’t do it if your lab is not secured ####
*A:r5>bof# static-route 0.0.0.0/0 next-hop 192.0.2.254
MINOR: SYSTEM #1505 Invalid static route destination prefix – cannot configure default route on the management interface
*A:r5>bof# static-route 0.0.0.0/1 next-hop 192.0.2.254
*A:r5>bof# static-route 128.0.0.0/1 next-hop 192.0.2.254
Studying for the Alcatel-Lucent NRS1 exam?
I have written a study guide entitled “Network Routing Specialist 1 – A Beefed-Up Self Study Guide” which covers the NRS1 track but digs deeper in to protocol function to a level that you might expect to see in the NRS2. Inside you will find chapters covering the 7×50 and 7210 hardware, tips and tricks on navigating the CLI, end of chapter quizzes and a lab covering IGP, MPLS, BGP and services.
The ebook is almost 700 pages long and technical content review was provided by Darren O’Connor and Davide Barbaro.
If you are interested please check out my business site https://snu.training/books.html
The book is now priced at $29 and is available in pdf or epub format.
Alcatel Lucent Service Routing Architect Lab
I took the SRA lab a couple of weeks ago and got my result late last week (a pass). Unlike the CCIE there isn’t really any information about going for the SRA in terms of logistics so here you go, here is how I got to Antwerp and how I got on.
I flew in to Zaventem from Dublin (with Aer Lingus). Ryanair also fly to Charleroi (never going through that nightmare again) and Cityjet fly direct from Dublin to Antwerp. I elected to go with Aer Lingus as the timing worked out better. The lab is from 8:30 to 5ish. From Brussels airport I took the De Decker coach to Antwerp Central Station (Queen Astrid Square I think). It cost 10 eurodollars, an absolute bargain. The bus departs on the hour from Zaventem and takes around 45 minutes to Antwerp. If you have been to Diegem then you know where the bus to the Cisco hotels go from. This one is in the same area, on the far left with blue paint on the ground at the stop. Here’s a fancy link .
If you have never been to Belgium before and are a native english speaker then you will find most people have an excellent level of fluency, seems par for the course in Benelux. I speak French but was advised against doing so in Flanders.
After the short bus trip I got to central Antwerp at around 11am the day before my exam. Once you get off the bus there is a fabulous looking central station. ALU are about 10 mins walk from here. Go in to the station and keep walking past all the diamond shops until you get to the end of the station. Turn left out the glass doors and ALU are just to the left of the station.
I stayed in the Linder hotel, there is also an Ibis within 1 minute walk from ALU. It was about 180 euro for the night with breakfast and dinner, they have a sky bar where I had some coffee and tried to do some labs. Some poor soul was doing his soundcheck for thats nights performance so it was loud and he was rubbish, lucky I brought my headphones. I walked the 1 minute round to ALU just to make sure the reception area was where I was due to go in the morning. I then had some nice organic fruit and pastries in a cafe type thing beside the hotel. Le Petit Dejeuner I think it was called (obviously no one told them speaking French in Flanders was uncool, or maybe the joke was on me), staff were really nice and the food was good. After that I went back to my room and had a nap. A bloody nap! Who does that? I have sleep apnoea so I like to snooze whenever I can. I got up after a few hours and had dinner in the hotel, fine, reasonable quality then I went to sleep for super serial around 8pm. Big mistake, I was up at midnight til around 4am, dozed off until my alarm went off at 5:30. Breakfast wasn’t until 7 but I wanted to do some scenarios beforehand, couldn’t focus though.
Unlike when I sat the CCIE I wasn’t worried at all for this one, in fact I was expecting to fail as I didn’t prepare, and I had budget for a second attempt if required. Because there is so little information on the SRA I thought a recce attempt would be a worthwhile investment.
At 8:10 I went round to ALU and was there around 8:11 🙂 and waited in reception for my proctor. Like my NRS2 attempt my proctor was cool, explained the rules etc and off I went.
I had an initial read of the paper (which I didn’t do for my CCIE) and checked out all the diagrams. I redrew them out on the paper the proctor provided me with, working pens too! Take note Cisco! All the SROS config guides were available in a folder on screen, I consulted them a few times, again I hadn’t really prepared. You know all the ALU courses and study guides, they have 6 routers in them. I use a network of 14 lab routers in the day job which was fine.
Now here is where I can’t really say any more detail. I will say this, I would consider the exam somewhat on par with the NRS2 but with more complicated subject matter. I found it relatively straightforward, finishing well within the allotted time and taking it easy at that. I left after 6 hours having rechecked a couple of times. I find some questions ambiguous in most exams, must be very hard for non native English speakers. I made the decision on how to proceed based on what I felt was more logical in an exam environment. For example if you need to change a service parameter that is tied to a physical element, don’t change the physical element, accommodate that restriction in your solution. These exams are there to make you think right? Not just go for the easy option. Whether I was right or wrong I don’t know but I did enough to pass.
After the exam I went back to the same bus stop and waited for the bus. In the lashing rain. For 45 minutes. The bus was 10 euro back and even though this was around 4pm and traffic was awful our route seemed to go against all the traffic. Always a plus. Compulsory purchase of the Belgian chocolates for the family and off home.
I haven’t completed the SRA yet, I still have my elective written exam to complete, which is a weird kind of limbo to be in.
Jerry Springers final thought: If you prepare with the ALU scenarios then there is no reason you shouldn’t pass this exam. If I give the CCIE SP a 7-8/10 in terms of difficulty then this one would be a 4-5/10. Maybe it was easier cos I had already done the CCIE, I don’t know. It’s certainly not the hardest exam I’ve ever sat. If you know what you are doing in theory and in practice, and not just learning by rote, then you should pass no problem.
SAVE YOUR CONFIGS OFTEN!! These are sims so they can break.
The perils of CPM filters and how to use them – 7750 SROS
Control plane filtering on the 7750 is managed with CPM filters, any time you want to secure you device or protocols you need to use these guys. They are basically access control to the processors and used wisely they are incredibly powerful. Use them foolishly and they may cost you your job. Configure them incorrectly and you can isolate your node or bring down your entire network! There is an urban legend that someone made a change to CPM filters from SAM and pushed them out to all nodes and unfortunately all remote access was lost, mega truck roll time!
****************** Caveat and warning time ******************
I am writing this post from memory, with some output I was able to find. I don’t have
any lab equipment to test this on so nothing below can be considered tested and/or safe
to deploy. You can do some serious damage with control plane filters. Do not deploy
without doing your own testing and/or vendor support. I’m not taking responsibility for
your actions. I can’t over emphasize testing every single change no matter how small.
**********************************************************************
OK so now the formalities are done with what can CPM filters do? I guess the first thing is they are not supported on the SR1 (or the 7210, they have other methods) so you need a bigger router. Like I said above they allow us to permit or deny addresses and protocols access to the CPM. You can configure MAC, IPv4, IPv6 filters but we will focus on IPv4 for today.
The first, and probably most crucial, is the default action applied to the filters. If you have no filters configured and you set the default action to deny then get in your car and head to site. Let’s set the default to accept which you should always do when you are making the filter list for the first time.
configure system security cpm-filter default-action accept
For reference the keyword to set the deny all else is ‘drop’ instead of ‘accept’
Now we have allowed all access to the routers control plane. Anything else we specify will either be allowed or dropped. Anything we don’t match at this point will be allowed as well, highly insecure. It’s up to you to determine your security policy and ensure it is based on best practice.
For the remainder of this post we will look at OSPF ensuring it is secure (we still need authentication of course). We will create filters for OSPF but also create a log mechanism to ensure any denied traffic is signalled to the operations guys. We will permit what we want, explicitly denying what we don’t and ignore the default action until the end.
Let’s configure the prefixes we want to match against and allow, assuming the neighbours are on 10.10.10.0/24
configure system security cpm-filter ip-filter entry 10 create description "allow ospf" action accept match protocol ospf-igp src-ip 10.10.10.0/24 exit exit
Lets deny all other OSPF
entry 20 create description "drop all other ospf" action drop log 123 match protocol ospf-igp exit exit
If any OSPF traffic not sourced from 10.10.10.0/24 hits the CPM it will be dropped and because we have the default action set to accept all traffic will be successful beyond this.
In order to verify if packets are being processed or not issue this command and you will see something similar to the following:
show system security cpm-filter ip-filter =============================================================================== CPM IP Filter (applied) =============================================================================== Id Dropped Forwarded Description ------------------------------------------------------------------------------- 10 0 648 "allow ospf" 20 11 0 "drop all other ospf"
What this tells us is 648 packets have been accepted sourced from 10.10.10.0/24. These will allow us to form adjacencies. The makey-uppy 11 dropped packets are assumed to be from any other address that we don't trust. You can see more detailed output on a per entry basis by specifying entry $number$ in the show command.
Now you will notice the log 123 statement in the deny entry. This will allow us to have a record of denied OSPF packets by sending entries to syslog.
First lets configure a syslog specific log
configure log syslog 2 description "send naughty ospf to syslog server" address 172.16.1.1 exit all
Here we are saying log 2 is used for syslog and the IP of the syslog server is 172.16.1.1. We now need to reference the syslog credentials in the filter log.
configure filter log 123 create description "log for untrusted ospf" destination syslog 2 wrap-around no shutdown
What we have done now is send logs for entry 20, based on its mapping to log 123, to the server listed in syslog 2. It's extra work to do all this but it's this type of modularity that I like about SROS.
So what have we achieved? We can now form adjacencies with our neighbours without being open to any attack from other routers outside of our controlled prefix. Of course we must secure our entire control plane as best we can. You should look to permit your IGP, LDP, RSVP, BGP, VRRP if you use it, multichassis protocols such as MC-LAG, BFD along with management protocols such as TACACS, SSH, NTP etc. This list is by no means exhaustive, you need to analyze your network traffic to see what you have hitting your CPMs. Once you have identified all relevant traffic, test your filters then set your default action to drop using
configure system security cpm-filter default-action drop
CPM filters are a must but they need to be respected or they will create more work for you down the road.
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.
End of an era and new stuff
I have been with my current employer for almost 15 years, that’s pretty much my entire adult life. Turns out passing the CCIE opens a lot of doors so I resigned and I am off to try out the world of contracting.
How does that impact on my blog? Well as sporadic as my entries might be I do enjoy writing and plan on keeping going. I’ve committed to passing the SRA within the next 6 months at most so I will be posting more relevant stuff to that. I won’t have access to a lab 24/7 and will have to buy time off mysrlab which seems very expensive but what can you do. The sooner ALU release their vsim the better (around 12.0r4 apparently).
Anyway watch this space as I prepare for the NRS2 lab, complete the remaining 3 writtens for the SRA and then finally the SRA lab itself.
RPF on the 7750
Burak recently asked for a post on RPF loose and strict modes and how they behave on the 7750. I have quit my job so I have been frantically trying to get things finished and handed over and haven’t had time to really test anything for my own amusement. As I will be finishing up tomorrow and won’t have access to any 7750 lab stuff this is a real quick thrown together post.
We will use a simple network of four routers. All routers have all interfaces in OSPF area 0 with the same cost of 10 on each link. OSPF preference (AD) on the 7750 is 10. We configure a static route on r1-rack3 pointing 1.2.3.4/32 out to r2-rack3, its preference is 5. r1-rack3 is at 10.9.254.28
So what does the topology look like from r1-rack3s perspective?
and what does r5-rack15 think?
r5-rack15 is going to send traffic on the direct path to r1-rack3 but r1-rack3 thinks 1.2.3.4 should be reachable via r2-rack3. Let’s enable RPF on the interface and see what happens (ignore the IntraAS in the name, it’s from another test).
I have now enabled loose mode RPF. Theoretically traffic should pass here as once the prefix is in the routing table it should be ok. First clear the statistics (you need to use the urpf-stats variable to clear RPF stats or they won’t clear down)
Now we send a ping from r5-rack15 sourced from 1.2.3.4/32.
As we can see the pings are successful. This is because even though r1-rack3 uses different egress than the received packets ingress, loose allows more flexibility in what the router will accept.
Happy days, our check fail stats have not increased. Now let’s enable strict mode and see it all fall apart. Strict mode means you MUST receive the packet over the interface you would use to transmit to the destination.
Now when we ping from r5-rack15 to r1-rack3 we should not see a response to our packets arrive.
In fact debug router ip icmp doesn’t even show up failed attempts. They’re just ignored.
Look at that, beautiful. OK so it’s not a very elegant way of showing how it works but it does. I haven’t found a debug for RPF fails or anything beyond show router interface statistics to display any further RPF information. If you know of any stick it in the comments and I’ll add it.
iamjeffvader's studymotron and rantatorium 