- Test - lists.nanog.org

Re: attacking DDOS using BGP communities?
by Saku Ytti 18 Oct '02

18 Oct '02

On (2002-10-18 00:15 -0400), John Fraizer wrote: > > 2) 'TTL' community. > > > > -just think about the amount of route-maps :> > > Whoa. Decrementing a single community integer value while leaving others > unchanged would seem to be a bit tricky. This would require much more > work on the part of others than the first suggestion and I think it would > attract far fewer participants for that matter. Actually would it matter if it wouldn't be additive change? Since it would be diagnostic/special case. But of course it would be trivial for the vendors to add support for changing the communities this way, if this could be performed as a additive change you could offer your customers automaticly partial visiblity under DOS attack until it's resolved rather than 0 visibility. Not to mention how much it would ease pinpointing faulty/aggressive parties thus in long run it could have very positive effect for things like proper anti-spoofing configurations. -- ++ytti

1 0

vrf resources?
by Scott Call 17 Oct '02

17 Oct '02

Hello all. I was recently handed a piece of a network that used VRF to implement vlans. I'm by no means a vrf expert, but the config looks right to me. The problem I'm having is that traffic destined for IP addresses within the VRF Vlan from interfaces not within the VRF vlan (they don't have "ip vrf forwarding" statements in their interface configurations) which of course breaks the whole concept of a private routing table. I've done extensive searching of Cisco's website and have found no mention of this problem, or it's avoidance when setting up a vrf vlan. Lacking a valid service contract, I cannot open a ticket, so any insight is greatly apreciated. Thanks -Scott

1 1

RE: question concerning traceroute?
by Kris Foster 17 Oct '02

17 Oct '02

> a traceroute shows the outbound route. it's possible for the the probe > packets to follow one path and the returning icmp packets to take another > path. a looking glass in the AS your tracing to is a good way to see what > the return path is... The returning ICMP packets may take many different paths back to the sender of the UDPs, since each hop will make it's own decision on how to return to the source (not just the single asymmetric path from the destination of the UDPs). Kris

1 0

RE: Global Internetworking/Switch and Data
by Bob Collie 17 Oct '02

17 Oct '02

Let me clarify now that I've done a bit more homework...they have not merged with Switch and Data from my investigations of Switch and Data, they just appear to be a business channel partner with Switch and Data. -----Original Message----- From: Bob Collie Sent: Thursday, October 17, 2002 3:03 AM To: nanog(a)nanog.org Subject: Global Internetworking/Switch and Data Is anyone familiar with this company (http://www.globalinternetworking.com) and had any experience with them? They recently merged with Switch and Data (an Equinix-like company) out of Florida. Any intelligence would be helpful. Thanks. -- Bob Collie Education Networks of America p: 615-312-6004 f: 240-358-8872 e: bob(a)ena.com

1 0

Global Internetworking/Switch and Data
by Bob Collie 17 Oct '02

17 Oct '02

Is anyone familiar with this company (http://www.globalinternetworking.com) and had any experience with them? They recently merged with Switch and Data (an Equinix-like company) out of Florida. Any intelligence would be helpful. Thanks. -- Bob Collie Education Networks of America p: 615-312-6004 f: 240-358-8872 e: bob(a)ena.com

1 0

Re: sprint passes uu?
by smd＠clock.org 16 Oct '02

16 Oct '02

Valdis writes: | About the only conclusion that you can *safely* draw is that Sprint has a | more complicated network than UU does. This runs contrary to many years of architecture and design philosophy, and indeed to deployment history based upon that. Obviously we could have very different ideas about what is complicated and what is not, or a misunderstanding about what you think is complicated in our network. However, Sprint has been de-complicating its IP network for many years, ripping out channel banks in the transition to full T1s, ripping out a layer of PDH MUXes in the T1->T3 upgrade cycle, ripping out PDH altogether while *not* adopting ATM in the deployment of POS, and then ultimately ripping out reliance upon the SONET layer in the upgrade to "POS over virtual back-to-back fibre" at 2.5 and 10Gbps. This has eliminated not just equipment and protocols, but also all the processes involved in provisioning and maintaining them. I call that de-complication. Sprint has also carefully layed out its virtual L1 topology to completely avoid the need to roll out MPLS (a complicated forwarding paradigm, with an even more complicated control plane) in order to move traffic cost-effectively and with on average zero congestion. In short, Sprint's approach contrasts with other networks' approach by requiring alot of extremely clever thinking well in advance of deploying, including preparing fallbacks in case something is predicted incorrectly. Alot of that thinking goes into long-term minimization of the need to steer the network once it is deployed. I think this is less complicated than a network which requires a VC-or-ER-based L2 that requires rearranging as traffic grows between step-change buildouts. | Now *hopefully*, they have more customers too We would be happy to add you to the list of customers, especially if you were to connect in Europe. -:) | or the Sprint backbone engineers will have to carry a much higher | complexity/customer ratio, which means when the senior engineers | finally snap under the pressure, we'll get junior engineers making | weird work-arounds that will just complicate things 5 years down | the road. This also runs contrary to many years of history. Having [sb]een a number of generations of Sprintlink engineers over the years, I think the most troublesome complexity/customer issue has involved the interconnect between Sprint's access routers and Sprint's customers. As this is universal -- perhaps excepting some networks operated by LECs -- and is tied up on matters involving OSI Layers 8 and 9, it is astonishing that you have this view while Sprintlink has notably not suffered from weird workarounds done bye junior engineers since about the time that I was one. | Oh wait.. that already happened at most carriers, didn't it? That's where we | got the CURRENT crop of senior engineers.. ;) Well, you could be right, leaving Sprint as an unusal case, since as with its world-beating pro-simplification architecture, Sprint has enjoyed a world-class team almost without interruption since the early 1990s. Sean. (smd(a)sprint.net, again, incidentally...) - -- Sean Doran <smd(a)clock.org> (home & target of NANOG and spam) <smd(a)sprint.net> (Sprint, 1 Pall Mall East, London SW1Y 5AU, UK)

1 0

Has it really been 4 years?
by Patrick W. Gilmore 16 Oct '02

16 Oct '02

October 16, 1998, Jon Postel, "Grandfather of the Internet," passed away. It certainly does not seem like 4 years ago. -- TTFN, patrick

1 0

RE: sprint passes uu?
by Shawn Solomon 16 Oct '02

16 Oct '02

I'm curious to know how many of those UU customers are just waiting for their contracts to expire before giving them the big F.U. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Tuesday, October 15, 2002 7:09 PM To: jlewis(a)lewis.org Cc: Brian; nanog(a)merit.edu Subject: Re: sprint passes uu? On Tue, Oct 15, 2002 at 07:25:15PM -0400, jlewis(a)lewis.org wrote: > > It's hard to know how large a percentage though without knowing how many > Sprint customers are also UU customers. i.e. The combination of Sprint > and UU customer routes could still be just 47637 prefixes, though I'm sure > it's somewhere between that and 47637+45410. It's certainly not > 47637+45410, which would falsely suggest that together Sprint and UU have > roughly 80% of the internet as customers. Well, just by checking the "big" providers off the top of my head, I come up with: ASN Routes Common Name ---- ------ ----------- 1239 47711 Sprint 701 45429 UU 3561 23205 CW 7018 23154 AT&T 1 20231 BBN/Genuity 209 17082 Qwest 3356 12587 Level 3 3549 12175 GBLX 6453 10403 Teleglobe 2914 8791 Verio 6461 8089 MFN/AboveNet 4200 7506 Aleron/Agis 1299 6773 Telia 5511 4261 OpenTransit 4637 4066 Reach 16631 2067 Cogent 2828 1842 XO 4006 1727 NetRail/Cogent ----- 256984 Which of course ignores many dozens of 1-2k route providers. Now, of course number of routes has absolutily nothing to do with amount of traffic (ex: AOL, which anounces 400 some routes (and a lot of those are RoadRunner) but is one of if not the single the most important sink of traffic in the world), but it's interesting nevertheless. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3

Transit prices
by up＠3.am 16 Oct '02

16 Oct '02

>From down here (the low end of the transit market), it looks like the bottom of the transit market is already past. Sprint just raised their prices by 8% for T1 and T3s, much more for DS0s. ATT raised their prices for ATM and FR service, but that's really loop only (they say it "includes port charges", but it isn't IP port). The Sprint prices are for combined port/loop service. James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

1 0

RE: C&W Move
by Charles Youse 16 Oct '02

16 Oct '02

What game is this? I have some gear at SJC1 and I've not heard anything. C. -----Original Message----- From: David Schwartz [mailto:davids@webmaster.com] Sent: Wednesday, October 16, 2002 2:02 PM To: moe(a)vidnet.net; Nanog Subject: Re: C&W Move On Wed, 16 Oct 2002 12:23:20 -0500, Moe Allen wrote: >We are in that C&W group and C&W is telling us we have to sign the contract >by Friday the 18th. We were only notified Last Friday. I get concerned >when things happen this quick without a lot of backup information. >thanks >Morris Allen >VidcomNet, Inc. Sounds similar to the game AboveNet is playing with all their SJC1 customers. DS

3 2