- NANOG - lists.nanog.org

An article from the Miami Herald about the Florida MIX
by Martin J. Levy 15 Sep '02

15 Sep '02

Hello all, I apologize for the operational nature of the email, but I interrupt the regular threads to post something to do with peering points. This is from the Miami Herald. What's strange about this is... It's an example of peering converting to transit, or in this case a peering point converting into a transit network. The two are so different that I can't see the connection. Martin ----------------- There are two articles. They are close copies of each together. http://www.miami.com/mld/miami/news/4070039.htm http://www.miami.com/mld/miami/business/4070691.htm >Posted on Fri, Sep. 13, 2002 > >BellSouth changes strategy of South Florida Internet network >BY BEATRICE E. GARCIA >bgarcia(a)herald.com > >BellSouth is changing the character and the mission of its South Florida Internet network. > >BellSouth's Florida Multimedia Internet Exchange (MIX) won't be billed as a major Internet access point. But the Internet network will expand outside South Florida and eventually move into the nine-state region serviced by BellSouth in order to capitalize on its newly gained entry into the long-distance market. > >BellSouth set up its Florida MIX last summer as a major Internet network access point, or NAP, where Internet traffic changes hands, with four connection points: downtown Miami, West Miami-Dade, Fort Lauderdale and Boca Raton. > >It was meant to compete with the NAP of the Americas, built in downtown Miami by Terremark Worldwide. > >However, sources say the Florida MIX never attracted many customers interested in exchanging Internet traffic between major networks. But it did sign carriers and business customers who used the network to transport Internet traffic within South Florida. > >Now that the Atlanta-based company has gained approval to offer long-distance service in Georgia and Louisiana and its application for Florida is pending before federal regulators, the company is setting the groundwork to take its data network services beyond state lines. Long-haul transport is a lucrative service. > >David Sutton, a company spokesman, said ''BellSouth is creating a next-generation Internet backbone,'' which is a system of networks and servers used to move Internet traffic long-distance. > >BellSouth is calling its new design the BellSouth Regional IP Backbone (BRIB). > >The BRIB will feature three central points of presence in Atlanta, Miami and New Orleans. > >Sutton said BellSouth will release more information about the BRIB within the next few weeks. >

1 0

Sprint BGP customer policy
by jlewis＠lewis.org 15 Sep '02

15 Sep '02

I've been trying to make use of these 6500N:XXX community strings on a Sprint BGP session with no results. After dealing with 3 different Sprint IP engineers, I'm convinced none of them understands the following info from the Sprint web site. I'd like to hear from a Sprint routing engineer who can either help me get this working or tell me it's no longer supported. All responses from bgp4-adm(a)sprint.net and phone calls to the Sprint IP NOC have been comical at best and demonstrated a complete lack of understanding of route-maps and communities at worst. I won't embarrass them by including any of their responses. If you're a Sprint customer utilizing these communities, I wouldn't mind hearing from you as well, especially if you know what hoop has to be jumped through to get Sprint to accept and act on these communities. [from http://www.sprint.net/policy/bgp.html] AS-PATH PREPENDS Sprint allows customers to use AS-path prepending to adjust route preference on the network. Such prepending will be received and passed on properly without notifiying Sprint of your change in announcments. Additionally, Sprint will prepend AS1239 to eBGP sessions with certain autonomous systems depending on a received community. String Resulting AS Path to ASXXX 65000:XXX Do not advertise to ASXXX 65001:XXX 1239 (default) ... 65002:XXX 1239 1239 ... 65003:XXX 1239 1239 1239 ... 65004:XXX 1239 1239 1239 1239 ... This is my second attempt to send this message. Majordomo seems to have either eaten my first message or bounced it to the moderator(s). ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

3 2

RE: BGP Default Route
by Lupi, Guy 14 Sep '02

14 Sep '02

Assume I am originating default for customers that only want a default route, or a default route and some portion of the full Internet routing table. You're right, if I am the only gateway then it really doesn't matter. Obviously if there is more than one provider it would be better for the customer to accept full routes, but there are some customers out there that have 2 providers and don't want to assume the cost of purchasing a router that can accept 2 providers feeding it full tables (why you would assume the cost of 2 providers and not a reasonably priced router that can handle it I don't know, but I have run into it before). I am really just curious as to how people implement this and their reasoning for selecting a particluar method. Is your method the one you stated before, default origination from the router that is directly connected to the customer? -----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Saturday, September 14, 2002 4:48 PM To: Lupi, Guy Cc: 'nanog(a)merit.edu' Subject: RE: BGP Default Route The answer is you can do it all sorts of ways. Why are you originating default? If you are originating default because you are the only gateway for a customer, whatever partial connectivity your router has is better than effectively turning them off if you have a network partition. If your customer has more than one upstream they really should take full views so they have the ability to make routing decisions based on that information. This fixes your concern and is the best engineering choice. A hack would be to conditionally announce default based on the presence of some specific other route. This would be doing additional work to implement a suboptimal solution which a simpler use of BGP (full views) fixes automatically. Yes, as much as you can, your routers should be meshed with more than one connection each. Mike. On Sat, 14 Sep 2002, Lupi, Guy wrote: > I see what you are saying, and I understand that the default route would be > originated per neighbor, or per peer group for all neighbors within that > peer group. My biggest concern is that if the aggregation router with this > configuration was to lose connectivity back to the routers which provide it > with external routing information, it would still announce the default to > that neighbor. Do you feel that this is an acceptable risk, taking into > consideration that the aggregation router has redundant connectivity to > those routers that provide it with it's external routing information and it > is highly unlikely that the router would lose it's view of the world? > > > -----Original Message----- > From: Mike Leber [mailto:mleber@he.net] > Sent: Saturday, September 14, 2002 4:19 PM > To: Lupi, Guy > Cc: 'nanog(a)merit.edu' > Subject: Re: BGP Default Route > > > > On Sat, 14 Sep 2002, Lupi, Guy wrote: > > I was wondering how people tend to generate default routes to customers > > running bgp. > > Typically you would only originate default via BGP to a customer that > isn't taking a full view. > > neighbor 10.10.10.2 default-originate > neighbor 10.10.10.2 filter-list 9 out > > ip as-path access-list 9 deny ^.*$ > > > Is it from the aggregation router that customers are directly > > connected to, or from one or more core/border routers? > > In the example above the default originate is done via a specific BGP > session, so it isn't router wide on either core or border routers. > > > If one is using a default route to null 0... > > I'll leave the rest of this for somebody else to answer. > > Mike. > > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ > | Mike Leber Direct Internet Connections Voice 510 580 4100 | > | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | > | mleber(a)he.net http://www.he.net | > +-----------------------------------------------------------------------+ > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +-----------------------------------------------------------------------+

3 2

RE: BGP Default Route
by Lupi, Guy 14 Sep '02

14 Sep '02

I see what you are saying, and I understand that the default route would be originated per neighbor, or per peer group for all neighbors within that peer group. My biggest concern is that if the aggregation router with this configuration was to lose connectivity back to the routers which provide it with external routing information, it would still announce the default to that neighbor. Do you feel that this is an acceptable risk, taking into consideration that the aggregation router has redundant connectivity to those routers that provide it with it's external routing information and it is highly unlikely that the router would lose it's view of the world? -----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Saturday, September 14, 2002 4:19 PM To: Lupi, Guy Cc: 'nanog(a)merit.edu' Subject: Re: BGP Default Route On Sat, 14 Sep 2002, Lupi, Guy wrote: > I was wondering how people tend to generate default routes to customers > running bgp. Typically you would only originate default via BGP to a customer that isn't taking a full view. neighbor 10.10.10.2 default-originate neighbor 10.10.10.2 filter-list 9 out ip as-path access-list 9 deny ^.*$ > Is it from the aggregation router that customers are directly > connected to, or from one or more core/border routers? In the example above the default originate is done via a specific BGP session, so it isn't router wide on either core or border routers. > If one is using a default route to null 0... I'll leave the rest of this for somebody else to answer. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +-----------------------------------------------------------------------+

3 2

Pre-NANOG 26 Oregon Rafting Adventure
by Daniel Golding 14 Sep '02

14 Sep '02

Hello! We would like to announce the Pre-NANOG 26 Oregon Rafting Adventure. When: October 26th, the day before NANOG 26 starts. Where: The Upper Mckenzie River, www.hcexpeditions.com What about a Hotel: Many of us are staying the nights before and after at Holiday Farm Resort (Preferred due to the large number of rooms and availability) 800-823-3715 http://www.holidayfarmresort.com/, then caravanning to Eugene on Sunday morning. There are additional places to stay in the immediate area - we'll send you full information when you RSVP. Please plan on making your room reservations as early as possible as many of these are filling up due to various golfing promotions. How Far: About 50 miles from Eugene Where should I fly into: PDX Airport - Portland. This should be less expensive than trying to fly into Eugene. Who is running this?: This trip is being coordinated by Mitchell Rose and Daniel Golding. Ren Nowlin ordinarily runs these things, but she's in China, so we have been left in charge. Fear it. :) Who can come: Anyone who wants to. This trip is not being sponsored by vendors or employers. The trip: we will pass most of the possible hotel accommodations on our raft trip. All of the places are within a 10 mile radius of where we will meet (begin and end) on Sat. for rafting (Belknap Resort). The stretch of river will range from a slow float to class 2-3. We will go through protected forest and secluded areas, past large log jams (this is Oregon, lots of timber). We will have a nice BBQ on the river for lunch and end with a grand raft surfing finale! We will then head to Belknap to soak in an outdoor 104 degree hot spring next to the river. This should be a VERY memorable trip. What to bring: a change of cloths for after the trip (you might get wet ;)), and preferably non-cotton cloths for wearing under the splash gear on the trip. All other clothing and gear will be provided. Check the web site for more details. What's included: All day rafting, lunch, and use of the Hot Spring at the Belknap Resort. How Much: $75 for the raft trip, but there may be discounts if we can get enough folks. How do I sign up?: Three simple steps - Send email to Mitchell Rose (mrose(a)cw.net) or Dan Golding (dgolding(a)yahoo.com) We'll get back to you with more detailed information on the trip and area hotels, and answer any questions you might have. At the same time, you should register for the raft trip at http://www.highcountryexpeditions.com/ under Cost/Booking. Please include "NANOG" as the group name, your Shoe size (M/W), Splash top size (Sm, Med, Large, XL, XL2), and any special needs - vegan, vegetarian, food allergies, etc. The cutoff date for this adventure is 9/30/02. After that, it's purely "space available". Finally, book the hotel room of your choice - we'll send you a full list, but Holiday Farm Resort is recommended. Transportation: None, but we can all carpool there and back. Please let us know if you need or want a ride, or can provide one. Is fun guaranteed?: Yes. Thanks, Daniel Golding and Mitchell Rose

1 0

Re: Security focus (aka bugtraq) reachability
by Scott Gifford 14 Sep '02

14 Sep '02

Mike Tancsa <mike(a)sentex.net> writes: > Can anyone with a host in the IP range of 64.0.0.0/8 confirm if they > can connect to the www.securityfocus.com or mail.securityfocus.com ? > (i.e. the bugtraq people). I can reach it, but it's not working, and this is sure strange: $ telnet www.securityfocus.com 80 Trying 66.38.151.10... Connected to www.securityfocus.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK -> Server: Microsoft-IIS/5.0 Content-Location: http://66.38.151.10/Default.htm Date: Sat, 14 Sep 2002 04:20:27 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Fri, 13 Sep 2002 18:00:33 GMT ETag: "50d4ae744f5bc21:9db" Content-Length: 606 Netcraft says they ran Apache on Linux until today. I wonder what's going on over there?... ----ScottG.

4 3

FW: OpenSSL worm
by Avery Buffington 14 Sep '02

14 Sep '02

passing this along for those who may have not seen it yet -----Original Message----- From: Hal Flynn [mailto:flynn@securityfocus.com] Sent: Friday, September 13, 2002 12:23 PM To: focus-linux(a)securityfocus.com Subject: OpenSSL worm For those of you not aware, there has been a report of an OpenSSL worm in the wild. Discussion is on Bugtraq currently. Cheers, Hal Flynn Symantec Corp. "....You guys are the Marine's doctors; There's no better in the business than a Navy Corpsman...." -- Lieutenant General Lewis B. "Chesty" Puller, U.S.M.C.

2 1

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 13 Sep '02

13 Sep '02

Or you cut the lines coming into the city - i.e Chicago has about 5 diverse routes for fiber into the city. No explosives required and you get the same effect. ----- Original Message ----- From: Dave Israel <davei(a)algx.net> Date: Friday, September 13, 2002 10:52 am Subject: Re: Vulnerbilities of Interconnection > > On 9/13/2002 at 10:30:47 -0400, alex(a)yuriev.com said: > > > > > > > > > > Yet, it is reasonable that people expect x % of their > traffic to > > > > use IX's. If those IX"s are gone then they will need to > find another > > > > path, and may need to upgrade alternate paths. > > > > > > > > I guess the question is. > > > > > > > > At what point does one build redundancy into the network. > > > > > > No, it doesnt necessarily use IX's, in the event of there > being no peered path > > > across an IX traffic will flow from the originator to their > upstream> > "tier1" over a private transit link, then that "tier1" > will peer with the > > > destination's upstream "tier1" over a private fat pipe then > that will go to the > > > destination via their transit private link. > > > > > > I'm only aware of a few providers who transit across IX's and > I think the > > > consensus is that its a bad thing so it tends to be just small > people for whom > > > the cost of the private link is relatively high. > > > > I think you are missing a one critical point - IX in this case > is not an > > exchange. It is a point where lots of providers have lots of > gear in a > > highly congested area. However they connect to each other in > that area does > > not matter. > > > > Now presume those areas are gone (as in compeletely gone). What > is the > > possible impact? > > They're all completely gone? Then we have a bigger issue than the > Internet not working, because lots of us are dead. A lot of the > exchange areas are city-wide, in a literal sense. Take DC, for > example. Lots of folks connect in DC, not just at MAE-East, but also > via direct cross-connects between providers, following a large variety > of fiber paths owned by a variety of carriers. A single event that > removed all the connectivity from DC would either have to devastate > the city and surrounding suburbs, or at a minimum, distrupt > electronics (EMP airburst) or hit every power plant in the area (and > yeah, that kills folks, too, especially in winter.) > > Now, having destroyed civilization in DC (so to speak), we have > removed a major exchange point, but also all traffic generated in DC. > The rest of the Internet is fine. To break the rest of the exchanges, > we'd have to do the same to New York, Dallas, Boston, Chicago, > Atlanta, San Francisco, San Jose... And that's just in the States. > > If you were to hit a telco hotel (usually a hard target, but we'll > grant you the necessary firepower), you would inconvenience the > Internet in that area until another well-connected site could be > chosen and filled with equipment. Internet infrastructure is > logically mapped to telco infrastructure, and telco infrastructure is > ubiquitous. You're looking for a weakness where it isn't. If you > wanted to hurt the Internet, you wouldn't hit a city. You'd hit the > cross country fiber paths, out in the middle of nowhere. > > -Dave > > >

2 1

Security focus (aka bugtraq) reachability
by Mike Tancsa 13 Sep '02

13 Sep '02

Can anyone with a host in the IP range of 64.0.0.0/8 confirm if they can connect to the www.securityfocus.com or mail.securityfocus.com ? (i.e. the bugtraq people). I have tried from two separate networks (mine and a totally separate ISP nothing to do with my AS) and both cannot connect from different IP addresses in the 64.0.0.0/8 range. From IP addresses outside of 64/8 its fine. Its as if they dont have ip classless enabled or some rogue firewall rules / routes. e.g. quartz# telnet -s 199.212.134.17 www.securityfocus.com 80 Trying 66.38.151.10... Connected to www.securityfocus.com. Escape character is '^]'. ^] telnet> close Connection closed. quartz# telnet -s 64.7.128.97 www.securityfocus.com 80 Trying 66.38.151.10... telnet: connect to address 66.38.151.10: Operation timed out telnet: Unable to connect to remote host quartz# quartz# traceroute -s 199.212.134.17 www.securityfocus.com traceroute to www.securityfocus.com (66.38.151.10) from 199.212.134.17, 64 hops max, 40 byte packets 1 iolite (209.112.4.3) 1.206 ms 2.952 ms 3.377 ms 2 hespler-waterloo (199.212.135.65) 3.299 ms 0.497 ms 1.419 ms 3 waterloo-hespler (199.212.135.66) 2.839 ms 2.542 ms 1.740 ms 4 tor-wat (64.7.143.42) 8.786 ms 6.523 ms 9.926 ms 5 64.187.3.213 (64.187.3.213) 55.151 ms 49.215 ms 52.673 ms 6 h216-18-62-89.gtconnect.net (216.18.62.89) 53.744 ms 51.485 ms 52.029 ms 7 GE3-1.WANB-TOROON.IP.GROUPTELECOM.NET (216.18.63.13) 51.477 ms 51.297 ms 54.376 ms 8 POS9-2.WANB-CALGAB.IP.GROUPTELECOM.NET (216.18.32.165) 49.236 ms 52.984 ms 51.725 ms 9 216.18.32.6 (216.18.32.6) 52.931 ms 68.631 ms 47.683 ms 10 216.18.37.117 (216.18.37.117) 51.466 ms 51.354 ms 51.815 ms 11 216.18.37.117 (216.18.37.117) 54.124 ms !X *^C quartz# They are single homed out of GT (AS 6539). ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 1

ISPs who de-aggregate intentionally?
by Jeffrey Haas 13 Sep '02

13 Sep '02

As part of the process of making the latest BGP draft an IETF standard, the IDR working group is in the process of reviewing how the current draft reflects deployed code. As part of this effort, if anyone is aware of ISPs who intentionally de-aggregate routes and could contact me to share some of the reasoning and their methodologies behind this, I would greatly appreciate it. Please note - no names will be named, unless you want to be. A summary of the results will be posted back to this list. -- Jeff Haas NextHop Technologies

2 3