- NANOG - lists.nanog.org

RE: Choosing new transit: software help?
by Sam Hayes Merritt, III 17 Oct '05

17 Oct '05

>> Anyway, does anyone have a suggestion for determine our next >> best transit? Essentially, I am looking for techniques of: >> >> 1. Gathering our current traffic patterns and subtotalling >> source/destination IP by ASN. Flowscan will do this. Origin and path. >> 2. Gathering our BGP views into a useful form for analysis. >> 3. Using #1 and #2 to analyze which new AS would make the >> most sense to connect to for transit. The goal would be for >> the new transit to reduce the number of AS we must transit >> given our customer's actual usage. > > I know most nanog responses seem to go off list immediately > but I'd be interested in this as well for traffic engineering. > A top AS and top prefix talkers would be really useful. Flowscan will do the top AS, out of the box. It could be hacked to go further. sam

2 1

Level 3's side of the story
by Richard A Steenbergen 17 Oct '05

17 Oct '05

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/10-0… "On October 6, Level 3, as it had repeatedly advised Cogent it would, terminated free traffic exchange with Cogent. Because Internet users, apparently without notice from Cogent and through no fault of their own, have been impacted, Level 3 has, effective immediately, re-established a free connection to Cogent. In order to allow Internet users to make alternative arrangements, we will maintain this connection until 6:00 a.m. ET, November 9, 2005. The effectiveness of this arrangement of course depends on Cogent's willingness to maintain their side of the traffic exchange. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

13 14

Re: And Now for Something Completely Different (was Re: IPv6 news)
by John Reilly 16 Oct '05

16 Oct '05

Forgot to subscribe to nanog-post first time round... -------- Forwarded Message -------- On Sun, 2005-10-16 at 05:31 -0400, Joe Maimon wrote: > Long story short, seperating endpoint/locator does nothing to allow > multiple paths to a single IP6 address/prefix to scale. I may be wrong - I haven't been following shim6 for long, but to me it does appear to scale because it is moving the host identity problem from being an IP address that exists in a single long prefix in the core routing table to being an identifier (128 bit number) which maps to a number of existing IP addresses which each already live in much shorter prefixes in the core routing tables. i.e. move the problem from the core to the edge nodes. Those edge node only need to locator lookup tables for the hosts they are talking to - not all that they may talk to. e.g. Say there is a host a::1 and my server has 3 IP addresses b::1, c::1 and d::1, via service providers B, C and D. As it stands, obviously a::1 can talk directly to the server using any of the addresses. Now, say I want to multi-home. Obviously in the past, I would have gotten my own prefix, say e:: and ASN and announced it. But now with shim6, I could use e::1 as the identifier for my host and use b::1, c::1 and d::1 as the locators. So now someone requests a AAAA for my host and gets back e::1. Now when a::1 tries to connect to e::1, the shim does a lookup and sees three possible locators - b::1, c::1 and d::1. It selects one of them and packets are then routed between a::1 and one of b::1, c::1 and d::1 in the same way that they would today. How are there traffic engineering problems when at the end of the day the packets will still be routed in the same way? Or am I missing some crucial point? Regards, John

1 1

design of a real routing v. endpoint id seperation
by Joe Maimon 16 Oct '05

16 Oct '05

How about something like this. A chunk of ipv6 space is carved off. This is assigned to multihoming desiring sites. All routers {can | should } filter this space from their tables completely by default - except the single prefix covering the entire space. A customer with a prefix assigned from this chunk has to connect with an ISP who has * a Very Large Multihoming (to handle scaling concerns) router somewhere in its network that peers to other ISP Very Large Multihoming routes. ISP operating a VLMrouter to offer multihoming service to their customers would originate the entire multihoming space prefix to their customers AND to all their peers. These would have ALL the prefixes from the Multihoming Space. * the customer would peer with the VLMrouter, receive no routes and advertise their prefix. * source routing allowed on ingres IF the destaddr is in the multihoming space AND the route-option is the Very Large Multihoming router * source routing is allowed within the ISP network The VLMrouter would make a SOURCE routing decision, putting a source route destination to the customer. * The ISP allows egress source routed packets What this means is that there are 2 tables on the internet, the table that ALL internet routes need have (like today) and the table that only an ISP offering access to multihoming need have. The ISP offering such access would only need, say one box per POP or so. So the scaling problem becomes much smaller in scope. Now only ISP wishing to offer multihoming services need to track the multihoming table. Additionaly, the tables are actually halved, the VLMrouter need not contain the normal internet routes and vice versa. The downside is that an ISP performing as multihoming table hoster would be a magnet for traffic that would possibly transit in and out. Smaller multihoming hosting ISPs would probably try to prepend the prefix mightily, or arrange not to originate it at all, and simply receive prefix source routed from an ISP they connect to who also hosts multihoming hosting AND originates the prefix. No changes to stacks, endpoint nodes or anything else needed. (if source routing still works in ip6?) Some source routing filtering capabilities needed for border patrolling something like this config-if#ip source-routing prefix-list multihoming-prefixes access-group allowed-source-routes Joe

1 0

Re: And Now for Something Completely Different (was Re: IPv6 news)
by Brandon Butterworth 16 Oct '05

16 Oct '05

> Think in the future, do we really want routers that'll handle millions of > prefixes and hundreds of thousands of AS numbers, just because people want > resiliance? Something will have to provide it and I don't want it to be each of my hosts. I'd rather the hundreds of hosts handle payload and a few proper network devices handle where to move it > If this can be solved on the end-user layer instead, it's more > scalable. Sadly most end users will have no idea and cause more trouble that it's worth if hosts do it brandon

1 0

Really OT: Re: Time for a real Internet highway (?)
by Scott Weeks 16 Oct '05

16 Oct '05

From: Randy Bush <randy(a)psg.com> To: "Scott Weeks" <surfer(a)mauigateway.com> Cc: nanog(a)merit.edu Subject: Re: Time for a real Internet highway (?) Date: Sat, 15 Oct 2005 12:14:51 -1000 > > The internet is global and without boundries. The US > > highway system is domestic with boundries. > > the history of the interstate bill is quite interesting. > among other things, it killed the trains, contributed to > the degredation of the inner cities, ... and guess which > industries lobbied it through. > > and why does oahu have interstate highways, anyway? All 56 miles of it, you mean? Be careful on that H-1, it's over 27 miles long. Might run outta gas... ;-) It's in the "Hawaii Omnibus Act of 1960...right between Opium Poppy Control Act and shortly before a passage headed Purchases of Typewriters" http://www.straightdope.com/classics/a3_129.html. Ever wonder why it's called the "National System of Interstate and *Defense* Highways"? Rhetorical question... Following NANOG methodology of late, we could make an analogy to a MAN here. Cars are packets, malformed data inside many packets >:-( MAJOR congestion at peak loads, no timing on the line, etc. scott

1 0

Re: Time for a real Internet highway (?)
by Scott Weeks 15 Oct '05

15 Oct '05

----- Original Message Follows ----- From: "Michael Painter" <tvhawaii(a)shaka.com> To: "NANGO" <nanog(a)merit.edu> Subject: Time for a real Internet highway (?) Date: Fri, 14 Oct 2005 13:07:32 -1000 > I'd be very interested in what folks here think of this: > > http://news.com.com/Time+for+a+real+Internet+highway/2010-1028_3-5894664.ht… The internet is global and without boundries. The US highway system is domestic with boundries. The writer doesn't get it at all. Analogies are WAAAYYY overrated. Move on; nothing to see there... scott

2 1

RE: IPv6 news - newbie
by Ben Butler 15 Oct '05

15 Oct '05

*********************** Your mail has been scanned by InterScan VirusWall. ***********-*********** "One thing i find promising/good: Lots of people here sent their v6 traces to the list, so it's not just a few random geeks messing with v6 as much anymore, it's there. - jared" Hi, Well this thread primarily, plus the problems I am having currently getting multicast & pim working correctly, have spurred me onto do the reading and multi-stack the network and start talking native v6 across the core to the various IXs + transits I am connecting to. I must confess that having read various Cisco + MS documents on v6 I cant quite see what all the fuss about its lots of work and its really hard is all about - but then I only operate a "small" UK network and multi-stack was way less complicated for me than tunnels. So I would recommend others have a look too. I have no idea whether there is a market for v6 connectivity / hosting amongst UK businesses, I guess we will find out. I wonder how long it will be before v4 internet is turned off??? Regards Ben

2 1

RE: SONET MUX
by Hannigan, Martin 15 Oct '05

15 Oct '05

> Hello, > > We are looking for a OC3 -> 3xDS3 MUX. (If it can grow up to > a OC12 -> > 12xDS3 thats a plus) > Sonet side will be 1+1 protected > > I have looked at the following equipment is there any other > sonet muxes that > i should look at? > > Adtran Opti-3 > Adtran OPTI-6100 > Cisco ONS 15310, 15327 > Fujitsu Flashwave 4010, 4100, 4300 > Fujitsu FLM 150 The difference between Fuji and Cisco is the backplane architecture. The former is redundant and is a five nines solution. The latter is not and is a four nines solution. You will find the cisco device cheaper to buy and operate. The cisco is also less RU and less power. If you haven't already lighted your own dark fiber network, there's a lot to know at layer 1 to be sure you get the redundancy you're looking for in layer 3. Have you considered leasing circuits from a LEC or buying a wavelength managed service? -M<

1 0

Re: IPv6 news
by Brandon Butterworth 15 Oct '05

15 Oct '05

> But I have also to admit that I'm shocked how few folks have the balls > (or is it lazyness?) to express their opinion on IPv6 multihoming in the > public, on the established fora for that stuff. The probably got bored of having "it doesn't scale" shouted at them > Almost zero feedback from enterprise / SME folks. That of course > makes it much easier... "see, noone really complains! we must be going > down the right road!". "it doesn't scale? forget it then that's no use to us we'll get on with something more productive" Just one d(3)peering has told them they are right to hold out for more simpler multi homing and not accept anything that aims to stop them I can't see them paying a premium for something that does less. brandon

1 0