IOS-XR Route-Policy

I said when I started this blog that I would write about some cool IOS-XR stuff that I’d been learning, and I’ve totally 100% failed to do that yet. So here we go!

I’m going to use this post to basically just annotate a cleaned up RPL that I’m using at a current customer. The following RPL is being used at the Internet edge at their peering to ISPs. This customer is actually a colo, so it’s maybe a bit different from you’d see at a typical enterprise.

route-policy RPL_[ISP1]_Inbound
 apply RPL_Deny_Bogons
 apply RPL_All_Provider_Inbound
 apply RPL_[ISP1]_All_Prefixes
 apply RPL_[ISP1]_Provider_Local_Prefixes
 end-policy

Hah! Look easy as that, just name route-policies something that sounds like it would do something cool, then it magically does it!! Okay, more seriously, route-policies can easily call other route-policies. The whole approach is far more programatic than in ‘regular’ IOS. Lets take a look at the first RPL that we are calling ‘RPL_Deny_Bogons’ which does as you would suspect — denies bogons in incoming BGP updates (shouldn’t have any, but just in case!):

route-policy RPL_Deny_Bogons
 if destination in PS_Bogons then
 drop
 else
 pass
 endif
 end-policy

So obviously this is way different from IOS. As I said, it’s basically just programing what you want to do. IF/THEN statements are now your friend! In this policy, IF the destination is in prefix-set (XR prefix list syntax), THEN ‘drop.’ Drop is of course the same as deny. ELSE, as in if prefixes do not match the IF statement, pass, which does as expected also — passes the prefixes on for further examination.

For reference, here is what a prefix-set looks like in XR:

prefix-set PS_Bogons
 0.0.0.0/0,
 0.0.0.0/8 le 32,
 10.0.0.0/8 le 32,
 127.0.0.0/8 le 32,
 169.254.0.0/16 le 32,
 172.16.0.0/12 le 32,
 192.0.0.0/24 le 32,
 192.0.2.0/24 le 32,
 192.168.0.0/16 le 32,
 198.18.0.0/15 le 32,
 198.51.100.0/24 le 32,
 203.0.113.0/24 le 32,
 224.0.0.0/4 le 32
 end-set

Moving onto our next called policy ‘RPL_All_Provider_Inbound’; this is a generic type policy to be applied to all provider peering sessions. The intent here is to strip any inbound communities (which I believe does not apply to well-known communities) from prefixes, then apply a community that can be used internally to reference any provider learned prefixes. Finally, the local-preference is set to 90. This last bit is just to ensure that routes learned via colo customers are preferred locally instead of from providers (even though AS-path *should* take care of this — just in case!!).

route-policy RPL_All_Provider_Inbound
 delete community all
 set community COMM_Any_Provider additive
 set local-preference 90
 pass
 end-policy

This one doesn’t show us much of the ‘programatic’ style of XR, but does show that it is pretty easy to understand if you are used to route-maps in IOS. Community-lists are also pretty similar to IOS, here’s an example as used above:

community-set COMM_Any_Provider
 1:1
 end-set

Wrapping up the policies, these last two assign communities to all routes learned form a particular provider, and another community to routes local to the provider (Provider ASN + 1 hop). The logic for these are just to allow as much granularity in matching prefixes as possible in as simple a possible way in the future.

route-policy RPL_[ISP1]_All_Prefixes
 set community COMM_[ISP1]_All_Prefixes additive
 pass
 end-policy
 !
 route-policy RPL_[ISP1]_Provider_Local_Prefixes
 if as-path in AS_[ISP1]_Local then
 set community COMM_[ISP1]_Provider_Local additive
 pass
 endif
 end-policy

Pretty cut and dry here. Note that the ‘additive’ keyword is just like IOS, use that if you don’t want to overwrite all the communities on a prefix. The second policy above matches an as-path just like you can in a route-map. Heres a basic as-path-set:

as-path-set AS_[ISP1]_Local
 ios-regex '^65535_[0-9]*$’
 end-set

Above we just match an AS-path of ’65535’ plus one hop (as an example). RPLs also give some cool functionality such as matching a prefix that ‘passes-through’ an ASN. You can also match things inline — instead of calling prefix-sets etc. Hopefully I will get to write about some more of that later!

Cisco XRv Impressions

I’ve been begging random Cisco folks that I meet for a copy of XRv, XR4U,CML, VIRL for a while now… it hasn’t worked very well… at all. This month Cisco has finally released XRv though, so now I have a new toy to play with! I’m not 100% sure what entitlements are required to be able to download this, but I was able to successfully download it sometime last week.

I won’t bother with talking about how to download it or install it because there are already plenty of posts in forums including a very in-depth post from Fryguy (@FRYGUY_PA) over on his blog about the install. One thing to note is that the ESXi Enterprise license is required in order to setup the Serial over Network feature as described in his post. Since I don’t have that, I had to do a bit of a work around with named pipes and serial ports. Heres some quick screen caps to show the setup:

XRvSide

In the above pic you can see that this serial port is basically configured with a named pipe, that this end, the “near” end, is a server (our XRv device), and the far end of the pipe goes to another virtual machine. The other virtual machine in my case is just a simple Ubuntu box with a serial port that is configured in the reverse of the above. In the Ubuntu VM I used screen to pop onto the TTY: “screen /dev/tty.S0” — I’m sure there are better/different ways to do that, but that worked for me.

Once you are “consoled” into the XRv device, you can assign an IP address to the management port (the first adapter you assigned by ESXi is the management port). I put this management port onto my normal home network. At this point things are “ping-able” and that’s pretty exciting (assuming you are lazy like me and have a “flat” network at your house), but telnet/SSH won’t work at this point. Via your console session, you can enable telnet as follows:

telnet ipv4 server max-servers 5

Note that the ‘5’ can be 1-100, I just used five for kicks. If your training has taught you to loathe telnet and not want to configure that you can easily setup SSH like this:

ssh server v2
 ssh server vrf default
 domain name home.lab
 crypto key generate rsa general-keys SSH

In the above snippet, obviously enter whatever domain name you would like, the final line there is an exec level config — ‘SSH’ is just a name for the key pair.
If you are not used to IOS-XR — you will have to remember to ‘commit’ changes that you make, luckily for you IOS-XR will do a pretty good job of barking at you to telling you that you forgot to do so!

Last piece here — if you are NOT lazy like me and have multiple subnets and would like to be able to reach your XRv device from any of them, you can set up a simple static default into your home network simply:

router static
  address-family ipv4 unicast
   0.0.0.0/0 [NEXT HOP]

So now that I’ve got this nifty XRv device humming along whats the deal. To answer that lest back up from the technical stuff for a bit. So whats the point of XRv? For me, the best part is that I can now lab some seriously cool and complex stuff that you just can’t do in GNS3. I’m sure that’s a nice plus for Cisco too, but that doesn’t make them much/any money (perhaps they will do a “study” license in future releases or more likely they will just do that with CML as has been discussed), and doesn’t really and any value/benefits for their customers.

I think more importantly (to Cisco at least) than the training/CML use case is the ability to use this as a virtual route reflector. Consider that in many scenarios route-reflectors are usually nothing more than a device with a bunch of memory to handle big routing tables and occasionally send them out when a client router goes offline and comes back up. That router isn’t actually in the transit path for any customer traffic at all, it’s just there to keep the tables and hand them out as needed. There is basically zero good reason to have that on an expensive ‘five nines’ physical router. Why not use XRv to leverage existing virtual environments, I’m assuming (not 100% sure but don’t see why not) it can be vMotion’d to allow for maintenance of the physical hosts; that’s surely a lot cheaper than buying two physical routers for redundancy, or loading up routers with multiple RPs etc. I really like this idea, and in fact have a customer right now that could really benefit from this type of flexibility.

Anyway, enough with that, lets see what I’ve found that works and doesn’t work so far.

Things I’ve gotten to work just like the real deal:
OSFP; haven’t done a bunch yet, but everything I’ve poked seems to work so I don’t see why there would be anything not working here.
EIGRP; same story.
Static; ditto.
Obviously it can be bridged into physical networks no problem. There was a thread somewhere that said that ESXi only supports up to 10 vNICs per host but XRv supports up to … some very high number. I’m not sure about either of those facts, but they sound legit! Though I think that’s mostly irrelevant for the ‘real world’ potential use case of route-reflection, and also probably not that big of a deal for lab too.
RSVP; its configurable without screaming at me… seems like a good start.
Multicast-routing; ditto RSVP.
Explicit path configs.

Things not working for sure:
BFD, don’t get any sessions to come up in OSPF… can try more later.

Things I’m 99% will work and will hopefully test soon:
L3 VPN — since it looks like everything required to do this work, can’t imagine it won’t work.
MPLS TE (sans fast reroute because of BFD)

Things I’m 99% sure will NOT work and will hopefully test soon:
L2VPN; it seems to want to accept configs for this, but I’m skeptical it will work…. we shall see

Misc:
CDP to physical stuff; network in ESXi is in promiscuous and all that fun stuff… CDP in GNS3 works in this fashion so this may warrant a bit more exploration. CDP between two XRv instances doesn’t appear to be working either. I would have thought this would work, but that may be due to the ESXi config stuff.

 

That’s all I’ve got for now. Bottom line is that XRv is pretty slick and I’m glad to finally have my hands on it. At this point I don’t think its a viable replacement for rack rentals/physical gear for CCIE SP lab use, but it certainly won’t hurt. I plan to try and write some more about XRv at some point hopefully soonish (but I’ve planned to write more about the DMVPN/BGP post too…. see how that’s working for me).