- NANOG - lists.nanog.org

RE: AT&T outage?
by Jonathan M. Slivko 17 Jun '05

17 Jun '05

I should probbably say my equipment on AT&T's IP network - not the core network. -- Jonathan M. Slivko - jonathan(a)slivko.org "Linux: The Choice for the GNU Generation" - http://www.linux.org/ - Don't fear the penguin. .^. /V\ /( )\ ^^-^^ He's here to help. -----Original Message----- From: Matt Taber [mailto:tabes@wmis.net] Sent: Friday, June 17, 2005 1:14 PM To: jonathan(a)slivko.org Subject: Re: AT&T outage? Where in GR did you see that alarm for AT&T? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Matt Taber tabes(a)wmis.net WMIS Internet http://www.wmis.net 616-281-9647 1-888-482-9647 "Accelerate ... It's a Speed Thing" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jonathan M. Slivko wrote: > Hmmmm..... I saw some alarms on equipment on AT&T's IP network in Grand > Rapids, MI a while ago. The alarm only lasted 10-15 minutes though. > > -- > Jonathan M. Slivko - jonathan(a)slivko.org > "Linux: The Choice for the GNU Generation" > - http://www.linux.org/ - > > Don't fear the penguin. > .^. > /V\ > /( )\ > ^^-^^ > He's here to help. > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tom > Sands > Sent: Friday, June 17, 2005 12:57 PM > To: Jim McBurnett > Cc: nanog(a)merit.edu > Subject: Re: AT&T outage? > > > Only issue we've seen is a number of people connecting Cogent to AT&T in > DFW. > > > Jim McBurnett wrote: > > >>Has anyone seen a major issue out of Atlanta with AT&T... >> >>Thanks, >>Jim >> >> >> > >

1 0

AT&T outage?
by Jim McBurnett 17 Jun '05

17 Jun '05

Has anyone seen a major issue out of Atlanta with AT&T... Thanks, Jim

3 2

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's SenderIDAuthentication......?]
by Ben Hubbard 17 Jun '05

17 Jun '05

Michael.Dillon(a)btradianz.com said: > That is something that businesses will pay for. > > But first, ISPs have to put their hands up and take > collective responsibility for Internet email as a service > that has value and not just as some kind of loss leader > for Internet access services. Many large organizations already have already, in a case by case way, set up private mail peering with others they exchange large volumes of mail with. This "trusted traffic" is often able to bypass the expense and delay of the spam-filter farm, making the cost and hassle of a parallel mail infrastructure worthwhile to them, and everyone is happy. There is no reason you can't pick another port, modify one of the many FOSS mail servers out there to do whatever it is you are proposing, and start providing this kind of thing on a more formal basis. Call it an email toll-road. (hmmmmm, would a toll-road be troll free? I might pay for that). If you are able to create a solution that works, and that people will pay for, then you'll be happy. Since it works in parallel, it won't disrupt anyone who doesn't want to play along, so they won't be anymore unhappy than they are now. I don't think what you have been talking about so far will work, and I don't think I'm alone in that. But hey, prove me wrong, and maybe someday I'll be writing a check to you to make sure I get email every day. Best, Ben

2 1

Re: The Cidr Report
by Hank Nussbacher 17 Jun '05

17 Jun '05

I was hoping the report would be cleaned up by now but it hasn't so sorry for the multiple list post. The Bogon section is IMHO, broken. Taking just the 1st line as an example: Prefix Origin AS AS Description Unallocated block 3.0.0.0/8 AS80 GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0 3.0.0.0/8 is allocated, as is AS80. I suspect the algorithm, which determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat broken. There are thousands of lines like that. The bogus AS section also appears to be broken. -Hank

1 0

verisign
by Micah McNelly 16 Jun '05

16 Jun '05

Can someone with verisign operations please contact me offlist. Thanks! -- /m "I bet the human brain is a kludge." - Marvin Minsky

1 0

Best Practice where BGP router is "distance" from client
by Sam Stickland 16 Jun '05

16 Jun '05

Hi, I'm wondering what seen as best practice in this network layout: cisco6500 ==== Network Cloud ==== cisco3550 --- Client The client needs a full BGP feed, which of course the 3550 is unable to provide, but the cisco 6500 can. The network cloud is relatively simple, and is running IP. There's a few options: 1) Create a VLAN all the way back from the client to the cisco 6500, and rely on STP/RSTP to provide redundancy over the cloud 2a) Get the client to form a BGP session with the cisco3550 and announce there network(s) to it. The cisco3550 announces our internal address range to the client. Over the top of the this another BGP (multihop) is setup between the client and the 6500. Layer3 protocols (in this case OSPF) provide redundancy in the cloud. Traffic entering our network for the client will be routed straight to the cisco 3550. Traffic from the client will be backhauled all the way to the cisco 6500 before being sent on it's way. 2b) Same as 2a) but with next-hop-unchanged configured on the cisco6500. This should be that traffic leaving the client will be routed from the cisco3550 to the most appropiate network exit-point. The only problem I can see with this senario is if private loopback addresses are in use on the iBGP sessions. Thoughts? Are there any nasty gotcha's I missed, or pain to be encounted later?

2 1

RE: Document Action: 'BGP Wedgies' to Informational RFC
by Church, Chuck 15 Jun '05

15 Jun '05

Will sharply 'pulling up' the MED on a rear-facing peer clear the wedgie, or make it worse??? Sorry, couldn't resist... Chuck -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Fergie (Paul Ferguson) Sent: Wednesday, June 15, 2005 1:29 PM To: nanog(a)merit.edu Subject: FWD: Document Action: 'BGP Wedgies' to Informational RFC Direct operational relevence, methinks. FYI. - ferg -- The IESG <iesg-secretary(a)ietf.org> wrote: The IESG has approved the following document: - 'BGP Wedgies ' <draft-ietf-grow-bgp-wedgies-03.txt> as an Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-wedgies-03.txt Technical Summary It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Working Group Summary The Grow Working Group came to consensus on this document. Protocol Quality This document was reviewed for the IESG by David Kessens. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Alcatel 7670 RSP
by Pablo's Gmail 15 Jun '05

15 Jun '05

Does anyone have these devices deployed out in their backbone? Looking for a general feel on experience with these boxes as it relates to IP funtionality instead of ATM. Please reply offline. thanks

1 0

Alcatel 7670 as RSP
by Pablo's Gmail 15 Jun '05

15 Jun '05

Does anyone have these devices deployed out in their backbone? Looking for a general feel on experience with these boxes as it relates to IP funtionality instead of ATM. Please reply offline. thanks Pablo

1 0

FWD: Document Action: 'BGP Wedgies' to Informational RFC
by Fergie (Paul Ferguson) 15 Jun '05

15 Jun '05

Direct operational relevence, methinks. FYI. - ferg -- The IESG <iesg-secretary(a)ietf.org> wrote: The IESG has approved the following document: - 'BGP Wedgies ' <draft-ietf-grow-bgp-wedgies-03.txt> as an Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-wedgies-03.txt Technical Summary It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Working Group Summary The Grow Working Group came to consensus on this document. Protocol Quality This document was reviewed for the IESG by David Kessens. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0