On Thursday, May 08, 2014 06:34:14 PM Christopher Morrow
wrote:
> :( that's bad news... config hackery is brittle.
> (but fun)
Don't I know :-)... *sigh*
Mark.
signature.asc
Description: This is a digitally signed message part.
On Thu, May 8, 2014 at 10:51 AM, Mark Tinka wrote:
> On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow
> wrote:
>
>> if only there were some technology that could be used to
>> thwart such things.
>
> It's gotten to a point where a repeat offender has me wound
> up enough to prepend his AS
On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow
wrote:
> if only there were some technology that could be used to
> thwart such things.
It's gotten to a point where a repeat offender has me wound
up enough to prepend his AS into some of my paths.
I wish there was a simpler way to "tur
On Thu, May 8, 2014 at 1:51 AM, Mark Tinka wrote:
> On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein
> wrote:
>
>> Operationally speaking, AS1 should not be leaking routes
>> from one upstream to the other. Bad route policy.
ideally it'd be nice to be valley-free... so to speak.
>> Also,
On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein
wrote:
> Operationally speaking, AS1 should not be leaking routes
> from one upstream to the other. Bad route policy.
> Also, AS3 should not accept routes from AS1 that don't
> belong to it. Customer router filtering would prevent
> this.
Operationally speaking, AS1 should not be leaking routes from one upstream to
the other. Bad route policy. Also, AS3 should not accept routes from AS1 that
don't belong to it. Customer router filtering would prevent this.
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.
> I have one bgp convergence problem which confused me. The problem is as
> follows:
>
> ++
> | AS5 |
> +--+16.1/16 |
> | +-+--+
> ||
> +---+--+ |
> | AS4 | |
> |
On Tue, 06 May 2014 11:58:58 +0800, Song Li said:
> I have one bgp convergence problem which confused me. The problem is as
> follows:
You may want to Google for 'BGP Wedgie'.
https://www.nanog.org/meetings/nanog31/presentations/griffin.pdf
http://www.rfc-base.org/txt/rfc-4264.txt
Once you unde
I suggest you work your way down :-)
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Dennis Hagens
Song Li schreef op 5/6/14 1:42 PM:
Hi Dennis,
I think there are two possible convergence results:
1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it w
Hi Dennis,
I think there are two possible convergence results:
1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it will withdraw
announce of 16.1/16(5) towards AS1. And AS1 will remain 16.1/16 (2 4 5).
2/ AS1 accepted route 16.1/16(3 5) from AS3, then it withdraw 16.1/16(2
4 5), and AS3 w
Hi Song Li,
As far as I know there are 2 mechanisms that should prevent this
situation you describe from happening:
- Not advertising routes that are not in the RIB
Once AS1's peering with AS3 comes back up, the route through AS3 is
learned and preferred. Therefore the route via AS2 is purged
* globic...@gmail.com (Andy B.) [Tue 08 Jun 2010, 16:28 CEST]:
I finally decided to shut down all peerings and brought them back
one by one.
Sadly that's often the way it has to be done, modulo mild tweaks.
Everything is stable again, but I don't like the way I had to deal
with it since it w
> The Cisco 7600 and 6500 platforms are getting fairly old and have
> underpowered cpus these days.
the hamsters in them were never well fed, ever. though i have never run
one, too yucchhy, i have measured receiving a research feed from one.
over ten minutes for a full table while a router takes
On Tue, Jun 08, 2010 at 12:22:04PM -0400, Jared Mauch wrote:
>
> The Cisco 7600 and 6500 platforms are getting fairly old and have
> underpowered cpus these days.
>
> Starting in SXH the control plane did not scale quite as well as in
> SXF. This got better in SXI, but is not back on par with SX
Hi Andy,
We have had similar problems with s720/3bxl on exchanges with large
numbers of peers. Exact same symptoms, can be triggered by any
significant UPDATE flux, even iBGP originated path-hunts. This problem
is compounded if you are taking full tables on the same device, to the
extent that th
On Tue, Jun 8, 2010 at 7:27 AM, Andy B. wrote:
> I finally decided to shut down all peerings and brought them back one by one.
>
> Everything is stable again, but I don't like the way I had to deal
> with it since it will most likely happen again when DECIX or an other
> IX we're at is having issu
On Jun 8, 2010, at 10:27 AM, Andy B. wrote:
> I finally decided to shut down all peerings and brought them back one by one.
>
> Everything is stable again, but I don't like the way I had to deal
> with it since it will most likely happen again when DECIX or an other
> IX we're at is having issue
I finally decided to shut down all peerings and brought them back one by one.
Everything is stable again, but I don't like the way I had to deal
with it since it will most likely happen again when DECIX or an other
IX we're at is having issues.
I've seen a few BGP convergence discussions on NANOG
Dear Andy
This morning there was an ethernet loop problem on DECIX, causing many
BGP sessions to flap throughout the entire platform.
While this can happen, I am myself facing with BGP convergence
problems on our DECIX router (SUP720-3BXL with IOS SXI3).
De DECIX loop has been solved two hours
19 matches
Mail list logo
