October 2005 - Test - lists.nanog.org

RE: Level3 problems
by David Hubbard 21 Oct '05

21 Oct '05

From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > > On Fri, Oct 21, 2005 at 02:28:23AM -0400, Richard A Steenbergen wrote: > > > > On Fri, Oct 21, 2005 at 09:26:06AM +0300, Emilian Ursu wrote: > > > > > > I see its completely down and several others are starting > > > to have problems. > > > Anyone knows whats up ? > > > > I think everyone sees them completely down across the board > (even mpls > > transport services), been that way for about 30 mins now. :) > > All of Speakeasy outbound SF (and possible other locations) is down, > after being on hold with them, they are saying Level3 and not further > information yet. > I'm sure Cogent is getting a kick out of this. :-) Our L3 link started having serious issues at about 1:45 EST and we turned it off. It seemed like an eternity for them to withdraw our routes from their peers though so they must be having some serious issues. From home on Verizon FIOS they seem to be trying to push most of their traffic onto their Level 3 link in Atlanta which is making me unable to get to Google and a few other big sites. For those with L3 that want to call them, they have parent ticket 1429209 open on this issue but you won't get any info yet so I'd give them some time. Dave

2 1

Are ISP's responsible for worms and viruses
by J. Oquendo 21 Oct '05

21 Oct '05

Bruce Schneier seems to think so... ////// http://www.theregister.co.uk/2005/10/19/schneier_talks_law/ By John Oates in Vienna 19th October 2005 RSA Europe 2005 ISPs must be made liable for viruses and other bad network traffic, Bruce Schneier, security guru and founder and CTO of Counterpane Internet Security, told The Register yesterday. He said: "It's about externalities - like a chemical company polluting a river - they don't live downstream and they don't care what happens. You need regulation to make it bad business for them not to care. You need to raise the cost of doing it wrong." Schneier said there was a parallel with the success of the environmental movement - protests and court cases made it too expensive to keep polluting and made it better business to be greener. ////// Let's one up this and blame vendors like Microsoft and hold them liable too. http://news.google.com/news?hl=en&ned=us&q=microsoft+patch+worm&btnG=Search… =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey

5 5

Re: /24 multihoming issue
by Kyaw Khine 20 Oct '05

20 Oct '05

I got an answer for my question. 7018/ATT does ACCEPT /24 routes from 701/mci. e.g 24.143.13.0/24 on route-server.ip.att.net has AS-PATH (7018 701 13368). Is 7018 preferring 19094 over 701 regardless of AS-PATH length? Or, 7018 will not take prefixes from other peers if a particular prefix is coming from 19094 regardless of AS-PATH? ** 7018 is just an example. There a quite a few ISP with the same behavior. Well .. I'm still in the maze. --- Kyaw Khine <joekhine(a)yahoo.com> wrote: > Says .. I pick 7018/AT&T. > 7018 is accepting 701/mci customer routes. But is > 7018 > accepting 701/mci customer /24 routes ??? > 7018 is definitely accepting 19094/telcove /24 > routes > because I see 64.9.17.0/24 on ATT route-server > (route-server.ip.att.net) > > So, why is 7018 receiving/accepting /24 from some > peers (19094) but not from others (701)??? > > That .. I can't figure out. > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/

3 4

LACNIC to start allocating from 189/8 and 190/8
by Ricardo Patara 20 Oct '05

20 Oct '05

This an announcement that LACNIC will start to make allocations from address space 189.0.0.0/8 and 190.0.0.0/8 on next November 2005. These blocks were allocated to LACNIC by IANA on last June 2005. This announcement has the objective to remind you that adjusts to any filters in place might be needed. For additional information about blocks under LACNIC administration and responsibility, please refer to: http://lacnic.net/en/registro/index.html Tests have been conducted in order to verify possibles routing problems and or filters. The following blocks are being announced: 189.0.0.0/20 189.128.0.0/21 190.0.0.0/20 190.128.0.0/21 Regards Ricardo Patara RS Manager -- L A C N I C Latin American and Caribbean Internet Addresses Registry

6 8

RE: multi homing pressure
by Owen DeLong 20 Oct '05

20 Oct '05

--On October 20, 2005 2:31:39 PM -0400 "Howard, W. Lee" <Lee.Howard(a)stanleyassociates.com> wrote: > >> Imagine instead, a world where Routing Location Identifiers >> are not coupled to End System Identifiers and Interdomain >> routing (AS-AS routing) occurred based on Routing Location >> Identifier, and only Intra-AS routing depended on the >> End System Identifier. >> >> For example: >> >> Host A connected to ISP X then ISP Y to ISP Z which >> provides service to Host B. >> >> Today, A, X, Y, Z all need to know how to reach B. >> >> If we separated the RLI from the ESI, then, the fact >> that B is reached via Z only has to be available >> information that can be looked up by A, and, X >> and Y only need to know how to get to Z. Only Z >> needs to know how to reach B. This allows the >> amount of data kept by each point along the way >> to be much smaller. > > Interesting. So Host A needs a lookup mechanism. If > I'm ISP X, then I'm providing a lookup server? You'd > need to figure out how to provide locally-significant > lookup results for topologically diverse hosts (A). > No.... ISP X needs to be able to look up a mapping for Host B->Z or B->{G,H,Q,Z} or such. Much like a Name->A record lookup occurs today, but, with a more authenticated/secure protocol. Further, since this is a "What ASs are proper termination points for B?" question, it's not locally significant to A (or locally significant at all). > What if X and Y (or Y and Z) connect at multiple points? > Would you hot-potato or cold-potato? Can you provide a > TE knob for that? > Yes... This would be router dependent, but, it is do-able. Instead of X knowing how to reach prefix Y.B and prefix Y.C and prefix Y.D, X would know all the ways to reach Y. TE would involve some mechanism for deciding which portions of traffic destined to Y use which path, and, in this case could be based on prefix or on some other method. Specifying the methods is outside of the scope of this proposal, but, examples could include: round robbin, shortest queue, least recently used, prefix hashing, flow hashing, etc. > It would be interesting to see a table showing how often > various routes are looked up. I suspect that a > significant portion of routes are seldom, if ever, used > by most parts of the network, and therefore don't really > need to be held and recalculated except on-demand. But Exactly, and, which significant portion that is is different depending on where on the network you are. > I'm not currently equipped to do that analysis, and it > would be completely different depending on where you are > in [your | the] network. > Exactly. That is why I think that global knowledge doesn't and can't scale in the long run. Currently, we are approaching routing the same way we used to approach name->IP mapping. (Remember the days when the /etc/hosts file was FTPd from SRI?) DNS is a much more scalable solution for that problem. I think that routing can be done on a similar basis. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

1 0

/24 multihoming issue
by Kyaw Khine 20 Oct '05

20 Oct '05

I'm having trouble announcing a single /24 from an ASN. ASN is multi-homed to ISP-A and ISP-B, prepending on ISP-B side. ASN in question has one and only one /24 which originally was from ISP-B /17 block. Some ISP only sees path from ISP-A and some from ISP-B and very few sees both paths. Apparently, when we are testing failover, it failed. (can't get to most of the internet, can't VPN in from outside, can't send mails etc.... BGP paht/route disappear from some of looking glasses) After the test, I registered /24 and ASN with RADB and things get slightly better, meaning a few more ISP sees both but majority of them still seeing single ISP path. I've contacted both ISPs and they both claimed they are announcing our /24 to the rest of the world, without manipulation. What am I missing here? Thanks, - Kyaw __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

6 15

RE: Scalability issues in the Internet routing system
by Susan Hares 20 Oct '05

20 Oct '05

Andre: Hence my earlier point on #2 - the prefixes in the routing hit one part of Moore's law. The FIB hits another. Using the compression ("cooking") per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a "minimum" set of routes can provide some leverage against the prefix growth. Tony point still stands. The "cookinjg" way to deal with prefix growth by using a compression algorithm for FIB insertion. Moore's law hits the security filters, the route filters, and lots more - that may or may-not be able to be "cooked". Sue Hares -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tony Li Sent: Tuesday, October 18, 2005 4:46 PM To: Andre Oppermann Cc: nanog(a)nanog.org Subject: Re: Scalability issues in the Internet routing system Andre, > capacity = prefix * path * churnfactor / second > > capacity = prefixes * packets / second > I think it is safe, even with projected AS and IP uptake, to assume > Moore's law can cope with this. > > This one is much harder to cope with as the number of prefixes and > the link speeds are rising. Thus the problem is multiplicative to > quadratic. You'll note that the number of prefixes is key to both of your equations. If the number of prefixes exceeds Moore's law, then it will be very difficult to get either of your equations to remain under Moore's law on the left hand side. That's the whole point of the discussion. Tony

5 6

RE: /24 multihoming issue
by John van Oppen 20 Oct '05

20 Oct '05

A few questions that might help narrow down the problem you were seeing: How exactly did you test the fail over? How much time did you wait for things to stabilize before deciding the fail-over did not work and turning the second connection back on? How is your outbound routing setup? Default routes or full tables? If defaults, it would be helpful to see any static routes that might be present. Assuming that 19094 is still announcing the aggregate, the problem of filtering should be a non-issue (assuming they don't filter the 701 path from their upstreams). In any case, things seem to look ok from an outside perspective to most everyone who has commented. John :) -----Ursprüngliche Nachricht----- Von: Elmar K. Bins [mailto:elmi@4ever.de] Gesendet: Thursday, October 20, 2005 1:43 AM An: Kyaw Khine Cc: nanog(a)merit.edu Betreff: Re: /24 multihoming issue joekhine(a)yahoo.com (Kyaw Khine) wrote: > I opened ticket with both 701 and 19094 when we did > failover 2 weeks ago. Both 701 and 19094 insist that > they just take the route and send it out to the rest > of the world. I do see the prefix via both 701 and 19094 (heavily prepended) here in Frankfurt, Germany: 5539 3549 701 33105 12312 3257 7911 19094 33105 33105 33105 33105 5669 286 209 701 33105, (received & used) 8220 2914 701 33105 (and some dupes) Neither one seems to filter wildly; I would believe that you hit aggregate-based (what's an allocation in ARIN terms?) ingress filters somewhere. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2(a)ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---

1 0

Re: IPv6 news
by John Reilly 19 Oct '05

19 Oct '05

Forgot sub to nanog-post.. -------- Forwarded Message -------- On Sat, 2005-10-15 at 22:02 -0700, David Conrad wrote: > I _really_ wish people would stop saying '"unlimited"' or 'almost > infinite' when talking about IPv6 address space. It simply isn't > true, even in the theoretical sense, and particularly given how > address space is being allocated now. It also gives many people the > wrong impression: that IPv6 addresses will mean every grain of sand > in the Universe (or whatever) can have portable address space. Am I mistaken in thinking that if shim6 (or something like it) did exist, that portable address space could be allocated to everyone (maybe with a different allocation policy?) to be used as (shim6) identifiers. Then, a number of years down the line, if the company met certain criteria they could get an ASN and announce the portable address space as routing prefix if they desired? John

14 23

origin as numbers to ignore in an analysis
by Randy Bush 19 Oct '05

19 Oct '05

if one is looking at origin-as in routing annoucements in route views, there are some asns that should be ignored, e.g., 7777. is there a good list of these somewhere. randy

1 0