BGP is not a bug-free protocol.
BGP is the easiest protocol to *debug* when the problem shows up.
BGP does not help to accidently affect *unaffected* paths when
a problem shows up.
While there is a recursion issue in the BGP-IGP scenario, BGP would be
just as broke if the only path between
While there is a recursion issue in the BGP-IGP scenario, BGP would be
just as broke if the only path between two nodes (and whatever nodes are
behind them) had their BGP session removed. Misconfigurations do not imply
bad network designs. Bugs are bugs (whether they be OSPF or ISIS or
problem on unaffected route?
Ask your customers. They do not care if someone else is having a problem.
They care that they dont.
Do you run a decent sized network?
No, I have never touched a router in my life.
Possibly..
Convergence time in the order of
On Tue, 3 Sep 2002 [EMAIL PROTECTED] wrote:
That is why their route is *nailed* via BGP to the router that *always*
provide connectivity to them. If they have to move, BGP injectors are your
friends. Takes seconds.
Talking about things that take seconds: would you mind sharing your BGP
hold
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 10:39 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ATT NYC
On Tue, 3 Sep 2002 [EMAIL PROTECTED] wrote:
That is why their route is *nailed* via BGP to the router that
*always*
provide connectivity to them. If they have
Since when is BGP a bug-free protocol? Let's not forget the BGP best
path selection algorithm itself is broken (there are circumstances under
which it will NEVER converge on a best path see ietf draft on IDR route
oscillation). Not to mention the various malformed AS-Path bugs which
have
On Tue, 3 Sep 2002, Jesper Skriver wrote:
Links and loopbacks = IGP
Why on earth does you want your link addresses in your IGP ?
Sometimes it cannot be avoided, due to bad implementation, but why do
you need it ?
Routers that learn a route over IBGP need to know where the next hop
On Tue, 3 Sep 2002, Frank Scalzo wrote:
Since when is BGP a bug-free protocol? Let's not forget the BGP best
path selection algorithm itself is broken
Actually, the RFC says the route selection algorithm is a local matter, so
if it's broken on your network, then strictly speaking, it's your
On Tue, Sep 03, 2002 at 05:26:54PM +0200, Iljitsch van Beijnum wrote:
On Tue, 3 Sep 2002, Jesper Skriver wrote:
Links and loopbacks = IGP
Why on earth does you want your link addresses in your IGP ?
Sometimes it cannot be avoided, due to bad implementation, but why
do you need it ?
On Tue, Sep 03, 2002 at 10:24:44AM +0100, Stephen J. Wilcox wrote:
Do you run a decent sized network? Convergence time in the order of that
taken by BGP is not acceptable, things go crazy when traffic pours in
and theres no routes to carry it.
Alex ran a decent sized network back when
You keep referring to the problem of OSPF causing the outage
for ATT and unaffected customers. The ATT released RFO simply states
that OSPF network statements were removed. That can happen just as easy
with static routes and BGP network/neighbor statements.
OSPF did what it was instructed to
You keep referring to the problem of OSPF causing the outage
for ATT and unaffected customers. The ATT released RFO simply states
that OSPF network statements were removed. That can happen just as easy
with static routes and BGP network/neighbor statements.
OSPF did what it was
Which is exactly what you are doing when you inject nailed routes into bgp.
So, why do you need IGP such as OSPF again?
Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
1) You should have a static route for every bgp next-hop, on every router?
Including both router loopbacks and EBGP next-hops?
Absolutely not.
2) You should have a static route for every router loopback, on every router?
Asolutely not.
3) You have lots and lots and lots of iBGP sessions
As far as BGP would have done the same thing: would you mind desciring a
configuration of BGP where deletion of a network statement in one router
would cause unreachability across paths that do not *realy* on that network
statement?
Since you have replaced ospf/isis/rip or any other
And that:
you don't use closest-exit at all, but haul traffic, wherever, around
your network based upon steps below the igp-metric step in the bgp decision
tree?
That's the part I can't figure out without some lab time either, but
obviously you can tweak this setup to _statically_ do
On Mon, 2 Sep 2002, Petri Helenius wrote:
Stephen J. Wilcox wrote:
On Mon, 2 Sep 2002, Petri Helenius wrote:
[EMAIL PROTECTED] wrote:
With link-state, one interface flap can mean doing SPF on every route.
Only if you learned every one of your routes from different
Stephen J. Wilcox wrote:
but.. with SPF you need to run the algorithm on all paths for each flap and then
see what that does to your routes
Only the paths that cross the one you lost. Obviously if this happens
or not, depends on your implementation. Look in the documentation under
heading
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument for not using BGP as your IGP.
Alex
iBGP is only one half of an IGP. It is the where to go half.
You still need some other igp (isis, ospf, rip, static routes, etc) for
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument for not using BGP as your IGP.
Convergence time?
What is better - relatively long convergence time
With link-state, one interface flap can mean doing SPF on every route.
Only if you learned every one of your routes from different neighbor.
If you have two exits and 10 routes, you calculate twice and
apply the results to the prefixes.
Note that this does not
Which is exactly what you are doing when you inject nailed routes into bgp.
So, why do you need IGP such as OSPF again?
Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
complex and prone to
Which is exactly what you are doing when you inject nailed routes into bgp.
So, why do you need IGP such as OSPF again?
Alex
To carry the bgp next-hops around the network? You could add in statics
for every next-hop on every router, but this kind of configuration is
complex
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
I would definately not recommend route reflection or a confederation in a
network with such a small number of BGP routers:
In spirit of the above, I suggest you also do not have maintenance window,
forget about re-checking configs, enable to
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
I would definately not recommend route reflection or a confederation in a
network with such a small number of BGP routers:
In spirit of the above, I suggest you also do not have maintenance window,
forget about re-checking configs,
Care Team
-Original Message-
From: Matt Levine [mailto:[EMAIL PROTECTED]]
Sent: Wed 8/28/2002 6:21 PM
To: Mike Tancsa
Cc: Wes Bachman; [EMAIL PROTECTED]
Subject:Re: ATT NYC
On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote:
route
ATT VPNS: 1-888-613-6501
Thank you for using ATT.
Sincerely,
The ATT Customer Care Team
-Original Message-
From: Matt Levine [mailto:[EMAIL PROTECTED]]
Sent: Wed 8/28/2002 6:21 PM
To: Mike Tancsa
Cc: Wes Bachman; [EMAIL PROTECTED]
Subject: Re: ATT NYC
]
Subject: RE: ATT NYC
This is impressive. It's very nice to see a carrier providing this level of
technical analysis to customers after an outage. Many carriers would be
embaressed or try to gloss over what has happened. Sprintlink, in the old
days, was also very good about this. Customers really
On Thu, 29 Aug 2002, NAIDOO Kesva FTLD/IAP wrote:
:
:Has anybody mentioned the benefits of ISIS as an IGP to them.
:
Of course, ISIS is no more resilient against the deletion of igp
configuration than OSPF.
cheers,
brian
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument for not using BGP as your IGP.
Alex
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote:
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument for not using BGP as your IGP.
Slow convergence.
On Thu, 29 Aug 2002, Peter van Dijk wrote:
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote:
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling argument
That's why you configure two. :)
-C
looking a lot better than configuring 4 more BGP sessions. I've heard
some people recommend a route-reflector, but that would mean if the
route-reflector goes down you're screwed.
-Ralph
msg04911/pgp0.pgp
Description: PGP signature
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote:
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really*
break.
I still do not see a compeling argument for not using BGP as your
IGP.
Um. Set up more than one reflector
On Thu, 29 Aug 2002, Ralph Doncaster wrote:
On Thu, 29 Aug 2002, Peter van Dijk wrote:
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote:
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are
Um. Set up more than one reflector
yes... and align your setup with your physical topology(so making it
useful);
use other proto for mapping your infra, etc, etc,..
mh
On Thu, 29 Aug 2002, Ralph Doncaster wrote:
On Thu, 29 Aug 2002, Peter van Dijk wrote:
On Thu, Aug 29, 2002 at
Yup. I like using OSPF to set up the mesh to the loopbacks and then ibgp
as the IGP.
On Thu, 29 Aug 2002, Michael Hallgren wrote:
Um. Set up more than one reflector
yes... and align your setup with your physical topology(so making it
useful);
use other proto for mapping your infra,
.)
Derek
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of
Robert A. Hayden
Sent: Thursday, August 29, 2002 3:53 PM
To: Michael Hallgren
Cc: Ralph Doncaster; Peter van Dijk; [EMAIL PROTECTED]
Subject: RE: ATT NYC
Yup. I like using OSPF to set up
On Thu, 29 Aug 2002, Derek Samford wrote:
I personally prefer using IS-IS for loopback/infrastructure routes, and
I use confederations for my IBGP. If a confederation ever gets to large,
I can always add a route-reflector inside the confederation. Ralph, you
have never failed to amaze me
I wish this was a joke, but I know it's not.
Ralph, they are talking about running BGP as an IGP, not if they are going
to run BGP at all. Most large carriers run BGP everywhere. They also run an
IGP for next-hop reachability within their networks (loopbacks, interface
/30s, etc). The issue was
Ralph, building SCALEABLE
networks, is not.
Derek
-Original Message-
From: Ralph Doncaster [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 29, 2002 4:44 PM
To: Derek Samford
Cc: 'Robert A. Hayden'; 'Michael Hallgren'; 'Peter van Dijk';
[EMAIL PROTECTED]
Subject: RE: ATT NYC
On Thu
Ralph == Ralph Doncaster [EMAIL PROTECTED] writes:
Ralph I think we're both confused now. Your example seems to
Ralph have nothing to do with what I'm talking about. I'm
Ralph currently using an iBGP mesh in my network, with no OSPF or
Ralph IS-IS. In other
PROTECTED]
Subject: RE: ATT NYC
daniel, why would you return to that state?
--
dima.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of
Daniel Golding
Sent: Thursday, August 29, 2002 3:27 PM
To: Ralph Doncaster; Peter van Dijk
Cc: [EMAIL
On Thu, 29 Aug 2002, Peter van Dijk wrote:
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote:
Has anybody mentioned the benefits of ISIS as an IGP to them.
Link-state protocols are evil, and when they break, they *really* break.
I still do not see a compeling
Every time you see one of us mention ISIS or OSPF, all it has to do
with is carrying loopback/infrastructure routes.
I don't think anyone has said to Ralph why the above is done. Just in
case it isn't obvious: you need to make sure the next-hops are known
on each router by a means other than
Bryan,
There is a known ATT outage in Chicago currently. Could this be
effecting you in some way?
-Wes
On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote:
Anyone seeing any problems with ATT in new york?
Best regards,
Bryan Heitman
Interland, Inc.
--
Wes Bachman
System Network
*
Wes Bachman [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
08/28/2002 03:52 PM
To:Bryan Heitman [EMAIL PROTECTED]
cc:[EMAIL PROTECTED]
Subject:Re: ATT NYC
Bryan,
There is a known ATT outage
I am seeing this as well. One of my upstreams (ATT Canada- 15290) has
connections with ATT US (7018) in Chicago and Vancouver. Chicago seems to
have disappeared for me and all traffic bound via that path is going via
Vancouver now.
---Mike
At 02:52 PM 28/08/2002 -0500, Wes
-BEGIN PGP SIGNED MESSAGE-
On Wed, 28 Aug 2002, Matt Buford wrote:
Yep. ATT master ticket 1070909. No details other than agreeing they're
having major problems. They didn't seem to know the scope. I saw our BGP
session stay up but no packets making it through.
Lots of
: [EMAIL PROTECTED]
Subject: Re: ATT NYC
I am seeing this as well. One of my upstreams (ATT Canada- 15290) has
connections with ATT US (7018) in Chicago and Vancouver. Chicago seems to
have disappeared for me and all traffic bound via that path is going via
Vancouver now.
---Mike
At 02
route-server.ip.att.net is not currently reachable, but AS15290's router
server is for those who want a view on things...
route-server.east.attcanada.com.
and
route-server.west.attcanada.com.
which come in handy :-)
---Mike
At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote:
I am
On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote:
route-server.ip.att.net is not currently reachable, but AS15290's
router server is for those who want a view on things...
Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody
else, including AS7018
But to give such a complete trouble report / post mortem and so quickly
after the fact is excellent! I have had outages in the past where the
response has essentially been, Outage, what outage ? I can ping you. There
is no outage here. Nice reporting ATT! Hell, even just admitting there
On Thu, Aug 29, 2002 at 06:42:04AM +0200, Mikael Abrahamsson wrote:
On Wed, 28 Aug 2002, Frank Scalzo wrote:
Whoops! 2 hours to find routers w/o an IGP tsk tsk.
I think it's worth full credit that they actually say what was wrong and
why it took so long to fix it. A lot of other
Massive stupidity shouldn't win you points just because you admit to it
(note that I consider the *massive* stupidity part to start at the
inability to troubleshoot the problem, not the failure in change
management).
I don't think anyone can point to massive stupidity w/o knowing exactly
55 matches
Mail list logo
