I am starting to see random BGP neighbor messages from multiple neighbors on
different boxes.
%BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt
AS path) 516 bytes
I dont see much documentation on this, and we are in the process of opening
a TAC case, just curious if
I am seeing them from 39625 and 47868.
-Matt
I am starting to see random BGP neighbor messages from multiple neighbors on
different boxes.
%BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt
AS path) 516 bytes
Maybe because of this?
94.125.216.0/21*[BGP/170] 00:31:49, MED 22367, localpref 100
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
Hi all,
We're seeing some garbage being thrown into the global BGP table by AS 47868.
%BGP-6-ASPATH: Long AS path 3549 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
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
We're seeing them from AS 48438, coming across to us as an Optional
Transitive Attribute which our force-10s are not parsing (but cheerfully
passing along to our clients, who are then flapping their peers because
of it.) Sample route; 91.210.248.0/23
Ozar wrote:
I am starting to see random
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
Sprint has already expunged 47868 from their offerings but Paetec nee
McLeod is still bouncing sessions to us. It is Monday, isn't it?
On Mon, Feb 16, 2009 at 11:10 AM, Andy Davidson a...@nosignal.org wrote:
Hi,
Yep, we see them too. Nasty because there are lots of networks flapping as
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-Ashow ip bgp 94.125.216.0/21
BGP routing table entry for
Looks good here too
tel...@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
NetworkNext
On Mon, 16 Feb 2009, John van Oppen wrote:
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...
Is there a reason you don't use something like bgp maxas-limit NN on
your
We didn't but see significant routing problem here in Prague/EU.
Michal Krsek - AS41711
John Martinez napsal(a):
Has anyone opened a ticket with Cogent?
Their packet loss is reaching ~10%.
http://www.internetpulse.net
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.
On Mon, 16 Feb 2009, Jon Lewis wrote:
On Mon, 16 Feb 2009, John van Oppen wrote:
Yep we saw the same, every customer with old IOS had
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.
On Mon, 16 Feb 2009, Leland E. Vandervort wrote:
bgp maxas-limit has a default value of 75 if you don't include it
explicitly in the config so in this case
On Mon, 16 Feb 2009, John van Oppen wrote:
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
On Feb 16, 2009, at 12:57 PM, John van Oppen wrote:
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
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.
On Mon, 16 Feb 2009, Jon Lewis wrote:
Why do you say that? I counted 78 instances of 47868 in this long
as-path, and
Hi,
Anyone onlist knows the similar command (bgp maxas-limit NN) on Foundry XMR
platform ?
regards,
---
Nuno Vieira
nfsi telecom, lda.
nuno.vie...@nfsi.pt
Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301
http://www.nfsi.pt/
- Jon Lewis jle...@lewis.org wrote:
On Mon, 16 Feb 2009, John
Hello John ,
On Sun, 15 Feb 2009, John A. Kilpatrick wrote:
Has anyone had problems with using current Intel quad ethernet cards for
packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and
hooked it up to some Network Critical taps. There was a very strange issue
Loss between AS22663 and various European sites was running 50% for us
around 10:00 GMT. We dropped Paetec peering, which got Cogent out from
between us and the sites in question, then things were fine via Sprint. Our
usage at the time was maybe 5 mbits on a DS3.
On Mon, Feb 16, 2009 at 11:46
On Sun, Feb 15, 2009 at 11:48 PM, John Martinez jmarti...@zero11.com wrote:
Has anyone opened a ticket with Cogent?
Their packet loss is reaching ~10%.
We see strange losses to/from their network.
Losses to some hosts while other hosts on the same network route do
not experience losses.
Seems
I had big problems ~ 11:30 AM EST in Vienna, Virginia, but they are
fixed now.
Marshall
On Feb 16, 2009, at 12:46 PM, Michal Krsek wrote:
We didn't but see significant routing problem here in Prague/EU.
Michal Krsek - AS41711
John Martinez napsal(a):
Has anyone opened a ticket
Yea cards are default for separate physicals MACs, since they are
supported by individual net chips. The only time one would see a
logical Mac, is when the ports are trunked, and this is driven by
software.
Jay Murphy
IP Network Specialist
NM Department of Health
ITSD - IP Network Operations
One more note it is a bridging chip, not switching, that is resident
on the board that is the communicator to the other NIC chipsets.
Jay Murphy
IP Network Specialist
NM Department of Health
ITSD - IP Network Operations
Santa Fe, New Mexico 87502
Bus. Ph.: 505.827.2851
We move the
On Mon, Feb 16, 2009 at 12:35 AM, John A. Kilpatrick j...@hypergeek.net wrote:
Has anyone had problems with using current Intel quad ethernet cards for
packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT
and hooked it up to some Network Critical taps. There was a very
Hello,
We have been assigned 66.249.96.0/20 in April of 2008. Little did we
know that this network was used by a spammer in 2004 (Lightwave
Transit) and with this is deeply
embedded in a lot of ACL's that seem to be unmaintained.
If a GLBX engineer could take a look, it seems traffic
Jens Ott - PlusServer AG wrote:
Therefore I had the following idea: Why not taking one of my old routers and
set it up as blackhole-service. Then everyone who is interested could set up a
session to there and
I do something similar on our network with a RTBH trigger router. I
peer with it
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
It hit my routers at 11:26:40, EST.
Michael
On Monday 16 February 2009 07:26:23 pm Adam Greene wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Shadowserver Foundation is pleased to announce the formal rollout of
our ASN/netblock alerting and reporting service.
This reporting service is provided free-of-charge and is designed for
ISPs, enterprises, hosting providers, and other
Announcing GCTIP - New Forums for Internet Transparency,
Performance, and ISP Issues
http://lauren.vortex.com/archive/000506.html
Greetings. I'm pleased to announce the availability of a new venue
for discussion, reporting, analysis,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 16, 2009 at 8:51 PM, Michael Ulitskiy mulits...@acedsl.com
wrote:
It hit my routers at 11:26:40, EST.
Michael
On Monday 16 February 2009 07:26:23 pm Adam Greene wrote:
Anyone have an estimate as to when these long announcements
I encountered it yesterday from AS47868.
-Original Message-
From: Paul Ferguson [mailto:fergdawgs...@gmail.com]
Sent: Tuesday, February 17, 2009 01:02 PM
To: nanog@nanog.org
Subject: Re: anyone else seeing very long AS paths?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb
Hello,
On Sun, Feb 15, 2009 at 09:35:30PM -0800, John A. Kilpatrick wrote:
Has anyone had problems with using current Intel quad ethernet cards for
packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT
and hooked it up to some Network Critical taps. There was a very
On Mon, 16 Feb 2009, Jon Lewis wrote:
Is there a reason you don't use something like bgp maxas-limit NN on your
transit sessions?
I've been using maxas=50 for years now (see the 2005 thread:
http://www.atm.tut.fi/list-archive/nanog-2005/msg04753.html)
I also knew this would happen one day and
36 matches
Mail list logo
