[j-nsp] iBGP routes and prepends - Cisco vs Juniper behaviour

[Danny McPherson]

> The Cisco boxes in our network gladly accepted these routes containing
> our own AS-number prepended, and propagated them correctly to their
> external peers, with the AS-path prepend in place. This is the behaviour
> I expected, having worked with this type of setup before, when it was
> done intentionally. 

I'm not sure this is what I would have expected.  I'm actually surprised
they didn't discard it.  

> However, the Juniper boxes ignored the routes
> completely, i.e. I could not see them using "show route receive-protocol
> bgp x.x.x.x" or in any other way,

Having just become familiar with how Juniper handles this :-), had 
'keep all' been configured even the looping AS_PATH routes would have 
been retained.

> however a quick trace showed that the
> Junipers received the correct number of prefixes in the update message
> from the iBGP peer in question. Unless this is some oddity that results
> from something in our config (or our JunOS version - all boxes in
> question are on 5.4R2.4) only, I am assuming that this is due to the
> fact that the Juniper boxes do the same type of loop-prevention on
> routes from iBGP peers as routes from eBGP peers, i.e. drop routes
> containing our own AS-number in the AS-path.
> 
> If that is the case, it is a rather interesting difference in behaviour.
> The fact that the Cisco boxes and the Juniper boxes acted differently
> made me curious, as this caused the engineers who were troubleshooting
> this some extra head-scratching time before identifying the
> misconfiguration. And also because I've previously been working in some
> Cisco-only shops which actually do this type of behaviour under "normal"
> circumstances, i.e. they prepend certain routes as they are received,
> before propagating to iBGP peers, and these networks would obviously
> have some fun if they should decide to place some Junipers in their
> core.

As a matter of policy, prepending the local AS number on ingress seems 
like a bad idea to me, regardless of whether it works or not. 

> A quick perusal of the BGP RFC didn't seem to shed any light on which
> behaviour is "correct", as far as the RFC is concerned I guess the real
> incorrect behaviour is on the part of the injecting router, since the
> RFC states that you should not modify the routes before passing them to
> an internal peer.

The current rev of the spec (the one Pedro cited, -18) says SHALL NOT, 
which is not a MUST NOT (in IETF speak *8-/):

      a) When a given BGP speaker advertises the route to an internal
      peer, the advertising speaker shall not modify the AS_PATH
      attribute associated with the route.


> Any comments on which behaviour is the "correct" one? Anyone else
> noticed this behaviour, or is it in fact something just happening for
> us? It's not really an issue, since this was a misconfiguration (and the
> responsible engineer has gotten his fingers thorougly slapped), but as I
> said, I know certain networks who use setups like this intentionally,
> and they might be in for a surprise if they ever wise up and get some
> Junipers in their networks if this really is the case, so I'd just like
> to know if this is intentional or not...

I agree with Pedro that the check should be performed on iBGP peers as well, 
and that looping paths should be ignored, unless explicitly configured
otherwise.

-danny