IOS XR Gotchas

I've recently started doing some work with IOS XR - I have to say I'm quickly getting to love XR and, if I'm honest, completely going off IOS as far as MPLS and BGP are concerned. I've found a couple of gotchas around the way RPL and BGP works as compared to normal IOS. Aside from the obvious need to type "commit" every time you make changes there are a few quirks that have caught me out - I expect I'll continue to add to this post as and when I get caught out by new and wonderful things.

No Policy = No Routes

One of the big, fun changes in IOS-XR is that if you don't apply either an inbound or an outbound route policy to a BGP peer then it assumes you've made a mistake and does not advertise or accept any routes at all. You can see that this is the case because the peer is marked with an excalmation mark (!) in the BGP summary.

The fix: apply either an inbound policy, an outbound policy or both.

Soft Reconfiguration Inbound

Another surprise when migrating to IOS-XR from IOS is that the rules for soft-reconfiguration have changed. Originally, before route-refresh capability came along, soft-reconfiguration was primarily there so that you could edit an inbound route-map and apply it without doing a hard reset on the BGP session. IOS-XR is a bit of a smarty-pants so if you configure "soft-reconfiguration inbound" and the peer turns out to support the refresh capability, it decides you don't need that local copy of the received routes - if it needs to apply an updated policy it can just request a refresh from the peer.

Most people who do a lot with BGP will be familiar with how useful it is to have a copy of all the routes received from a peer, including the ones dropped by policy, for troubleshooting purposes. Luckily, it is possible to force the router's hand by configuring "soft-reconfiguration inbound always".

Empty Prefix Sets Don't Work

IOS-XR has a new CLI construct called a set - mathematicians will already be familiar with these as an un-ordered group of items. In RPL sets can be used for communities or prefixes, but beware - if you create a prefix set but leave it empty, the CLI will accept it but any policies that reference the set will fail. If you're seeing a message like this:

% The policy [policy-name] uses an invalid argument to the [pfxmatch] condition on the [destination] field. Internal error:  no parameters

... then you've got an empty prefix set somewhere. Curiously it doesn't seem to mind about empty community sets. The workaround for this is to put a dummy prefix into any sets that need to be there but don't currently have anything in them.

Applying a Route Policy (or maybe destroying it!)

One nasty bit of CLI I've found is this: to apply a route-policy to a BGP peer you would type "route-policy policyname in" or "route-policy policyname out" under the configure -> router bgp -> neighbor context. If, however, you omit the "in" or "out" keyword, XR kindly assumes you want to blow away the policy and build it from scratch! Luckily you can just type "abort" to escape disaster... but you lose whatever you changed since your last commit.