BGP session going down on "invalid attribute list"

Hello list,

Yesterday we had a BGP session fall away under our feet, and
we don't
completely understand why. We have a Juniper M7i running
JUNOS 7.4.

Logging shows:
Jan  3 16:37:18 juniper rpd[2727]: bgp_read_v4_update:
NOTIFICATION sent
to *.21 (External AS X): code 3 (Update Message Error)
subcode 1 (invalid
attribute list)
Jan  3 16:37:18 juniper rpd[2727]: bgp_event: peer .21
(External AS X) old
state Established event RecvUpdate new state Idle
Jan  3 16:37:26 juniper rpd[2727]: bgp_pp_recv: rejecting
connection from
.21 (External AS X), peer in state Idle

We checked with our peer, and it seems that they received an
advertisement
containing a private AS:

our peer (AS X) <---> peer 1 <---> peer 2
<---> AS65422.

We do filter on private-AS'es using:

    policy-statement filter-private-as {
        from as-path private;
        then reject;
    }

Our Cisco router has a BGP session to the same peer AS (and
must have
received the same invalid attribute). However, the BGP
session did not go
down.

a) Has anybody seen this behaviour before?

b) Does an upgrade of JUNOS resolve the issue of the BGP
session going
down, or is that expected behaviour?

c) Can I apply alternative filtering to make sure routes
with a private AS
in the path are always rejected?

Regards
Rutger



_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, 4 Jan 2007, Rutger Bevaart wrote:
> Yesterday we had a BGP session fall away under our
feet, and we don't
> completely understand why. We have a Juniper M7i
running JUNOS 7.4.
>
> Logging shows:
> Jan  3 16:37:18 juniper rpd[2727]: bgp_read_v4_update:
NOTIFICATION sent
> to *.21 (External AS X): code 3 (Update Message Error)
subcode 1 (invalid
> attribute list)
....
> a) Has anybody seen this behaviour before?

First of all, it's not obvious to me why you believe the
private AS is 
causing the trouble.

As a matter of fact, we saw the same behaviour today
morning, except 
that we _received_ the NOTIFICATION of invalid attribute
list from our 
downstream customer when the full Internet routing table
we're 
advertising to the them (a Cisco router) flapped.  I hear
the Cisco 
router's memory is almost full which I thought might be a
possible 
indication of a memory allocation problem.

We are running 7.5SR.  It's not clear to me whether this was
a bug in 
Cisco or in Juniper.

-- 
Pekka Savola                 "You each name yourselves
king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On 04/01/07, Pekka Savola <pekkasnetcore.fi> wrote:
> As a matter of fact, we saw the same behaviour today
morning, except
> that we _received_ the NOTIFICATION of invalid
attribute list from our
> downstream customer when the full Internet routing
table we're
> advertising to the them (a Cisco router) flapped.  I
hear the Cisco
> router's memory is almost full which I thought might be
a possible
> indication of a memory allocation problem.

I saw a similar problem a couple of weeks ago:
rpd[2760]: %DAEMON-4: bgp_read_v4_update: NOTIFICATION sent
to
my.remote.peer (External AS x): code 3 (Update Message
Error) subcode
11 (AS path attribute problem)

Here the other side is a Cisco also.. unfortunately I got
the usual
'oh we don't know what happened your end must have caused a
bounce'
response when we tried to investigate and it hasn't happened
again.

Ras
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> Yesterday we had a BGP session fall away under our
feet, and we don't
> completely understand why. We have a Juniper M7i
running JUNOS 7.4.
> 
> Logging shows:
> Jan  3 16:37:18 juniper rpd[2727]: bgp_read_v4_update:
NOTIFICATION
sent to *.21 (External AS X): code 3 (Update Message Error)
subcode 1
(invalid attribute list)
> Jan  3 16:37:18 juniper rpd[2727]: bgp_event: peer .21
(External AS X)
old state Established event RecvUpdate new state Idle
> Jan  3 16:37:26 juniper rpd[2727]: bgp_pp_recv:
rejecting connection
from .21 (External AS X), peer in state Idle

Turn on some additional BGP traceoptions to get the actual
packet contents/decode. 

Your router _received_ an UPDATE that it did not like, and
therefore is resetting the session.  The NOTIFICATION that
you are sending will contain at least part of the path 
attributes which it did not like.  If you turn on packet 
decoding, it will show you those attributes. 

The private-AS is not likely to be an issue... 

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> Turn on some additional BGP traceoptions to get the
actual
> packet contents/decode.
>
> Your router _received_ an UPDATE that it did not like,
and
> therefore is resetting the session.  The NOTIFICATION
that you are sending
> will contain at least part of the path attributes which
it did not like.
> If you turn on packet
> decoding, it will show you those attributes.
>
> The private-AS is not likely to be an issue...
>
>

I will add traceoptions, although I'm doubtfull that it will
happen again
in the near future. If it does, we will at least have more
verbose
logging.

Thanks for the replies...

Regards
Rutger


_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

At 01:47 PM 04-01-07 +0100, Rutger Bevaart wrote:
>Hello list,
>
>Yesterday we had a BGP session fall away under our feet,
and we don't
>completely understand why. We have a Juniper M7i running
JUNOS 7.4.
>
>Logging shows:
>Jan  3 16:37:18 juniper rpd[2727]: bgp_read_v4_update:
NOTIFICATION sent
>to *.21 (External AS X): code 3 (Update Message Error)
subcode 1 (invalid
>attribute list)
>Jan  3 16:37:18 juniper rpd[2727]: bgp_event: peer .21
(External AS X) old
>state Established event RecvUpdate new state Idle
>Jan  3 16:37:26 juniper rpd[2727]: bgp_pp_recv:
rejecting connection from
>.21 (External AS X), peer in state Idle
>
>We checked with our peer, and it seems that they
received an advertisement
>containing a private AS:
>
>our peer (AS X) <---> peer 1 <---> peer 2
<---> AS65422.
>
>We do filter on private-AS'es using:
>
>     policy-statement filter-private-as {
>         from as-path private;
>         then reject;
>     }
>
>Our Cisco router has a BGP session to the same peer AS
(and must have
>received the same invalid attribute). However, the BGP
session did not go
>down.
>
>a) Has anybody seen this behaviour before?
>
>b) Does an upgrade of JUNOS resolve the issue of the BGP
session going
>down, or is that expected behaviour?
>
>c) Can I apply alternative filtering to make sure routes
with a private AS
>in the path are always rejected?

Maybe someone sent you a 32bit ASN?

-Hank


>Regards
>Rutger
>
>
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsppuck.nether.net
>
https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>+++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> Maybe someone sent you a 32bit ASN?

Isn't that capability negotiated during the OPEN
messages?

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, January 4, 2007 15:56, Paul Goyette wrote:
>> Maybe someone sent you a 32bit ASN?
>>
>
> Isn't that capability negotiated during the OPEN
> messages?
>


And should that cause a BGP session to drop? Why did 4 AS'es
propagate
this info, yet our Juniper choke on it?

regards
Rutger

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> >> Maybe someone sent you a 32bit ASN?
> >
> > Isn't that capability negotiated during the OPEN
> > messages?
> 
> And should that cause a BGP session to drop? Why did 4
AS'es propagate
> this info, yet our Juniper choke on it?

IF 4-byte ASNs is a negotiated capability,
AND IF we negotiated to NOT PERMIT 4-byte ASNs
AND  the peer sent us a 4-byte ASN anyway, 

THEN YES, this is sufficient reason to drop the session
since the peer has violated the negotiated agreement.

That's sort of the whole point of BGP's capability 
negotiation.

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On 4-jan-2007, at 16:27, Paul Goyette wrote:

IF 4-byte ASNs is a negotiated capability,
AND IF we negotiated to NOT PERMIT 4-byte ASNs
AND  the peer sent us a 4-byte ASN anyway,

THEN YES, this is sufficient reason to drop the session
since the peer has violated the negotiated agreement.

That's sort of the whole point of BGP's capability
negotiation.

Agreed, but AFAIK there are no 32-bit ASN aware software
releases from
Cisco, Foundry or Juniper. As our peer is running on Foundry
RX it seems
unlikely to be the reason. And the 4 AS'es in between
happily passed this
information on without going down.

I will ask the upstream party for some more logging and
details!

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp