Archive

Author Archive

Next chapter

January 4, 2018 Leave a comment

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

Advertisements
Categories: Uncategorized

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.cumulusbase.jpg

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.

local_host-vx.jpg

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.

vx_br.jpg

 

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

overallvx.jpg

BTW the user guide is really, really good. See it here cumulus_ug

Categories: Cumulus, labbing

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.

rpki.jpg

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.

r1.jpg

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

r8_bg_conf.jpg

We then confirm sros8 is receiving and installing 192.0.2.1/32 as the best path.

r1_bgp.jpg

Before we look at competing ASNs let’s enable prefix validation on sros8.

orig_r8.jpg

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.

stat_i.jpg

Now will BGP reject the prefix?  bgp_no_drop.jpg

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.

rpki_r8_wo.jpg

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!

rpki_sr3.jpg

We now have our peering up to both sros1 and sros3, both of which are sending us 192.0.2.1/32.

rpki_bgp_g.jpg

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.

rpki final.jpg

Categories: 7750, SROS

Loophole the BOF

April 12, 2017 Leave a comment

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

Categories: 7750, SROS

Studying for the Alcatel-Lucent NRS1 exam?

November 9, 2015 6 comments

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.

Categories: Uncategorized

Alcatel Lucent Service Routing Architect Lab

September 6, 2015 2 comments

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.

Categories: Uncategorized

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.

Categories: 7750 Tags: , , , ,