Mailing List Archive

Due to a recent misconfiguration in setting up a circuit to a downstream
customer, we ran across an interesting issue where the behaviour of
Cisco and Juniper's BGP implementation seems to be rather different in
how they regard certain configurations.

We support various customer-settable BGP communities for
traffic-engineering in our network. Some of these communities will make
our border-routers prepend our AS-number outbound to certain of our
peers, all the communities in this category are basically just validated
on the import policies on our downstream customer BGP sessions, and the
appropriate actions (prepends) are applied in the export policies on the
upstream or peer BGP sessions on all applicable border routers.

However, as stated, we had a slight misconfiguration on one of our
access routers (the wrong import policy was applied on a customer BGP
session), causing that router to prepend our AS-number itself, as the
routes were received from the downstream, before propagating to iBGP
peers. This led to some interesting results.

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. 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, 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.

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.

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...

/leg

On Sat, Mar 01, 2003 at 12:33:43AM +0100, Lars Erik Gullerud wrote:

[ ... ]

| 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...

lars,

does the following configuration on the receiving router
fix your problem ? [replace 4711 with your AS]

[edit]
hannes@obiwan# show
[ ... ]

routing-options {
autonomous-system 4711 loops 2;
}

[ ... ]
/hannes

> 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

On Sat, 2003-03-01 at 08:54, Danny McPherson wrote:
> > 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.

Well, as I said - I "expected" it because I already know that Cisco
accepts more or less anything when coming from internal peers. And for
us, it would actually have been good if Cisco, like Juniper, did NOT
accept them, as we would have caught this particular misconfiguration
immediately, when none of the affected routes were being propagated
anywhere...

> 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.

Yes, that's how I read it too, and I agree that it would indeed be
better if you had to explicitly configure it if you want to accept such
paths - since it would, like it was for us, in most cases be a sign of a
misconfiguration, and those who need to do this intentionally would have
to explicitly enable it. I doubt Cisco will change their default
behaviour so you would need to configure this though, given their
reluctance to change existing defaults in IOS for anything.

/leg