- Test - lists.nanog.org

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

21 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 20 Oct '05

20 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 20 Oct '05

20 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

Two things more important than NANOG....
by Fergie (Paul Ferguson) 20 Oct '05

20 Oct '05

Sorry for the interruption, but I couldn't let these two anniversaries pass without bringing them to your attention. http://fergdawg.blogspot.com/2005/10/in-memoriam-abha-ahuja.html [and] http://fergdawg.blogspot.com/2005/10/belatedly-october-16-1998-rip-jon.html I'll crawl back under my rock now... Cheers, - ferg -- "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

RE: Verizon outage in Southern California?
by Olsen, Jason 19 Oct '05

19 Oct '05

> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Matthew Black > Sent: Tuesday, October 18, 2005 3:13 PM > Telephone service is beginning to be restored in the Long > Beach area but is still sporadic. Our ATM WAN link through Sprint came back up around 1345 Central time, and the two DS1s for the school's Internet service were revived about fifteen minutes ago (1507 CDT). They've been rock-solid so something must be going right out there. When I called Sprint about any information they might have for the outage the tech said that the area was down due to a Verizon DACS failure. That must have been a spectacular failure, because I'm reading that it wiped out most everything ( http://www2.presstelegram.com/news/ci_3128087 indicates four tandems hit?! ) in the area. The articles are primarily focusing on the impact to E911 services, followed with the hit to POTS lines. I have yet to see any mention of impact to data in any of 'em. Here's what intrigues me about this outage: if it wiped out E911, most of the POTS and also impacted data services (as Jay Hannigan and I can attest), how did the cell towers that are also served by the network live through it? Jason "Feren" Olsen Senior Network Engineer DeVry, Inc Em: jolsen(a)devry.com Ph: 630-645-1607 One Tower Lane INOC-DBA: 19258*526 Fx: 630-389-2929 Oakbrook Terrace, IL 60181

5 4