Archive

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.

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 ####

OK so we have configured our IGP and we have full reachability within the core network. In order to provide MPLS VPN services we are going to need some protocol that will signal labels for both the transport addresses and the services. For the transport we can use LDP or RSVP and for services we can use BGP as well. This post will focus on LDP only.

Label Distribution Protocol is pretty much the awesomest protocol you can have. It’s very easy to configure, easy enough to troubleshoot and is scalable. I love it cos it’s difficult to mess up which means less of a mess for me to clean up when someone does!

LDP is the standardized version of Ciscos Tag Distribution Protocol, a.k.a TDP. It was developed by the IETF and is covered in a multitude of RFCs but the basics can be found in RFC5036, LDP Specification. For neighbour discovery (link local), LDP uses UDP port 646 and multicasts to 224.0.0.2. Once discovered, neighbours are maintained through TCP port 646. Targeted peers use the same function except the destination address is explicitly specified and unicast. Have a read of the RFC, it’s not the worst.

Anyway on to the 7750s and how we enable LDP.

Like the majority of protocol happenings the LDP configuration section is within the config router context. Entering the LDP subconfig admin enables the protocol on the router.
A:r2# configure router ldp

Once we have enabled LDP we need to put specific entities in to say where we want LDP to run, what variables we want to attach to each interface and if we want to specify targeted parameters.
First we will put our interfaces in to the process, the interface to r5 is used here:
*A:r2>config>router>ldp# interface-parameters
*A:r2>config>router>ldp>if-params# interface "tor5"
*A:r2>config>router>ldp>if-params>if# exit

Next we will want to specify some peers so that we can do authentication and neighbour specific parameters.
*A:r2>config>router>ldp# peer-parameters
*A:r2>config>router>ldp>peer-params# peer 1.1.1.1
*A:r2>config>router>ldp>peer-params>peer$ authentication-key labldp

Now by far the most useful command with LDP is show router ldp session, it will tell you who you have an adjacency with and if its link local or link local and targeted, displayed as both, and you will want both for services.

Now if we look at our peers we will see nothing to 1.1.1.1 even though we just configured it, wtf!? That’s because you need a reason to signal a targeted session as 1.1.1.1 is not directly connected to r2. You can do this in a couple of ways either by creating an explicit targeted relationship or creating a SDP. We will use targeted here as SDPs will be covered when I get on to services.
*A:r2>config>router>ldp# targeted-session peer 1.1.1.1

Of course we configure the equivalent on the remote side at r1. What is the result? r1 becomes a targeted peer:
*A:r2# show router ldp session

So what else can you do to tweak LDP? Interestingly you can enable fast reroute on it but since I only just saw it I have never tried it, maybe give that a go when I get on to RSVP FRR:
*A:r2>config>router>ldp# info detail | match fast
no fast-reroute

Under interface config you can change a few things, nothing really fancy. You can alter the local keepalive timers here but I dont set them away from default as I use the IGP and BFD to determine when something has failed. If you want to its hello # or keepalive #.

You can also bind BFD to the LDP interface by simply typing bfd-enable under the interface.

You can change the transport address away from the system address by setting it to use the interface address itself:
*A:r2>config>router>ldp>if-params>if# transport-address interface

There are lots of other things like tunnel in tunnel, or LDP over RSVP, that you configure here but I will leave those more advanced things for another time. I will finish up with import/export policies and controlling label propagation.

First off I am going to put a loopback interface of 44.44.44.44/32 on r4 and advertise it in to OSPF. This will cause a label to be allocated, or will it? No it won’t, not on a SROS box. On a Cisco router it would but the 7750s (and other SROS routers) will only advertise the system addresses by default. We need to use a policy to cause a label binding.
*A:r4# configure router interface loo44
*A:r4>config>router>if$ address 44.44.44.44/32
*A:r4>config>router>if$ loopback
*A:r4>config>router>if$ back
*A:r4>config>router# ospf area 0 interface "loo44"
*A:r4>config>router>ospf>area>if$ passive

OK so we should have the route in OSPF now but no label associated:
*A:r2# show router route-table | match 44.44.44.44
44.44.44.44/32 Remote OSPF 00h03m41s 10
*A:r2# show router ldp bindings prefix 44.44.44.44/32 | match Match
No Matching Entries Found

Now lets look at import policies, this is sooo not a real world example but it gets the point across.

In this example I am using r2 again. It is receiving a label for r4’s system address and allocating one for downstream distribution to r5, nothing unusual with that.
*A:r2# show router ldp bindings prefix 4.4.4.4/32

So here we see we have selected the label of 131069 directly from r4 as this is our IGP shortest path to 4.4.4.4. I am going to create a policy that will deny 4.4.4.4 from the peering to r4. You might think that forces us to use the label from r3 or r5 but as they are not on the IGP best path they wont be active label bindings. The policy will use a prefix list to match 4.4.4.4/32 and deny it, breaking any LSP going to or through r4. OK caveat time, I am only showing this so you see the danger of filtering labels and so this can be avoided. Breaking the LSP is going to get you in lots of trouble, don’t do it unless you have a good reason.

This post will cover setting up OSPF as your IGP, IS-IS will be covered separately.

First off we need to enable OSPF. Make sure you have your system interface configured before this point or your RID will be based on the base MAC of the chassis and will look like a public IP.
A:r2# show router interface "system" | match /32
2.2.2.2/32 n/a

If you forget or need to change the RID you need to config router ospf shut followed by config router ospf no shut. There is no command like clear ip ospf process in IOS.

So once we confirm this in place we can go ahead and enable OSPF so let’s do that.

The router will use the system address as the RID but we will statically configure one anyway. We will also make the routers an ASBR. This is quite important as simply redistributing prefixes in to OSPF with a policy doesn’t actually send any prefixes to OSPF without the ASBR command in place, the source of many an early days headaches. We will also enable traffic-engineering extensions so we can run MPLS TE, we will need it later.

BTW configuring something for the first time changes the prompt to $ but as I have already enabled OSPF and am just retyping commands the prompt appears as #

Now we want to configure some interfaces in to the process and we will start by creating area 0.0.0.0. This is where you should place your system interface unless you are a stub area router and not an ABR. The system interface is broadcast type by default and passive so I will set the interface type to point to point, and passive just to demonstrate the command.
*A:r2>config>router>ospf# area 0
*A:r2>config>router>ospf>area# interface "system"
*A:r2>config>router>ospf>area>if# interface-type point-to-point
*A:r2>config>router>ospf>area>if# passive
*A:r2>config>router>ospf>area>if#

Now lets configure an interface in to area 0 and give it some meaningful configuration such as link cost/metric, bind it to the interface BFD instance and force authentication using the password mypassword

To create a Totally Stub Area then we put the no summaries option under the stub configuration.

MTU obviously plays an important part in OSPF and every network engineer has been mind boggled by it at some stage in their career, exchange start anyone? To set it under an interface its simply mtu # where # is the value you apply. The maximum you can set is 9198, on my routers anyway.

A couple of miscellaneous commands now. If you wish to stop advertising subnet routes for an interface you configure no advertise-subnet if that floats your boat. Finally on the basics, if you have DR set up with type 2 LSAs for some reason (not a fan, it’s just messy), you can set the interface priority to bias the DR election. Simply configure the priority # command

(Yep I didn’t actually configure area 5 for tor5 🙂 I’m running some tests at the moment so can’t be messin with that!)

show router ospf interface shows you which interfaces you have OSPF running on, the DR/BDR, area and interface type. Unlike show ip ospf interface brief in IOS it doesn’t give you the interface cost. For that you need to use the detail option, which can be for all interfaces or a single one if you specify it:
*A:r2# show router ospf interface "tor4" detail | match "Oper Metric"
Oper Metric : 100 Bfd Enabled : Yes

show router ospf database -or- show router ospf opaque-database (for the TED) gives you access to the OSPF database, strange huh!? You can use the usual qualifiers to get in to more detail on the LSA contents:
*A:r2# show router ospf database
- database [type {router|network|summary|asbr-summary|external|nssa|all}] [area ] [adv-router ]
[] [detail]

I’m not going to show the output of these commands cos it’s just too much space for a post.

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.

In this post I will focus on creating interfaces so it will be a short one because there isn’t much to write home about.

The first thing to know about SROS interfaces is they are named and you bind a physical or logical port to them. The naming of the interface is called in all protocols so you need to make sure you get it right and have a clear convention as deleting the interface will destroy the protocols use of the interface. If you have an OSPF interface and you remove the router interface then OSPF will drop and your network maybe go a little crazy.

So how do we configure them? It’s pretty straightforward and there is no need to create here. Good ol’ ALU consistency.

*A:pe1# configure router interface "to_pe2"

And that’s the interface created. We then need to assign our IP address:

*A:pe1>config>router>if$ address 192.168.123.1/24

You can also run ipv6 over interfaces, which is enabled with the ipv6 command. You need to be in chassis mode C at a minimum and I can’t change that right now…You can do pretty much anything standard, icmp6, DHCP, VRRP.

Then we need to bind this to a physical interface:

*A:pe1>config>router>if$ port 2/1/3:123

Next you might want to run BFD over the interface to use very fast failure detection. The 7750 can be configured to support 10ms transmit intervals but it does require configuration relating to the processor. I have never tried it that low so I dont know what impact it will have on processing.

*A:pe1>config>router>if$ bfd 100 receive 100 multiplier 3

You can assign some CPM protection but I haven’t played with this either so I don’t know how it would benefit you. Something for another time when days allow more than 24 hours in them!

If you want, make the interface a loopback but obviously you need to remove your port binding with the no port command.

If you wish to make it an unnumbered interface you simply configure it with unnumbered and specify an interface name or address you want to take the IP address from.

To configure a secondary interface you simply apply secondary x.x.x.x/y

Finally you can configure VRRP with all the standard bits and bobs that entails. Here is a little snippet that creates the interface as the owner, specifies the partner router as .3, sets the priority to 200 so this interface will be the boss unless there is a problem. You can also tell the interface to reply to pings and traces regardless of it’s state as master or backup which is a pretty cool feature. Finally you can set the delay VRRP takes before establishing for situations where you have a link that may be bouncing.

There are some things you can do with BFD in a VRRP instamce but that will have to wait to my Services posts as it’s more relevant here. Anyway today is day 1 of my CCIE SP study so I have to get down to business there.

Typing info will show you configured commands within your present working context, which itself can be viewed with pwc. Using info detail will show all commands in the pwc including defaults, a very useful one!

As mentioned in my previous post / allows you to parse a command that would otherwise not be available.

tree will show you a tree structure of all available commands within your context

Matching:

The availability of pipe commands is very useful in many OS, SROS being no different. You can pipe any show, info or tree command to include or exclude variables but you can’t concatenate multiple matches in to one string:

info | match address will display any lines with ‘address’ in it

info | match match-not address will display all lines excluding ones with ‘address’ in it

info| match pre-lines 10 address will show you the 10 lines of config prior to a line with address in it,

info | match post-lines 10 address will show you the subsequent 10 lines of config if ‘address’ is matched.

Both the pre and post line match commands are very useful for locating config lines in large files. I frequently see files with over 10,000 lines of config, a downside of the granularity of SROS.

You match a string with spaces by using speech marks:

info | match "address 10" will show you anything with address 10 in the line, such as all network 10 addresses configured.

Who-am-I?

Configuring systems for human identification is crucial in an operational environment for obvious reasons. Here we look at configuring systems name, location information, banners and NTP

I’m not a security person by any means but it is always something we need to be conscious of. At a minimum we should be setting local authentication on a device. To set up secure access we can configure a local user:

You can configure stuff for the SAM5620 manager but I won’t go in to hit as I don’t have a test SAM server.

CPM Filters

CPM filters are what protects your processor and it’s protocols for being compromised, such as OSPF neighbours from a specific subnet. These are not available on the SR1. Extreme care should be take as no-shutting the filters before allowing your own access method can disconnect you from the chassis, and there is no remote way to fix it without out of band. In this section we will configure basic SSH access control and OSPF.

You should configure all your protocols to be permitted where required and only no shut the CPM filters when you have permitted your own access, e.g. a SSH filter permitting a source subnet you are on. I will post something on CPM protection when I dabble in it, it’s on my list of ‘to investigate’.

The last thing I want to mention under the configure system banner is the chassis mode. This controls service resources including FIB sizes and can be A, B, C or D. The SR1 supports mode A only which is somewhat limited.
Mode B allows 128k MAC FIB entries and the same ipv4 ARP entries. Mode C must be enabled to allow for IPv6 but chassis mode D is the most scalable. Mode D can support up to 500k MAC and an equivalent amount ARP entries. The chassis mode you run can only be as good as the line cards you have installed. If you have IOMv1 or v2 then you cannot run mode D regardless of the amount of higher spec cards. If you have IOMv3/IMM only then you can run mode D. Upgrading a chassis mode does not impact service traffic but downgrading, say from C to B, requires a reboot. It is enabled using configure system chassis-mode [a|b|c|d]

That’s it for this post, the next ones will relate to actual network build. I will do up a Visio with the topology and start at bringing the physical network up.