[j-nsp] iBGP routes and prepends - Cisco vs Juniper behaviour
danny at tcb.net
Sat Mar 1 00:54:15 EST 2003
> 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
> 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
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
More information about the juniper-nsp