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!

Advertisements

Tidbit: VLC for Multicast Testing

Its pretty well documented on the lovely inter tubes that using VLC to stream multicast is a pretty slick way to test out a multicast setup. It’s also pretty well documented that you need to change the TTL for multicast in VLC to something other than the default 1 or 0 or whatever it is.

Okay cool, so no problem right? VLC has a pretty nifty little “wizard” to set up a stream. Click next, type a group address to use, pick a flavor (UDP or RTP), pick some transcode stuff, and last page (on OSX, also somewhere in Windows, but maybe not the last page) the magical “TTL” setting. It starts at 1. Okay great, so we already know we need to change this… so put it to 10, or 100, or whatever you want.

So cool, time to test. Start with a sender and a receiver in the same subnet just to test it out — easy money, of course that works. Okay great, so next lets move between subnets. WTF. No dice. You know you can set up PIM dense mode…. its possibly the easiest thing ever. Turns out that the little TTL thing you thought you set didn’t really do anything. At all. Nothing.

So if you take a journey to the “Preferences” page and do the “Show All” in OSX, or “Advanced” (or something of the like) in Windows, there just so happens to be a section for “Stream output.” Well in said section there’s another menu called “Access output.” In this menu, there’s ANOTHER TTL setting. So you thought you set the TTL before to 10 or something, but this one still says NOT THAT!!! GRRR!!!  Change this to whatever you need, and wham bam thank you ma’am (assuming your multicast setup is good) you’re off and streaming!

 

I’d love to link to the other blog that lead me to discover this, but I can’t seem to re-find it. So hopefully this helps somebody else out!