On Thu, May 8, 2014 at 1:51 AM, Mark Tinka mark.ti...@seacom.mu 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
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 turn
On Thu, May 8, 2014 at 10:51 AM, Mark Tinka mark.ti...@seacom.mu 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
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.
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
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.
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
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
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
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
I have one bgp convergence problem which confused me. The problem is as
follows:
++
| AS5 |
+--+16.1/16 |
| +-+--+
||
+---+--+ |
| AS4 | |
| |
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
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
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 issues.
On Tue, Jun 8, 2010 at 7:27 AM, Andy B. globic...@gmail.com 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
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 SXF
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
* 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
18 matches
Mail list logo
