Mailing List Archive: nsp: juniper

iBGP routes and prepends - Cisco vs Juniper behaviour

Index | Next | Previous | View Threaded

roque at juniper

Feb 28, 2003, 8:01 PM

Post #1 of 5 (458 views)
Permalink

iBGP routes and prepends - Cisco vs Juniper behaviour

lerik [at] nolink (Lars Erik Gullerud) writes:

> However, the Juniper boxes ignored the routes completely

It discards them when they are received since they are looped...

>
> A quick perusal of the BGP RFC didn't seem to shed any light on which
> behaviour is "correct"

From draft-ietf-idr-bgp4-18.txt:

9. UPDATE Message Handling

An UPDATE message may be received only in the Established state.
When an UPDATE message is received, each field is checked for valid-
ity as specified in Section 6.3.

[...]

The information carried by the AS_PATH attribute is checked for AS
loops. AS loop detection is done by scanning the full AS path (as
specified in the AS_PATH attribute), and checking that the autonomous
system number of the local system does not appear in the AS path. If
the autonomous system number appears in the AS path the route may be
stored in the Adj-RIB-In, but unless the router is configured to
accept routes with its own autonomous system in the AS path, the
route shall not be passed to the BGP Decision Process. Operations of
a router that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.

---

My understanding is that this check is applicable to both e and iBGP
updates.

Pedro.

lerik at nolink

Feb 28, 2003, 6:32 PM

Post #2 of 5 (464 views)
Permalink

iBGP routes and prepends - Cisco vs Juniper behaviour [In reply to]

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

hannes at juniper

Mar 1, 2003, 2:52 AM

Post #3 of 5 (448 views)
Permalink

iBGP routes and prepends - Cisco vs Juniper behaviour [In reply to]

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 [at] obiwa# show
[ ... ]

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

[ ... ]
/hannes

danny at tcb

Mar 1, 2003, 2:53 AM

Post #4 of 5 (453 views)
Permalink

iBGP routes and prepends - Cisco vs Juniper behaviour [In reply to]

> 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

lerik at nolink

Mar 1, 2003, 12:32 PM

Post #5 of 5 (454 views)
Permalink

iBGP routes and prepends - Cisco vs Juniper behaviour [In reply to]

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads