anyone else seeing very long AS paths?

Mailman List Mirror (Read Only)
1

I am seeing them from 39625 and 47868.

-Matt

2

I'm seeing it too

Feb 16 16:44:36.065 GMT: BGP: x.x.x.x Bad attributes
Feb 16 16:45:43.389 GMT: %BGP-6-ASPATH: Long AS path 6461 1299 29113 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 received from x.x.x.x: Has more than 255 AS
Feb 16 16:45:43.389 GMT: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP
Notification sent
Feb 16 16:45:43.389 GMT: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 3/11
(invalid or corrupt AS path) 516 bytes 50020200 02FF193D 051371B9 BAFCBAFC
BA
Feb 16 16:45:43.389 GMT: BGP: x.x.x.x Bad attributes

3

I just see it from 47868 and I just filtered it so it would stop blowing
up BGP sessions to customers. In our case we are only seeing the
prefix from level3 which prompted me to create a route map to block it:

ip as-path access-list 500 permit _47868_

route-map as3356-in deny 1
match as-path 500

John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us

4

Hi,

Yep, we see them too. Nasty because there are lots of networks flapping as the long as-paths are tickling old bug CSCdr54230, so even networks not affected by the bug will be getting lots of extra updates.

Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them ?

Andy

5

Sprint has already expunged 47868 from their offerings but Paetec nee
McLeod is still bouncing sessions to us. It is Monday, isn't it?

6

Yep we saw the same, every customer with old IOS had their sessions die
to us at the same time... That always makes for an interesting time
when watching the NMS system...

We are seeing a much more sane path now:

agg2-sea-A>show ip bgp 94.125.216.0/21
BGP routing table entry for 94.125.216.0/21, version 25944571
Paths: (1 available, best #1)
Multipath: eBGP
  Advertised to update-groups:
     2 3 5 6 7 8 9

  3561 3356 29113 47868
    208.76.153.96 (metric 5102) from 208.76.153.96 (208.76.153.96)
      Origin IGP, metric 0, localpref 50, valid, internal, best
      Community: 11404:1000 11404:1040
agg2-sea-A>

John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us

7

Looks good here too

telnet@edge1.chi.ubiquityservers.com(config)#show ip bgp 94.125.216.0/21
Number of BGP Routes matching display condition : 2
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
    Network Next Hop Metric LocPrf Weight Path
*> 94.125.216.0/21 72.37.148.177 3 100 0 25973 29113 47868 i
* 94.125.216.0/21 65.47.180.113 3 100 0 2828 3257 29113 47868 i

Regards,

Jake Mertel
Nobis Technology Group, L.L.C.

Web: http://www.nobistech.net/
Phone: (312) 281-5101 ext. 401
Fax: (808) 356-0417

Mail: 201 West Olive Street
Second Floor, Suite 2B
Bloomington, IL 61701

8

Is there a reason you don't use something like "bgp maxas-limit NN" on your transit sessions?

We saw this too, but it stopped at our transit routers. There was actually another a few days ago.

Feb 13 18:46:07: %BGP-6-ASPATH: Long AS path 4323 1299 12887 12741 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625...

Feb 16 11:24:53: %BGP-6-ASPATH: Long AS path 4323 3257 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868...

9

Hello,

I am in touch with Sloane ( as29113 ) to fix this issue

Tomas Caslavsky

Jon Lewis wrote:

10

bgp maxas-limit has a default value of 75 if you don't include it
explicitly in the config so in this case it wouldn't have made much of a
difference.

L.

11

I am also a bit leery of setting it much lower than the defaults due to
the possibility of filtering something my customers will care about...
I am not sure what the best strategy is but what really bit a couple of
our customers was their old IOSes that tore the sessions down. I note
that most of our customers speaking BGP had no issue just three out of
about 25.

What do people think is a reasonable maximum as-path length to enforce
at ones edge?

John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us

12

Why do you say that? I counted 78 instances of 47868 in this long as-path, and our maxas-limit settings did trigger and reject these.

13

I've been using 75 for years and have never seen it trigger on 'legitimate' routes.

14

Would you want your upstream to set an arbitrary limit on these announcements for you, or should the few wayward souls finally upgrade their code? If your upstream were to set a limit (64, 96, 128, 192, 255) what would you expect that to be and how should it be disclosed?

  my opinion is that if you're going to operate in an active environment (eg: bgp) where messages are constantly being sent, you need to be an active participant in managing your risk. If you're not, perhaps you don't really need BGP since you can't afford the 'operational costs' of managing that asset.

  - Jared

15

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfbgp1.html#wp1254976

Defaults

The default value in Cisco IOS software for the number argument is 75.

16

Hi,

Anyone onlist knows the similar command (bgp maxas-limit NN) on Foundry XMR platform ?

regards,

17

Anyone have an estimate as to when these long announcements began? Seems like the first reports appeared just before noon, UTC-05.

We noticed a significant dip in Internet traffic to AS11579 for a few minutes last night (19:00 UTC-05) which we've been trying to hunt down the cause of. At first glance, the two events seem unrelated. Anyone else see anything similar?

18

It hit my routers at 11:26:40, EST.

Michael

19

Just as a follow-up -- and in case anyone hasn't read these yet:

http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml
http://asert.arbornetworks.com/2009/02/ahh-the-ease-of-introducing-global-r
outing-instability/

- - ferg

20

I encountered it yesterday from AS47868.