Re: The ORIGIN option on BGP - what is it for?
Not saying this is what others do, but you can certainly use that criteria (via a route-map) to control whether a route is prefered by a peer over two identical (in all other aspects) paths. DJ Peter Boothe wrote: What makes you mark routes as ORIGIN: IGP vs ORIGIN: EGP? I just checked out the latest routeviews snapshot to see what the origins of various routes were set to. The command line $ bzcat oix-full-snapshot-latest.dat.bz2 | sed -e 's/.* //' | sort \ | uniq -c | sort -nk1 Gave me a bunch of crap from overly-long lines, and then 9091 e 682087 ? 7560175 i Which means that out of 8,251,353 routes in routeviews, only 9,091 are marked as ORIGIN: EGP, while 682,087 are not configured as one or the other, and the other *7.5 million* are marked ORIGIN: IGP. So my question is: What do people use ORIGIN: EGP vs ORIGIN: IGP to distinguish? What makes a route EGP vs. IGP to you? -Peter -- Peter Boothe Graduate Student in Computer Science Beyond BGP Project University of Oregon http://soy.dyndns.org/~peter
Re: Are ISP's responsible for worms and viruses
--On October 20, 2005 9:32:44 PM +0100 Freminlins [EMAIL PROTECTED] wrote: Owen DeLong wrote: If companies that made vulnerable OSs were held liable for the damage caused by those vulnerabilities, you would rapidly see $$ make a BIG difference in the security quality of OS Software. How would that work for free/open source OSs/software? Who exactly would be held liable? The contributors? Free OSs are just as capable of sending out malware/virus infected emails, etc. as commercial systems. That depends: Free closed source: I would presume the closed source provider or no one. Hard to assign liability when money did not change hands. No money, no duty to care in most cases. Product liability is pretty much limited to products that are sold. Open Source: I would expect no liability exists because... 1. No money changes hands, no duty to care. 2. End user has full access to source, so, has at least shared responsibility for fitness to purpose. 3. Full access to source means end user cannot claim that vulnerability was hidden from end user. 4. Full access to source means end user has ability to correct vulnerability as soon as identified. Finally, while your statement is theoretically true, in practice, resolutions to vulnerabilities in open source software tend to be delivered much faster than in closed source software. Even allowing for the difference in market share, the percentage of open source based systems which are owned and acting as spambots is much lower than the percentage of closed-source systems which are doing so. (note: in this, although it is hybrid closed/open, I'll even count MacOS X in the open source for this purpose). Owen pgpnhxsuA3Uco.pgp Description: PGP signature
Level3 problems
I see its completely down and several others are starting to have problems. Anyone knows whats up ? Thanks
Re: Level3 problems
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. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Level3 problems
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. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html
Re: multi homing pressure
Because of the number of misconceptions of my idea presented, I'm posting this to the list. Those uninterested, feel free to ignore. Those interested, feel free to follow up with me directly. After this, I will not be continuing this on the list unless there is significant interest from multiple parties. Owen --On October 21, 2005 12:12:22 AM +0200 Elmar K. Bins [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Owen DeLong) wrote: Why wouldn't rewriting work? The encapsulation you show below is little different from the rewrite I propose. Except that it conserves the original addressing information, which I believe to be important. Look at what I proposed again... My rewrite does NOT modify the original addressing, it ADDs data to the header. First, let's start with something that looks a little more like an IPv6 datagram: You're only talking v6? Why? Anyway, let's follow this through... Because we don't really need to solve this in V4. V4 multihoming is well understood and is unlikely to hit a scaling limit on router capabilities before we hit an end of life on address space. [DST: ::B Src: ::A EXT[RLI: Z] Prot: ICMP [...]]] Then, Upon arrival at the first Router within AS Z, the packet is rewritten again: [Dst: ::B Src ::A Prot: ICMP [Type: Echo Req [Data: ...]]] You have used special fields in the IP header. Well, that's an elegant way to do it _if_ you have this field. You do not have this in IPv4, and that's what we'll be stuck with for the next couple of years, unfortunately (or not: I can remember v4 addresses much more easily...) Again... Multihoming already works in V4 and there is no real need to solve this in the V4 world. final packet arrives unchanged. Further, any router along the way that doesn't understand the Extension header doesn't have to really look at it, so, during transition, routing can occur on either RLI or Dst. If you encapsulate, you lose that transitional ability. Good point you have here. Actually, even that isn't necessarily an accurate characterization of what I am suggesting. The packet should not be rewritten until it reaches a DFZ router outside of AS Z. Whether that is within AS Y, or somewhere upstream (possibly more than one level upstream) of AS Y, that's where the initial rewrite should occur ideally. If the first DFZ router doesn't yet know about RLI, however, then, the first RLI aware router in the DFZ prior to reaching AS Z should do the rewrite. I see a couple of shortcomings to your idea: - it is limited to an IP protocol that carries a RLI header field - you only include one RLI in the packet header You only need one RLI in the packet header. More would actually be bad. Let me 'splain. If you are routing on RLI, then, you need to choose the best path and stick to it. If the packet doesn't make it through that way, that's OK... That's what retransmits are for. If you start rerouting it on the fly, it's likely to loop a lot before dying, but, little else is achieved. Worse, it's likely to loop even if it might have gotten there given one path and only one path chosen as best by the RLI inserting router. I do neither believe that we'll get rid of v4 soon, nor do I think it is a good idea to let the sender decide to which RLI to route the packet. The benefit of multihoming is lost then. No, it is not. Since the RLI inserting router has up to date dynamic information about which RLIs are reachable and at what cost (BGP distance vector data), you have the same overall effect as dynamic routing today. Just instead of trading prefix routes everywhere, you trade AS reachability info everywhere and map prefixes to ASs. Um... No... You don't want multiple RLIs in the packet. You want the router inserting the RLI to have the ability to chose from multiple RLIs. Definitely not. Definitely so. If you start playing with changing RLI along the way, then, you run into serious difficulty with looping possibilities. That is not intended. Another way to avoid loops must be found, and I believe the danger is pretty small. The RLIs in the packet are not changed in transit. But of course every new router can choose towards which RLI to send the packet. Luckily, distance on a working path in the Internet generally decreases as you approach a target you have chosen. I do see that there is a danger of looping, but I believe a way to detect that can be found. Why. Why not keep it simple and recognize that when routing changes, some packets get lost during the shuffle. This is the way it is today, and, this wouldn't be any worse with this system. Also, this means that loop detection continues to work essentially the way it does today, and, it doesn't require near as much new code or protocol support as what you propose. By choosing an RLI close to the source that, at the time of selection, had a valid dynamic advertised (BGP) AS Path for reachability, you seriously reduce the likelihood of looping
Re: Level3 problems
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 ? They're giving out master ticket #'s of 1429209 1429184 and 1429189 depending on who you talk to apparently (though I don't think they'll have any trouble finding it under total network outage :P). Rumor has it a maintenance in Chicago backfired (it did start at exactly 02:00 EDT on the dot). Anyone else having flashbacks to IGP/CEF bugs? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Level3 problems
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Level3 problems
On 10/21/05, David Hubbard [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 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 ? It seems the problem is worldwide. Here in Italy I lost both BGP sessions (primary and backup) at 7.51 CET, I can't even ping their router anymore. And still no response from their European Support... -- I'm Winston Wolf, I solve problems.
RE: Level3 problems
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 ? They're giving out master ticket #'s of 1429209 1429184 and 1429189 depending on who you talk to apparently (though I don't think they'll have any trouble finding it under total network outage :P). Rumor has it a maintenance in Chicago backfired (it did start at exactly 02:00 EDT on the dot). Anyone else having flashbacks to IGP/CEF bugs? :) I was given the same info re: maintenance. While on the phone with them, I started to see things come back to life, but still a big mess at the moment. -Sean Sean P. Crandall VP Engineering Operations MegaPath Networks Inc. 6691 Owens Drive Pleasanton, CA 94588 (925) 201-2530 (office) (925) 201-2550 (fax)
Re: multi homing pressure
Re Owen, Just a short (ok, now I read it again, it's grown...) answer to the list, but you're right, we might continue this in private. (Reply-To set) Thanks for being so patient explaining everything, and for discussing with a (still somewhat) hairy-head like myself :-) [EMAIL PROTECTED] (Owen DeLong) wrote: You're only talking v6? Why? Anyway, let's follow this through... Because we don't really need to solve this in V4. V4 multihoming is well understood and is unlikely to hit a scaling limit on router capabilities before we hit an end of life on address space. ... Again... Multihoming already works in V4 and there is no real need to solve this in the V4 world. I can expect a strongly rising demand of end-customers to multihome right now, and we still have a bunch of /24s to go on. But then, it may only add another 300Kprefixes to the BGP table, which is not really an order of magnitude. As to the it works - surely it does, but up to now I believed it wouldn't scale far enough. Maybe I'm wrong (see Moore). You only need one RLI in the packet header. More would actually be bad. Let me 'splain. If you are routing on RLI, then, you need to choose the best path and stick to it. If the packet doesn't make it through that way, that's OK... That's what retransmits are for. If you start rerouting it on the fly, it's likely to loop a lot before dying, but, little else is achieved. Worse, it's likely to loop even if it might have gotten there given one path and only one path chosen as best by the RLI inserting router. Actually, I don't understand the last part; why should it loop in this case? It's a matter of destination(s) look-up on the core routers, just like in your model. Only the destination's potentially more than one. It would of course loop anyway if it entered (the same part of) the same transit AS again, but that is independent of whether you see the ESI or not (aka RLI insertion vs. encapsulation). I'm still not comfortable with the box in Sao Paolo determining whether the packet should go to ISP A in Hamburg or ISP B in Munich or ISP C in Frankfurt (from where the respective ISP would forward it to the customer in Cologne). This decision can easily be made later on and result in a better path. No, it is not. Since the RLI inserting router has up to date dynamic information about which RLIs are reachable and at what cost (BGP The inserting router is less probable to have up-to-date RLI topology information than routers closer to the packet's destination, due to the way the topology information gets distributed. No. You have nearly the same advantage you have today. If the path goes away, then, hopefully by the time of retransmit, the RLI inserting router will have learned that that RLI destination is no longer reachable, and, he will insert a different one in the retransmitted packet. Same as what happens today with the retransmitted packet being sent a different way. I don't like hopefully here, but maybe that's our trade-off anyway. You are, nonetheless, giving the RLI inserting router somewhat hotter information, if it has to make the topological choice (choose destination RLI and, implicitly, select a group of possible paths over all others). If it were only to know the translation information which does not change as often, I'd be much happier. What I also do not like is the wrong analogy to today's routing mechanism. You claim implicitly that the RLI inserting router's new decision was the same as what happened in the Internet routing system today: rerouting packets. This means, in other words, you're making a global choice locally. But of course, the current system does not reroute at the packet source (only), it can do this on any hop between source and destination and thus makes only local choices locally. This is a significant difference, because it makes adaptation to changes easier, faster, and it works with only partial convergence along the path. Who exactly chooses? IMHO it's AS B that does the selection. And: B is closer to the target, aka the source of the routing information. Its BGP table is more probable to be up-to-date. Right... B is the first DFZ router. A is not likely DFZ since A is not multihomed in your scenario. No need for A to be DFZ if A only talks to B. Yesyesyes, consider A B C D E F T A B C D G H T What now? Is D necessarily the first DFZ router? I think not. So you are still using B for the RLI insertion; B has to make the choice, and that choice may be wrong or sub-optimal. Z's ESI is visible in the core, but, not carried in the routing table. Z does not have an RLI, but, instead uses the RLIs of their provider(s). Yup, in your add something to the header scenario, the ESI is still visible. In mine it is not (it is, but encapsulated). Actually, it does not matter, as long as the destination can revive this information (destination as in the re-translating router). In the long run (once
RE: Level3 problems
Anyone get anything useful out of L3 yet? Dave From: John van Oppen (list account) [mailto:[EMAIL PROTECTED] I am getting fast busy signals on all my Washington based level3 DID numbers at the moment... A level3 full peer up here seems to only seek 68k routes... not so good (thankfully that was not on my network). John :) -Ursprüngliche Nachricht- Von: David Hubbard [mailto:[EMAIL PROTECTED] Gesendet: Thursday, October 20, 2005 11:54 PM An: [EMAIL PROTECTED] Betreff: RE: Level3 problems From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
RE: Level3 problems
Still voice greeting... Level(3) is experiencing a wide spread network instability -Vikas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hubbard Sent: Friday, October 21, 2005 1:11 AM To: [EMAIL PROTECTED] Subject: RE: Level3 problems Anyone get anything useful out of L3 yet? Dave From: John van Oppen (list account) [mailto:[EMAIL PROTECTED] I am getting fast busy signals on all my Washington based level3 DID numbers at the moment... A level3 full peer up here seems to only seek 68k routes... not so good (thankfully that was not on my network). John :) -Ursprüngliche Nachricht- Von: David Hubbard [mailto:[EMAIL PROTECTED] Gesendet: Thursday, October 20, 2005 11:54 PM An: [EMAIL PROTECTED] Betreff: RE: Level3 problems From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
RE: Level3 problems
Just got off the phone with Level(3)... Bonnie. She's saying that they are experiencing a large-scale routing problem (duh) and that they estimate one more hour... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hubbard Sent: Friday, October 21, 2005 1:11 AM To: [EMAIL PROTECTED] Subject: RE: Level3 problems Anyone get anything useful out of L3 yet? Dave From: John van Oppen (list account) [mailto:[EMAIL PROTECTED] I am getting fast busy signals on all my Washington based level3 DID numbers at the moment... A level3 full peer up here seems to only seek 68k routes... not so good (thankfully that was not on my network). John :) -Ursprüngliche Nachricht- Von: David Hubbard [mailto:[EMAIL PROTECTED] Gesendet: Thursday, October 20, 2005 11:54 PM An: [EMAIL PROTECTED] Betreff: RE: Level3 problems From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Level3 problems
On 10/21/05, David Hubbard [EMAIL PROTECTED] wrote: Anyone get anything useful out of L3 yet? In Italy service has been restored at 9.39 CET, or at least my BGP sessions came up at that time. Traffic is flowing fine, I can reach USA and all other locations with no trouble. . -- I'm Winston Wolf, I solve problems.
Re: Level3 problems
Marco Matarazzo wrote: On 10/21/05, David Hubbard [EMAIL PROTECTED] wrote: Anyone get anything useful out of L3 yet? In Italy service has been restored at 9.39 CET, or at least my BGP sessions came up at that time. Traffic is flowing fine, I can reach USA and all other locations with no trouble. . In Ireland / UK the service came back up at 08:45 (one hour ago) and appears to be stable.
RE: Level3 problems
PAIX, (Palo Alto, CA) -- service back online... Tustin, (Orange County, CA) -- service back online North Las Vegas -- service back online -Vikas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Friday, October 21, 2005 1:45 AM To: Marco Matarazzo Cc: [EMAIL PROTECTED] Subject: Re: Level3 problems Marco Matarazzo wrote: On 10/21/05, David Hubbard [EMAIL PROTECTED] wrote: Anyone get anything useful out of L3 yet? In Italy service has been restored at 9.39 CET, or at least my BGP sessions came up at that time. Traffic is flowing fine, I can reach USA and all other locations with no trouble. . In Ireland / UK the service came back up at 08:45 (one hour ago) and appears to be stable.
RE: Level3 problems
I still see my link in San Francisco - China Basin still offline... probably a matter of time. -Vikas -Original Message- From: Vikas Khanna (NextWeb) [mailto:[EMAIL PROTECTED] Sent: Friday, October 21, 2005 1:54 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Level3 problems PAIX, (Palo Alto, CA) -- service back online... Tustin, (Orange County, CA) -- service back online North Las Vegas -- service back online -Vikas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Sent: Friday, October 21, 2005 1:45 AM To: Marco Matarazzo Cc: [EMAIL PROTECTED] Subject: Re: Level3 problems Marco Matarazzo wrote: On 10/21/05, David Hubbard [EMAIL PROTECTED] wrote: Anyone get anything useful out of L3 yet? In Italy service has been restored at 9.39 CET, or at least my BGP sessions came up at that time. Traffic is flowing fine, I can reach USA and all other locations with no trouble. . In Ireland / UK the service came back up at 08:45 (one hour ago) and appears to be stable.
Re: design of a real routing v. endpoint id seperation
ISPs who wish to connect customers who have allocations from the multihoming space must a) announce the whole space aggregated b) peer with other providers who host other customers As mentioned, this huge aggregate attracts unwanted traffic. It would make more sense if this so-called multi-homing aggregate was to be carved up into smaller aggregates based on the geographical topology of the network. That way, providers whose PoPs are geographically close to each other (in the same city) could use multihoming addresses from the same aggregate. Providers could then choose to only offer multihoming services in those cities where they peer with other multihoming providers. The number of aggregate routes announced mushrooms to about 5,000 because there are that many cities in the world with a population greater than 100,000 people. This geotopological address aggregation will still result in some unwanted traffic but a provider is at liberty to carry more detail internally and hand it off closer to the source. For instance, a provider with PoPs in New York and Paris, could elect to carry all Paris routes in New York in order to shed peer traffic before it crosses the Atlantic. I wonder if the solution to these issues would be facilitated by carrying some additional policy info in a routing protocol. Attributes like ROUTE_COMES_FROM_A_PEER_WHO_SELLS_MULTIHOMING or similar. If there are only 5000 or so peering locations in the world, then perhaps an attribute like ROUTE_HEARD_FROM_PEER_IN_CITY_439 would also be useful. --Michael Dillon
Routers RAM and BGP table bloat
*** Your mail has been scanned by InterScan VirusWall. ***-*** Hi, Apologies if this is not deemed operational enough. Further to the debate about prefixes / v6 / multihomeing etc etc. The growing size of the route table, de-aged networks and increasing corporate mutlihomeing all drive up the size of the route table and brings pressure to bear on the memory requirements of our routers. Now while I want to steer well clear of the my box is better than your box discussion - I was wondering if anyone had a view on what would happen if I managed to source an SDRAM of 512MB / 1GB of the same specification as the 256MB Cisco compatible memory that you use in an 7200 NPE225. Cisco say the maximum ram for that NPE is a pitiful 256MB, I am sure the memory manufacturers will have made larger SDRAMs, while recognising it would be fully unsupported what would happen if we tried to stick in a larger memory module in the NPE I can always go out and spend 5K per box on NPE G1 cards for each router, but operationally I don't need faster processors but I do need more RAM and I don't really see why I should be forced by Cisco to purchase an expensive upgrade just because they say 256MB is the maximum when I suspect we would be able to get away with sticking in a large SDRAM. Anyone got any thoughts on whether this would work or not? It must be costing us all a small operational fortune in router upgrades brought about by the growing BGP table size. And yes I do know that if I was running Quagga on a PC I could have 4GB of inexpensive RAM very easily, but I want to avoid the x is better than y discussion. Kind Regards Ben Butler ++ C2 Internet Ltd Globe House The Gullet Nantwich Cheshire CW5 5RL W http://www.c2internet.net/ T +44-(0)845-658-0020 F +44-(0)845-658-0070 All quotes services from C2 are bound by our standard terms and conditions which are available on our website at: http://www.c2internet.net/legal/main.htm#tandc
Re: design of a real routing v. endpoint id seperation
On Thu, 2005-10-20 at 07:49 -0400, Joe Maimon wrote: SNIP C) - end node performs locator lookup - end node encaps - destnode decaps This could be as easy as performing IPinIP with srv records and DDNS. There is an 'example possible alternate use' in the following document: http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ayiya-02.txt page 20, section 9.3 which describes something that could be called: - double NAT or: - encapsulation The problem though is that this requires the end-site/host to upgrade on both sides otherwise you loose this special multihoming capability. You need to detect that, which costs overhead etc and of course how do you figure out where the other end is at that moment and how do you know that the path between them is optional and and and a lot more issues :) To repeat: that section is only an 'example possible alternate use' so don't comment on it (except if you find typos or so ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Routers RAM and BGP table bloat
Ben Butler wrote: if anyone had a view on what would happen if I managed to source an SDRAM of 512MB / 1GB of the same specification as the 256MB Cisco compatible memory that you use in an 7200 NPE225. Cisco say the maximum ram for that NPE is a pitiful 256MB, I am sure the memory manufacturers will have made larger SDRAMs, while recognising it would be fully unsupported what would happen if we tried to stick in a larger memory module in the NPE I am just guessing here, but if the manufacturer says 256MB is the maximum, I would expect that the unit is not able to address more than 256MB memory, regardless of the amount you plug in to it. It must be costing us all a small operational fortune in router upgrades brought about by the growing BGP table size. And yes I do know that if I was running Quagga on a PC I could have 4GB of inexpensive RAM very easily, but I want to avoid the x is better than y discussion. Apart from the fact what is better than something else: I think it is very brave to use unsupported hardware to operate a network. If something fails, you are on your own then. No support from the vendor. One of the things where being brave and being insane are only seperated by a very thin line ;-) Nils
Re: image stream routers
behind their gurantee. If it doesn't work, they'll either fix it, or give you your money back. I'm way behind.. just getting caught up on NANOG: Circa 2000 I got stuck with one of the ImageStream DS3 systems, tried to return it and get our money back and could not.. Our reason for returning it was the card would not do fractional DS3 ie: set CSU bandwidth but would work fine for full DS3. We needed the frac DS3 (were were small.. could not afford a full DS3) even though we were told that it would (Sales Droids!). The only good thing was, I was able to recycle the hardware we got stuck with into something kinda useful.
The Cidr Report
This report has been generated at Fri Oct 21 21:45:55 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
14-10-05169210 113699
15-10-05169112 113683
16-10-05169174 113715
17-10-05169181 113788
18-10-05169304 113813
19-10-05169382 113960
20-10-05169661 114047
21-10-05169933 113957
AS Summary
20629 Number of ASes in routing system
8548 Number of ASes announcing only one prefix
1506 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91331328 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 21Oct05 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 169897 1138735602433.0% All ASes
AS4323 1188 234 95480.3% TWTC - Time Warner Telecom
AS18566 8649 85599.0% COVAD - Covad Communications
AS721 1074 314 76070.8% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS4134 1002 251 75175.0% CHINANET-BACKBONE
No.31,Jin-rong Street
AS7018 1506 987 51934.5% ATT-INTERNET4 - ATT WorldNet
Services
AS22773 544 29 51594.7% CCINET-2 - Cox Communications
Inc.
AS19916 541 76 46586.0% ASTRUM-0001 - OLM LLC
AS3602 568 110 45880.6% SPRINT-CA-AS - Sprint Canada
Inc.
AS9583 782 383 39951.0% SIFY-AS-IN Sify Limited
AS6197 941 551 39041.4% BATI-ATL - BellSouth Network
Solutions, Inc
AS17676 470 105 36577.7% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS6467 409 57 35286.1% ESPIRECOMM - e.spire
Communications, Inc.
AS812368 25 34393.2% ROGERS-CABLE - Rogers Cable
Inc.
AS4766 605 292 31351.7% KIXS-AS-KR Korea Telecom
AS15270 338 25 31392.6% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS14654 2926 28697.9% WAYPORT - Wayport
AS9498 387 108 27972.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS6167 331 59 27282.2% CELLCO-PART - Cellco
Partnership
AS9929 320 49 27184.7% CNCNET-CN China Netcom Corp.
AS17488 334 84 25074.9% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS1239 854 606 24829.0% SPRINTLINK - Sprint
AS6140 418 173 24558.6% IMPSAT-USA - ImpSat
AS18101 264 22 24291.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS5668 483 242 24149.9% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS19115 267 27 24089.9% CHARTER-LEBANON - Charter
Communications
AS1221 757 518 23931.6% ASN-TELSTRA Telstra Pty Ltd
AS2386 922 686 23625.6% INS-AS - ATT Data
Communications Services
AS6198 477 253 22447.0% BATI-MIA - BellSouth Network
Solutions, Inc
AS7545 519 301 21842.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS11456 287 74 21374.2% NUVOX - NuVox Communications,
Inc.
Total 18112 66561145663.3% Top 30 total
Possible Bogus Routes
24.246.0.0/17AS7018
Re: The ORIGIN option on BGP - what is it for?
On Thu, Oct 20, 2005 at 10:34:35PM -0700, Peter Boothe wrote: So my question is: What do people use ORIGIN: EGP vs ORIGIN: IGP to distinguish? What makes a route EGP vs. IGP to you? Origin is a mandatory transitive attribute which is being used in the BGP decision algorithm. If you have a prefix with the same localpref and aspath-length, the decision will be made based on the lowest origin-value. IGP wins over EGP, EGP wins over incomplete. You might use it to influence your inbound traffic. -- Sabri please do not throw salami pizza away
Re: Level3 problems
On Fri, 21 Oct 2005 00:18:43 -0700 Sean Crandall [EMAIL PROTECTED] 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 ? They're giving out master ticket #'s of 1429209 1429184 and 1429189 depending on who you talk to apparently (though I don't think they'll have any trouble finding it under total network outage :P). Rumor has it a maintenance in Chicago backfired (it did start at exactly 02:00 EDT on the dot). Anyone else having flashbacks to IGP/CEF bugs? :) I was given the same info re: maintenance. While on the phone with them, I started to see things come back to life, but still a big mess at the moment. Here in Northern Virginia / Tyco Road, everything went down at 2:00 AM EDT and seemed to come back at about 4:00 AM. BGP looks normal, but my traffic is still down by a factor of ~ 2. Multicast beacon connectivity is also still lousy, so I would tentatively conclude that there are still problems out there somewhere. On the other hand, streaming audio to my home in Cox Communications doesn't seem to have lost a packet in 2 hours. Regards Marshall Eubanks -Sean Sean P. Crandall VP Engineering Operations MegaPath Networks Inc. 6691 Owens Drive Pleasanton, CA 94588 (925) 201-2530 (office) (925) 201-2550 (fax)
Re: The ORIGIN option on BGP - what is it for?
On Oct 21, 2005, at 1:34 AM, Peter Boothe wrote: What makes you mark routes as ORIGIN: IGP vs ORIGIN: EGP? I just checked out the latest routeviews snapshot to see what the origins of various routes were set to. The command line $ bzcat oix-full-snapshot-latest.dat.bz2 | sed -e 's/.* //' | sort \ | uniq -c | sort -nk1 Gave me a bunch of crap from overly-long lines, and then 9091 e 682087 ? 7560175 i Which means that out of 8,251,353 routes in routeviews, only 9,091 are marked as ORIGIN: EGP, while 682,087 are not configured as one or the other, and the other *7.5 million* are marked ORIGIN: IGP. So my question is: What do people use ORIGIN: EGP vs ORIGIN: IGP to distinguish? What makes a route EGP vs. IGP to you? Mostly load balancing, thought manually setting it via route maps. -- TTFN, patrick
Re: Routers RAM and BGP table bloat
On Fri, 21 Oct 2005, Nils Ketelsen wrote: I am just guessing here, but if the manufacturer says 256MB is the maximum, I would expect that the unit is not able to address more than 256MB memory, regardless of the amount you plug in to it. Occasionally, that's not the case. i.e. the NPE225 was originally spec'd as having a max RAM capacity of 128mb. I've got an old Sony notebook that Sony says is upgradable to 256mb...but several manufacturers make a more densely populated dimm for it that allowed me to upgrade it to 384mb. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Routers RAM and BGP table bloat
Nils Ketelsen [EMAIL PROTECTED] writes: Ben Butler wrote: if anyone had a view on what would happen if I managed to source an SDRAM of 512MB / 1GB of the same specification as the 256MB Cisco compatible memory that you use in an 7200 NPE225. Cisco say the maximum ram for that NPE is a pitiful 256MB, I am sure the memory manufacturers will have made larger SDRAMs, while recognising it would be fully unsupported what would happen if we tried to stick in a larger memory module in the NPE I am just guessing here, but if the manufacturer says 256MB is the maximum, I would expect that the unit is not able to address more than 256MB memory, regardless of the amount you plug in to it. That's not entirely a reasonable conclusion - the npe225 only supported 128m and a lot of us were running them with 256m. Apart from the fact what is better than something else: I think it is very brave to use unsupported hardware to operate a network. If something fails, you are on your own then. No support from the vendor. Of course, if you don't have the hardware under support contract in the first place... One of the things where being brave and being insane are only seperated by a very thin line ;-) Indeed. ---Rob
Re: design of a real routing v. endpoint id seperation
(apologies to Owen for CC'ng list, his points are valid concerns that I hadnt addressed or considered properly) Owen DeLong wrote: c) Carry a much larger table on a vastly more expensive set of routers in order to play. ISPs who dont wish to connect these customers should feel free not to, and that will have no bearing on the rest of those who do. Somehow, given C) above, I am betting that most providers will be in this latter category. Considering that most people who are in favor of multihoming for ipv6 believe that there is customer demand for it, the market forces would decide this one. Additionally, until there are a few hundred thousand routes in the multihoming table, I dont see any more expense than today, merely an extra box in the pop. It could be years away that the doomsday table growth the anti-multihoming crowd predicts could occur. Only at that point would expensive seperate routers be needed. In fact seperate routers makes the multihoming table very small, at least to start with. It would be an implementation detail. An ISP could easily start off by simply not announcing the more specifics in the prefix space, without the new router systems. The point is, that the scaling problems multihoming brings would be limited to a) ISP's who want to offer service to customers who want to multihome b) The system that the ISP runs to provide this service. This is in contrast to todays mechanism, where customers who want to multihome affect everyone who accepts a full BGP feed. At the time customer demand worldwide demanded seperate routing tables, would be the time that ISPs would be able to decide whether the roi would be sufficient or not for them to keep their investment. Such a scheme would be a money where your mouth is. You say there is customer demand for multihoming? Well here it is. Lets see which ISPs want to implement it and which customers want to pay extra (FSVO extra) for it. In fact, customers who multihome in this way, need not use the same ASN space as the rest of the world, just unique to the multihoming table (that might not work well if ISP's faked it by simply not advertising the more specifics they carried internally) This concept brings true hierarchy, and thus scalability, to the routing table. If you are referring to the affect that this will attract unwanted traffic, that would be considered a COB. That too, but, primarily, c). There are simple ways to minimize this. 1) standard BGP tricksanti-social to be sure, such as prepending, meds.. 2) Transit-multihoming peering, where you depend more on external parties who peer with you on the multihoming plane more popular advertisement to bring you a higher ratio of traffic you are interested in. A small multihoming-table-carrying ISP would want to arrange things so that he pays a bit mer per (Mn|Gb) from his multihoming-table-peer, but does not have to attract large quantities of unwanted traffic from his non-multihoming-table peer. In essence, the previous discussion about LNP suggested that telco's must do the same thing, attract unwanted traffic, traffic they must switch right back out of their network. Except they don't. My formerly ATT number does not go through ATTs network to reach me just because it was ported. Read up on how SS7 actually works before you make statements like this that simply aren't true. So I have been toldapparently I mistook the conslusions of the relevant threads. apologies. Owen
RE: design of a real routing v. endpoint id seperation
Considering that most people who are in favor of multihoming for ipv6 believe that there is customer demand for it, the market forces would decide this one. We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home.
NANOG 35 PGP keyring
Joe Abley is coordinating a set of PGP key signing parties throughout the NANOG 35 meeting. I know Joe has his hands full with program and steering committee responsibilities and could use help from others to ensure keysignings go smoothly. If you'll be attending any part of the meeting, have a PGP key and are interested in exchanging signatures with other attendees the least you should do is add your public key to the keyring located on Biglumber: https://www.biglumber.com/x/web?keyring=9445 If you already have a login to biglumber then you probably know what to do, otherwise, just paste a copy of your public key in the text box and click the submit button. Look for keysignings during the last 15 minutes of morning and lunch breaks as was done in Seattle. For additional information, the NANOG 35 PGP keysigning page is here: http://www.nanog.org/pgp.abley.html Joe's Seattle meeting presentation detailing the NANOG process: http://www.nanog.org/mtg-0505/abley.trust.html I'm going to try to be one of the folks that attends most if not all the keysignings, but having others do so and ensuring a hard copy of the keyring is available for each would be great. John
Re: Level3 problems
I'm a reporter with InformationWeek magazine. I'm trying to get an idea of the significance of this morning's outage. Has Level 3 communicated with you about the cause of the outage? How greatly did the outage affect you or your customers? Was this an unusually large event? Thanks, [EMAIL PROTECTED]
RE: Level3 problems
Are you kidding? -gh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 21, 2005 11:03 AM To: nanog@merit.edu Subject: Re: Level3 problems I'm a reporter with InformationWeek magazine. I'm trying to get an idea of the significance of this morning's outage. Has Level 3 communicated with you about the cause of the outage? How greatly did the outage affect you or your customers? Was this an unusually large event? Thanks, [EMAIL PROTECTED]
Re: Level3 problems
This is a notification we just received regarding Level 3: Level 3 has resolved their internal issues. They were having some internal OSPF issues, but are going to send out an official RFO sometime this morning. For now Internap is turning up each BGP session with Level 3 out of the PNAPs and will be closely monitoring the situation. As soon as we get the official RFO from Level 3 we will forward it on to the customers. Hope that helps. Erik Koblence Nyi
RE: design of a real routing v. endpoint id seperation
We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home. that's the telco brittle network model, make it so it fails infrequently. this has met with varied success. the internet model is to expect and route around failure. randy
RE: design of a real routing v. endpoint id seperation
that's the telco brittle network model, make it so it fails infrequently. this has met with varied success. One way to look at it: the internet model is to expect and route around failure. this has also met with varied success. :-)
RE: multi homing pressure
If only I'd had the foresight to configure the all of the customers I've setup on BGP with Bogon filters, and more complex routing policies than defaults + provider customer routes, then I would have made mountains of recurring revenue from this maintenance, and I would be reading this thread in my mountain cabin with beleaguered amusement. Alas, I met the customers requirement, it has to just work... And it does. (and yes, on the network I administer at my day job, I bogon/rpf filter and aggressively traffic engineer.) -ejay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Radabaugh Sent: Wednesday, October 19, 2005 2:31 PM To: nanog@merit.edu Subject: Re: multi homing pressure John Payne wrote: Hrm, people keep saying that BGP is hard and takes time. As well as my end-user-facing network responsibilities, I also have corporate network responsibilities here. All of our corporate hub locations are multi-homed (or soon will be)... and I honestly can't remember the last time I made any changes (besides IOS upgrades) to BGP configs for the 2 hubs in the US. (We're moving physical locations in the international hubs and taking new providers, so I'm discounting those changes as you'd have similar changes in a single homed statically routed move). If you don't have multihoming requirements other than availability then it really can be fire and forget. Except for those pesky bogon filters which corporations seem to like to fire and forget. -- Mark Radabaugh Amplex [EMAIL PROTECTED] 419.837.5015
Re: design of a real routing v. endpoint id seperation
Neil J. McRae wrote: Considering that most people who are in favor of multihoming for ipv6 believe that there is customer demand for it, the market forces would decide this one. We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home. There is not only the multihoming issue but also the PI address issue. Even if any ISP would run his network very competently and there were no outages we would face the ISP switching issue. Again we would end up with either PI addresses announced by the ISP or BGP by the customer. With either the DFZ continues to grow. There is just no way around it. -- Andre
Re: FCC Outage Reports ..(.was Verizon outage in Southern California?)
Vicky Rode wrote: Thinking out loud. I guess some sort of trust model would help similar to what nsp-sec has in place (not sure its current state). It could be nice if there was some sort of a consensus among this consortium to distribute executive health metrics with the help of some secure trusted monitoring mechanism or maybe push model to a central database of some sort. Like to hear more thoughts as well. Here we see again that the secrecy (to prevent terrorism) of this information costs more than having it in the open as the FCC did in the past. The whole terrorism sham was just a convenient excuse to prevent outsiders from assessing the quality of the carriers network. Even if, which it does not, secrecy of this information would prevent any kind of external force terrorism we now have to suffer the terrorism from dishonest carriers and intransparent phone and bandwidth markets. One can only guess the cost shouldered by carriers customers because of unknown or deliberately wrong information. Guess how many procurements would have been made differently if true reliability and physical route information were available. Do I feel better that neither me nor the terrorist know that my redundant fiber routes are in the same dig? Or in the same cable even? We all know how reliable the carriers bonus driven sales droid promises are... -- Andre BTW: Often overlooked fact: Living is deadly.
RE: Level3 problems
Gary, I understand your statement, but I am sure the gentleman below does not. If you want a story to be done, so that the world can see how something like this can impact thousands of businesses, the best bet would be to help educate this guy so that he has something to write. Are, were you trying to scare him off from doing a story? Personally, I am quote fed up with the issues that the huge providers have and cause, yet never have anyone document it, find out about it, or do anything about it. I laud this guys effort for actually trying to do his job and expose something that needs to be exposed. I am now putting on my level-3 bullet proof jacket, and will be looking over my shoulder for the next 3 NANOGs. On Fri, 21 Oct 2005, Gary Hale wrote: Are you kidding? -gh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 21, 2005 11:03 AM To: nanog@merit.edu Subject: Re: Level3 problems I'm a reporter with InformationWeek magazine. I'm trying to get an idea of the significance of this morning's outage. Has Level 3 communicated with you about the cause of the outage? How greatly did the outage affect you or your customers? Was this an unusually large event? Thanks, [EMAIL PROTECTED] -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: FCC Outage Reports ..(.was Verizon outage in Southern California?)
On Fri, 21 Oct 2005, Andre Oppermann wrote: Here we see again that the secrecy (to prevent terrorism) of this information costs more than having it in the open as the FCC did in the past. The whole terrorism sham was just a convenient excuse to prevent outsiders from assessing the quality of the carriers network. In the field of security engineering, this is something called security through obscurity. Terrorists are well funded, and they, no doubt, can get hold on those 'secret' fiber maps if they have interest in them. Do I feel better that neither me nor the terrorist know that my redundant fiber routes are in the same dig? Or in the same cable even? We all know how reliable the carriers bonus driven sales droid promises are... Only ones suffering are us... -- juuso lehtinen
RE: design of a real routing v. endpoint id seperation
On Fri, 21 Oct 2005, Randy Bush wrote: the internet model is to expect and route around failure. randy That precludes agreement on a definition of failure. In recent weeks we have once again learned that a large fuzzy fringe around any sort of 100% consensus makes life interesting. For instance; was the withdrawal of certain routes from your BGP sessions a failure for you? Was it for superwebhostingforfree.com, who relies on a single provider for transit? matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 22 Oct, 2005 Analysis Summary BGP routing table entries examined: 172518 Prefixes after maximum aggregation: 98093 Unique aggregates announced to Internet: 83749 Total ASes present in the Internet Routing Table: 20734 Origin-only ASes present in the Internet Routing Table: 18027 Origin ASes announcing only one prefix:8543 Transit ASes present in the Internet Routing Table:2707 Transit-only ASes present in the Internet Routing Table: 75 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 21 Prefixes from unregistered ASNs in the Routing Table:26 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 10 Number of addresses announced to Internet: 1435243072 Equivalent to 85 /8s, 140 /16s and 18 /24s Percentage of available address space announced: 38.7 Percentage of allocated address space announced: 58.3 Percentage of available address space allocated: 66.4 Total number of prefixes smaller than registry allocations: 82326 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:35851 Total APNIC prefixes after maximum aggregation: 15747 Prefixes being announced from the APNIC address blocks: 33663 Unique aggregates announced from the APNIC address blocks:16681 APNIC Region origin ASes present in the Internet Routing Table:2388 APNIC Region origin ASes announcing only one prefix:693 APNIC Region transit ASes present in the Internet Routing Table:362 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 203929728 Equivalent to 12 /8s, 39 /16s and 184 /24s Percentage of available APNIC address space announced: 75.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 91650 Total ARIN prefixes after maximum aggregation:55548 Prefixes being announced from the ARIN address blocks:71720 Unique aggregates announced from the ARIN address blocks: 26944 ARIN Region origin ASes present in the Internet Routing Table:10276 ARIN Region origin ASes announcing only one prefix:3792 ARIN Region transit ASes present in the Internet Routing Table: 965 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 272820480 Equivalent to 16 /8s, 66 /16s and 233 /24s Percentage of available ARIN address space announced: 67.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 74/7, 76/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 33529 Total RIPE prefixes after maximum aggregation:22748 Prefixes being announced from the RIPE address blocks:30530 Unique aggregates announced from the RIPE address blocks: 20448 RIPE Region origin ASes present in the Internet Routing Table: 7220 RIPE Region origin ASes announcing only one prefix:3807 RIPE Region transit ASes present in the Internet Routing Table:1194 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to
And Verio too? (was Re: Level3 problems)
Authoritative sources report that Verio coincidentally had major problems last night also: http://www.boingboing.net/2005/10/21/two_tierone_isps_are.html http://slashdot.org/article.pl?sid=05/10/21/0958232 (is this the end for Level3? heh) Odd. The last time there was major instability due to multiple backbones upgrading was ... oh crap. So I'm going to get a major PSIRT upgrade now or die notice while I'm at NANOG. Good thing Monday evening is open... Pete. On Fri, 21 Oct 2005, Emilian Ursu wrote: I see its completely down and several others are starting to have problems. Anyone knows whats up ? Thanks
Peering BOF X Detailed Agenda
Hi all - I'm happy to announce the 10th NANOG Peering BOF will be held in Los Angeles from 14:00 to 15:30 on Monday. We have a *very* full Peering BOF agenda: 14:00 Introduction / Welcome - William B. Norton (Equinix) 14:05 Ad Hoc Transit Survey - all Since the Peering vs. Transit issue contains a financial component, we will employ an anonymous straw poll of wholesale transit prices and do a quick Peering Breakeven Point calculation by the end of the BOF. 14:10 Peeringdb.com - Richard Steenbergen (nLayer) The peeringdb attempts to solve two related Peering Coordinator Community problems - first, one of the most difficult problems is finding out who to talk to about peering in the target ISP company. Second, IXes have had a very difficult time populating and maintaining peering contact information for its populations. Richard has volunteered and set up a central database of peering contact information for the Peering Coordinator Community and he will share some stats and encourage folks to register their peering information. 14:15 Good Peers / Good Customers - Peter Cohen (Telia) Are all peers created equal? Should an ISP prefer some customers over others based on their traffic patterns? Peter will share some insights into these questions. 14:30 Unified Peering Forum - Josh Snowhorn (Terramark) Josh will share updates regarding the combined peering forum initiative, intended to reduce Peering Coordinator travel expenses and maximize the chances for peering coordinators to meet each other. In the last few years, the number of peering forums grew, and the Peering Coordinator Community attending these various forums to some degree fractured, reducing the benefits to the community. This initiative seeks to, among other things, pull together the community to fewer, open and jointly run forums. 14:40 The Great Debate on Peering Ratios : Important Metric or Dinosaur PreReq of a Bygone Era - Peter Cohen vs. Richard Steenbergen One challenge the Peering Coordinator Community faces (besides making contact and working within financial constraints discussed earlier) is meeting the peering requirements of the large traffic potential peers. There are some peers that believe peering ratios help them scrutinize where to most fairly expend their engineering resources, and ratios are one way to determine the balance of benefits between the potential peers. The other view is that there is no valid technical reason to use ratios are a filter for potential peers. A: Opening Statement - Peering Ratios are a valuable metric B: Opening Statement - Peering Ratios have no technical merit for screening potential peers A: Attack B / Defend A position B: Attack A / Defend B position A: Closing Statement B: Closing Statement Audience Vote: Which side made the more compelling case? Audience Engages Debaters: A chance for the audience to ask questions and make points NOT made during the debate, or to help reinforce points not made strongly enough during the debate. Secondary Audience Vote - did the audience view change? With the advantage of the audience points and followup discussion, which side made the more compelling case? 15:20 Peering Personals - all We have a few minutes for those who travelled a great distance to introduce themselves to the Peering Coordinator Community as we break for coffee and cookies. If you would like to introduce yourself to the Peering Coordinator Community, please send a note to [EMAIL PROTECTED] BEFORE MONDAY including: Name: email: Company: AS#: Three things the Peering Coordinator Community should know about peering with you: 1) 2) 3) These three things will help me select who gets stage time in case there are more people than time, and please make sure you speak with me before the BOF so we can seat you up front in the interests of time.
[Fwd: Re: FCC Outage Reports ..(.was Verizon outage in Southern California?)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just taking a quick poll to see if nanog community would consider this a worthwhile effort to pursue? regards, /virendra - Original Message Subject: Re: FCC Outage Reports ..(.was Verizon outage in Southern California?) Date: Fri, 21 Oct 2005 21:26:51 +0300 (EEST) From: Juuso Lehtinen [EMAIL PROTECTED] To: nanog@merit.edu References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On Fri, 21 Oct 2005, Andre Oppermann wrote: Here we see again that the secrecy (to prevent terrorism) of this information costs more than having it in the open as the FCC did in the past. The whole terrorism sham was just a convenient excuse to prevent outsiders from assessing the quality of the carriers network. In the field of security engineering, this is something called security through obscurity. Terrorists are well funded, and they, no doubt, can get hold on those 'secret' fiber maps if they have interest in them. Do I feel better that neither me nor the terrorist know that my redundant fiber routes are in the same dig? Or in the same cable even? We all know how reliable the carriers bonus driven sales droid promises are... Only ones suffering are us... - -- juuso lehtinen -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDWUsYpbZvCIJx1bcRAh2IAJsGJqCMtsuyMjYSDJFhCjzI07GBKwCfW7aG uPBNNwW0I75xGyKP1Tlg9iw= =l5Jg -END PGP SIGNATURE-
Re: design of a real routing v. endpoint id seperation
the internet model is to expect and route around failure. You cannot stop the last mile backhoes. Tony
Re: And Verio too? (was Re: Level3 problems)
[EMAIL PROTECTED] (Pete Kruckenberg) writes: Authoritative sources report that Verio coincidentally had major problems last night also: we (isc) saw level(3) go away and come back. verio's been normal here though. -- Paul Vixie
Microwave link security.
Fellow NANOGers, Please, do you know any documents and/or links about securing data microwave links? I am writing a project for MAN interconnection of several buildings with MW radios and concerned about possible security threats. TIA, Marlon Borba, CISSP.
Re: And Verio too? (was Re: Level3 problems)
On Fri, Oct 21, 2005 at 01:30:05PM -0600, Pete Kruckenberg wrote: Authoritative sources report that Verio coincidentally had major problems last night also: http://www.boingboing.net/2005/10/21/two_tierone_isps_are.html http://slashdot.org/article.pl?sid=05/10/21/0958232 (is this the end for Level3? heh) Odd. The last time there was major instability due to multiple backbones upgrading was ... oh crap. So I'm going to get a major PSIRT upgrade now or die notice while I'm at NANOG. Good thing Monday evening is open... The Verio part seems to be an observational anormaly caused by the frame of reference of the observer. -dorian
IANA Blackhole Servers Ill?
We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: design of a real routing v. endpoint id seperation
There is not only the multihoming issue but also the PI address issue. Even if any ISP would run his network very competently and there were no outages we would face the ISP switching issue. Again we would end up with either PI addresses announced by the ISP or BGP by the customer. With either the DFZ continues to grow. There is just no way around it. The way around it is to stop growing the DFZ routing table by the size of the Prefixes. If customers could have PI addreses and the DFZ routing table was based, instead, on ASNs in such a way that customers could use their upstream's ASNs and not need their own, then, provider switch would be a change to the PI-ASN mapping and not affect the DFZ table at all. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpAxFfvw49rq.pgp Description: PGP signature
Re: IANA Blackhole Servers Ill?
To me they do answer: ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-1.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20469 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 113 msec ;; SERVER: 192.175.48.6#53(blackhole-1.iana.org.) ;; WHEN: Fri Oct 21 23:15:39 2005 ;; MSG SIZE rcvd: 162 ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-2.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43116 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 112 msec ;; SERVER: 192.175.48.42#53(blackhole-2.iana.org.) ;; WHEN: Fri Oct 21 23:15:49 2005 ;; MSG SIZE rcvd: 162 Regards, Peter and Karin Dambier Crist Clark wrote: We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
RE: IANA Blackhole Servers Ill?
It is probably important to know that those servers are anycasted via the AS112 project (www.as112.net). Perhaps the AS112 operator you are seeing is having issues. You could try to identify which one and let them know. Thanks, John :) -Ursprüngliche Nachricht- Von: Peter Dambier [mailto:[EMAIL PROTECTED] Gesendet: Friday, October 21, 2005 2:20 PM An: [EMAIL PROTECTED] Cc: nanog Betreff: Re: IANA Blackhole Servers Ill? To me they do answer: ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-1.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20469 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 113 msec ;; SERVER: 192.175.48.6#53(blackhole-1.iana.org.) ;; WHEN: Fri Oct 21 23:15:39 2005 ;; MSG SIZE rcvd: 162 ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-2.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43116 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 112 msec ;; SERVER: 192.175.48.42#53(blackhole-2.iana.org.) ;; WHEN: Fri Oct 21 23:15:49 2005 ;; MSG SIZE rcvd: 162 Regards, Peter and Karin Dambier Crist Clark wrote: We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: IANA Blackhole Servers Ill?
John van Oppen wrote: It is probably important to know that those servers are anycasted via the AS112 project (www.as112.net). Perhaps the AS112 operator you are seeing is having issues. You could try to identify which one and let them know. Three things: 1) At least one other person reports the same problem. 2) They've been going up and down, so even if you go check and it works that one time, you may have caught it up. 3) I'd try to ask it which anycast instance it is, but both are sending ICMP unreachables at the moment. A traceroute says, traceroute to 192.175.48.42 (192.175.48.42), 64 hops max, 44 byte packets [snip] 6 p4-3-0.RAR2.SanJose-CA.us.xo.net (65.106.5.161) 34.390 ms 5.774 ms 5.280 ms 7 p1-0.IR1.PaloAlto-CA.us.xo.net (65.106.5.178) 44.123 ms 21.508 ms 5.672 ms 8 207.88.240.70.ptr.us.xo.net (207.88.240.70) 5.473 ms 26.629 ms 14.045 ms 9 ix-4-6.core3.PDI-PaloAlto.Teleglobe.net (207.45.196.66) 6.637 ms 10.697 ms 5.863 ms 10 blackhole-2.iana.org (192.175.48.42) 6.547 ms 6.561 ms 8.935 ms I don't have a BGP view of the world from XO, our provider on this link. Anyone know which instance that is? It's close to Palo Alto? From, http://public.as112.net/node/2 My best guess is ISC? But F-Root seems to be OK from here, FWIW, and a traceroute to F doesn't jump through that IX. -Ursprüngliche Nachricht- Von: Peter Dambier [mailto:[EMAIL PROTECTED] Gesendet: Friday, October 21, 2005 2:20 PM An: [EMAIL PROTECTED] Cc: nanog Betreff: Re: IANA Blackhole Servers Ill? To me they do answer: ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-1.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20469 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 113 msec ;; SERVER: 192.175.48.6#53(blackhole-1.iana.org.) ;; WHEN: Fri Oct 21 23:15:39 2005 ;; MSG SIZE rcvd: 162 ; DiG 9.1.3 -t any 10.in-addr.arpa. @blackhole-2.iana.org. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43116 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.in-addr.arpa. IN ANY ;; ANSWER SECTION: 10.in-addr.arpa.604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org.\ 2002040800 1800 900 604800 604800 10.in-addr.arpa.604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa.604800 IN NS blackhole-2.iana.org. ;; Query time: 112 msec ;; SERVER: 192.175.48.42#53(blackhole-2.iana.org.) ;; WHEN: Fri Oct 21 23:15:49 2005 ;; MSG SIZE rcvd: 162 Regards, Peter and Karin Dambier Crist Clark wrote: We got some very weird compaints about applications hanging. Tracked it down to reverse lookups timing out. Reverse lookups to RFC1918 space. Looks like the IANA blackhole servers for RFC1918 are not well? 1 0.0 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 2 0.01375 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 3 0.68455 207.88.152.10 - 192.175.48.6 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 4 0.00529 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 5 3.00417 207.88.152.10 - 192.175.48.42 DNS C 111.143.18.172.in-addr.arpa. Internet PTR ? 6 0.00548 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 7 0.68462 207.88.152.10 - 192.175.48.42 DNS C 69.160.18.172.in-addr.arpa. Internet PTR ? 8 0.00623 192.175.48.42 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) 9 0.60348 207.88.152.10 - 192.175.48.6 DNS C 52.143.18.172.in-addr.arpa. Internet PTR ? 10 0.00523 192.175.48.6 - 207.88.152.10 ICMP Destination unreachable (UDP port 53 unreachable) Looks like the hosts are up but not listening on 53/udp? Anyone else seeing this? Heard about it? (Of course, the fix is to claim authority for the RFC1918 space you are using in your own DNS servers.) -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review,
Re: IANA Blackhole Servers Ill?
Crist Clark wrote:
We got some very weird compaints about applications hanging. Tracked
it down to reverse lookups timing out. Reverse lookups to RFC1918 space.
Looks like the IANA blackhole servers for RFC1918 are not well?
From my location (Comcast cable modem in LA) I can see the IANA servers, and
they are answering queries.
(Of course, the fix is to claim authority for the RFC1918 space you are
using in your own DNS servers.)
It's arguably a good idea for resolving name servers to be authoritative for
all the 1918 space, as well as the zones recommended in RFC 1912
(ftp://ftp.rfc-editor.org/in-notes/rfc1912.txt). You can set up an empty
zone file (just SOA and NS), and do something like this:
zone 10.in-addr.arpa { type master; file master/empty.db; };
zone 16.172.in-addr.arpa { type master; file master/empty.db; };
zone 17.172.in-addr.arpa { type master; file master/empty.db; };
zone 18.172.in-addr.arpa { type master; file master/empty.db; };
zone 19.172.in-addr.arpa { type master; file master/empty.db; };
zone 20.172.in-addr.arpa { type master; file master/empty.db; };
zone 21.172.in-addr.arpa { type master; file master/empty.db; };
zone 22.172.in-addr.arpa { type master; file master/empty.db; };
zone 23.172.in-addr.arpa { type master; file master/empty.db; };
zone 24.172.in-addr.arpa { type master; file master/empty.db; };
zone 25.172.in-addr.arpa { type master; file master/empty.db; };
zone 26.172.in-addr.arpa { type master; file master/empty.db; };
zone 27.172.in-addr.arpa { type master; file master/empty.db; };
zone 28.172.in-addr.arpa { type master; file master/empty.db; };
zone 29.172.in-addr.arpa { type master; file master/empty.db; };
zone 30.172.in-addr.arpa { type master; file master/empty.db; };
zone 31.172.in-addr.arpa { type master; file master/empty.db; };
zone 168.192.in-addr.arpa { type master; file master/empty.db; };
Any more specific zones that you add for space that you're actually using
will be effective for those blocks instead of the more generic definitions
(at least in modern versions of BIND).
hth,
Doug
RE: design of a real routing v. endpoint id seperation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Neil! On Fri, 21 Oct 2005, Neil J. McRae wrote: If we all ran networks that worked as well as our customers demand... Some demand low price and some demand high availability. No way to please everyone. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDWWiP8KZibdeR3qURAlxDAKCnE8uNK36GKu5wHeuFtR9bID3LMwCeNMV5 Hrp1sFipFeyg4or0SHDv5bE= =KdkD -END PGP SIGNATURE-
Re: IANA Blackhole Servers Ill?
On Fri, 21 Oct 2005, Crist Clark wrote: 2) They've been going up and down, so even if you go check and it works that one time, you may have caught it up. Something's definitely going on, as the server at ISC seems to be coming and going in operation. 3) I'd try to ask it which anycast instance it is, but both are sending ICMP unreachables at the moment. A traceroute says, Always can be gleaned from this: dig @prisoner.iana.org hostname.as112.net any Which, from my local ISP's point of view (Sympatico in Canada) seems to yield different answers. wfms
Re: IANA Blackhole Servers Ill?
Looks like it was ISC? And they withdrewn their routes for a bit? For a while I got (from XO in CA), $ host -t txt -c chaos hostname.bind 192.175.48.6 Using domain server 192.175.48.6: hostname.bind CHAOS descriptive text black-1.sth.netnod.se Goin' transatlantic! Traceroutes seemed to verify. But now I'm back on, $ host -t txt -c chaos hostname.bind 192.175.48.6 Using domain server 192.175.48.6: hostname.bind CHAOS descriptive text hazel.isc.org ISC. Got a note from an ISC reader verifying they are/were having issues with their AS112 server. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Microwave link security.
On Friday 21 October 2005 03:12 pm, MARLON BORBA wrote: Please, do you know any documents and/or links about securing data microwave links? I am writing a project for MAN interconnection of several buildings with MW radios and concerned about possible security threats. Depends on many things, such as Frequency, emission, aperture, and any link scrambling. Bottom line unless it's standards compliant radio your using there is little chance of someone decoding it. If you want to be totally secure encrypt the traffic before it hits the radio. -- Bryan Fields Chief RF Engineer/Partner illiana.net 219-306-1805
