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 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: 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 loopi
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: 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)
Level3 problems
I see its completely down and several others are starting to have problems. Anyone knows whats up ? Thanks
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
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
The ORIGIN option on BGP - what is it for?
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: FCC Outage Reports ..(.was Verizon outage in Southern California?)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
regards,
/virendra
Wallace Keith wrote:
> I wasn't thinking in terms of automatic monitoring, that would open up
> a can of worms security wise.
> Just looking at some way of getting the manual reporting (that is still
> taking place to the FCC) back in the (semi?)public domain. Due to
> terrorism concerns, that information is no longer available online. I'm
> pretty sure the LEC's and IXC's like it that way also, as they no longer
> have to air their dirty laundry. I was able to get some information
> under the Freedom of Information act for an outage that affected me
> directly , but that takes days or weeks. As close to real-time
> information as possible is what's needed to assess and respond to a
> major outage, i.e. routing voice/data via different carriers, being able
> to explain to end users why their email or phone calls didn't go through
> , etc. and eliminating the need to open tons of trouble tickets during a
> major event. One master ticket - such as fiber cut affect xxx OC48's
> would suffice.
> Not sure how this can be balanced against DHS perceived needs
> though...any suggestions?
>
> -Original Message-
> From: Vicky Rode [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 19, 2005 5:45 PM
> To: Wallace Keith
> Subject: Re: Verizon outage in Southern California?
>
> I wonder how would Telcos, ISPs and GOV agencies feel about a third
> party polling their devices, not to mention security.
>
>
> I think netcarft comes close to what you're suggesting.
>
>
> regards,
> /virendra
>
>
>
> Wallace Keith wrote:
>
>>>All this speculation!!
>>>Remember the good old days when you could see faxes of FCC outage
>>>reports online?
>>>Was sure nice to know what was going on, before the FCC took these
>>>offline (due to DHS?) It would really by nice to have some sort of an
>>>online clearing house, and gain some visibility again into overall
>>>network status. This will become even more important as things
>>>continue to converge. DACS and DC Power failures tend to affect
>>>multiple services and in the case of power, multiple carriers that
>>>are colo'd in the CO.
>>>-Keith
>>>
>>>-Original Message-
>>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>>>Of Vicky Rode
>>>Sent: Wednesday, October 19, 2005 1:29 PM
>>>To: [EMAIL PROTECTED]
>>>Cc: nanog list
>>>Subject: Re: Verizon outage in Southern California?
>>>
>>>
>>>I wonder what ever happened to redundancy? I guess 5 9s (dunno what
>>>the going number is) got blown out of the water for them.
>>>
>>>
>>>
>>>regards,
>>>/virendra
>>>
>>>David Lesher wrote:
>>>
>>>
>Speaking on Deep Background, the Press Secretary whispered:
>
>
>
>>I'm not completely familiar with the telco jargon.
>>Does Tandem mean the same as a local central office, where POTS
>>lines terminate at the switch? Long Beach has a population of
>>470,000. The C/Os I know of are:
>
>
>
>A "Central Office" switch talks to subscribers aka end-users.
>On its backside, it talks to other CO's and tandems. Time was, that
>was also VF copper pairs, but it's long since all
>DS1 and up.
>
>A tandem is a switch that talks not to subs, but only to CO's. In
>days
>>>
>>>
>of old, when a {dialup} call went to the other side of town, chances
>are it went you-yourCO-downtown tandem-joesCO-joe. {copper all the
>way...}.
>
>A tandem was always housed in large CO building, but might have been
>ATT's vice the operationg company, etc...
>
>But ESS's and ""classless switching"" and massive expansion of the
>plant really muddled the picture. An ESS could be both a CO switch
>[for multiple prefixes and even multiple NPA's..] AND act like a
>tandem.. And oh, the actual "line cards" can be remoted 100 miles
>away
>>>
>>>
>in a horz. phonebooth box alongside the road in Smallville
>with DS1's/OC coming back.
>
>My guess is a DACS, a cross-connect point that is an software-driven
>patch panel, lost its marbles. [engineering term of art.] A DACS
>could have dozen->MANY dozen DS1/DS3/OC-n going hither and yon. Some
>will be leased circuits. Others will be the CO trunks going from one
>switch to another. It may/may not have muxes internal, so that what
>arrives on a DS1 leaves in a OC96..
>
>I note it went down at 2:20 AM. That SCREAMS software
>
> upgrade/cutover.
>
>>>
>What's to bet GEE, no...VZEEE, was doing just that and the
Re: /24 multihoming issue
On Oct 20, 2005, at 2:07 PM, Randy Bush wrote: Is 7018 preferring 19094 over 701 regardless of AS-PATH length? the convention is that, if 19094 is a customer of 7018, then it will always prefer it. and it was confirmed that this is the case for the prefix in question And this is a good reason not to cross "tiers" of your transit providers. Either have both "transit free" or both should have transit. why? when it get up to tier-1s it will be the same, the one(s) who heard it from customers will prefer the customers. and tier-Ns should be preferring customer routes as well; see discussion here between vaf, asp, and me in about '96. slipping back into the tier terminology which i was trying to avoid... it's only a problem if you want to do inbound traffic engineering. If the tier 2 is well connected to tier 1s (for example Internap), it's typically going to get more inbound traffic than the tier 1 connection because the tier 2 is preferred as a customer in a bunch of tier 1s.
Re: LACNIC to start allocating from 189/8 and 190/8
psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes 64 bytes from 189.0.0.1: icmp_seq=0 ttl=54 time=220.296 ms 64 bytes from 189.0.0.1: icmp_seq=1 ttl=54 time=219.952 ms 64 bytes from 189.0.0.1: icmp_seq=2 ttl=54 time=220.057 ms 64 bytes from 189.0.0.1: icmp_seq=3 ttl=54 time=220.221 ms 64 bytes from 189.0.0.1: icmp_seq=4 ttl=54 time=221.513 ms --- 189.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 219.952/220.408/221.513/0.566 ms PING 189.128.0.1 (189.128.0.1): 56 data bytes 64 bytes from 189.128.0.1: icmp_seq=0 ttl=54 time=222.030 ms 64 bytes from 189.128.0.1: icmp_seq=1 ttl=54 time=221.872 ms 64 bytes from 189.128.0.1: icmp_seq=2 ttl=54 time=222.107 ms 64 bytes from 189.128.0.1: icmp_seq=3 ttl=54 time=222.094 ms 64 bytes from 189.128.0.1: icmp_seq=4 ttl=54 time=221.575 ms --- 189.128.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 221.575/221.936/222.107/0.199 ms PING 190.0.0.1 (190.0.0.1): 56 data bytes 64 bytes from 190.0.0.1: icmp_seq=0 ttl=54 time=218.843 ms 64 bytes from 190.0.0.1: icmp_seq=1 ttl=54 time=218.311 ms 64 bytes from 190.0.0.1: icmp_seq=2 ttl=54 time=217.911 ms 64 bytes from 190.0.0.1: icmp_seq=3 ttl=54 time=217.902 ms 64 bytes from 190.0.0.1: icmp_seq=4 ttl=54 time=218.001 ms --- 190.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 217.902/218.194/218.843/0.357 ms PING 190.128.0.1 (190.128.0.1): 56 data bytes 64 bytes from 190.128.0.1: icmp_seq=0 ttl=54 time=218.329 ms 64 bytes from 190.128.0.1: icmp_seq=1 ttl=54 time=221.990 ms 64 bytes from 190.128.0.1: icmp_seq=2 ttl=54 time=218.104 ms 64 bytes from 190.128.0.1: icmp_seq=3 ttl=54 time=218.576 ms 64 bytes from 190.128.0.1: icmp_seq=4 ttl=54 time=218.106 ms --- 190.128.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 218.104/219.021/221.990/1.495 ms i think the lesson here, as it was from last month's test by cymru, is that it would be good if folk tested that it worked before announcing. randy
Re: multi homing pressure
[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. > 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... > [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...) > > 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 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. > 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. > 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. > 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 the packet. Yes, but you lose the benefit of multihoming, because the rewriting edge router may carry outdated information or simply make a "bad" choice. I'd rather have routing intelligence in the core than in the edge. > > If B is multihomed, I am not in favour of A (or X) selecting the > > location of B to be used. I believe the routing system should > > be able to determine that, like it's done right now. > > > Look... The first DFZ router selects the location of B to be > used in todays world, why should this change? I am not sure why you believe that the firsts DFZ router that is being traversed does the choice today. In paths like (from source to multihomed-target): A B C D T A B E F T 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. > > + Prefixes (ESI) have gone from the routing process > That's a GOOD thing. Yup. Longest match sucks. > > + Customers are hidden behind their ISPs > I'm not sure what you mean by that. Neither customer Z's ESI nor RLI (they don't need one) are visible in the core. Only their ISPs' RLIs are visible. > No... This scheme needs DFZ routers to do the lookup. This is > going to require significant changes to RFCs for full implementation > anyway, and, no, the whole point of my proposal is for routers NOT > to have to carry full lookup information, so, it is my intent > to modify that requirement. If I understand the idea correctly, you have to distribute two types of wide-area routing information: One ESI-based and one RLI-based. This is because any DFZ box max or may not be able to RLI-route and/or, if it sees that that's not been done yet, perform the translation. Of course, not every DFZ router needs both those tables, but there are some that do. Oh, and you do of course have to distribute the mapping info. > > But at least it differentiates between DFZ (aka Internet Core) > > routing a
Re: LACNIC to start allocating from 189/8 and 190/8
Hi, There was some packet filters based on ip destination/source address in between the machines. It should be all working now. Thanks for all feedbacks. Ricardo Patara -- L A C N I C On Thu, Oct 20, 2005 at 09:29:49AM -0200, Ricardo Patara wrote: | | Hello, | Commenting myself, there is an machine in the first address of | each the announced blocks. Just in the case someone want to | ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) | I forgot to mention this before. | | Ricardo Patara | -- | L A C N I C | | On Tue, Oct 18, 2005 at 03:02:24PM -0200, Ricardo Patara wrote: | | | | 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 | | | | | |
Re: Are ISP's responsible for worms and viruses
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. > Owen Frem.
Re: design of a real routing v. endpoint id seperation
Owen DeLong wrote: A customer with a prefix assigned from this chunk has to connect with an ISP who has * a Very Large Multihoming (to handle scaling concerns) router somewhere in its network that peers to other ISP Very Large Multihoming routers. ISP operating a VLMrouter to offer multihoming service to their customers would originate the entire multihoming space prefix to their customers AND to all their peers. These would have ALL the prefixes from the Multihoming Space. So... Let me get this straight. You think that significantly changing the economic model of every ISP on the planet (or at least every large ISP on the planet) is easier than changing the code in every core router? ROTFLMAO Owen 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 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. If you are referring to the affect that this will attract "unwanted" traffic, that would be considered a COB. 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.
RE: multi homing pressure
--On October 20, 2005 2:31:39 PM -0400 "Howard, W. Lee"
<[EMAIL PROTECTED]> 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.
pgp3f9imInEpi.pgp
Description: PGP signature
Re: Are ISP's responsible for worms and viruses
> Mind you, it would help if some of the anti-abuse groups > would band together under some umbrella organization that > ISPs could join. Botnet researchers, SPAM fighters, etc. > That way there could be some sort of good housekeeping > seal of approval that ISPs can use to competitive advantage > in the marketplace. At that point, money starts to talk > and there is an economic incentive to clean up your act > and get that "seal". What would help more would be if people realized that worms and viruses aren't like crack, they're more like biological WMD. As such, it is unlikely to be a productive solution holding the city where the WMD are being delivered liable. That becomes a game of legal whack-a-mole. What is needed, instead, is to hold the companies selling the technology used to build these WMD liable. 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. Why do we have seat belts in every car manufactured today? Because auto makers started getting held responsible for injuries caused by the failure to install them. As much as I think product liability law, especially in the US, has become insane, the software industry (where it so far hasn't really been applied) is one area SCREAMING for this to happen. Eliminate (or even significantly reduce) the number of systems being sold with virus friendly toolkits and features enabled by default, and, you will go a long way towards reducing the spam and virus/worm problem. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpMnKsma8KeI.pgp Description: PGP signature
Re: LACNIC to start allocating from 189/8 and 190/8
Same here from multiple networks on the west coast & some on the east. See the routes in the table though. -- Bill Sehmel - [EMAIL PROTECTED] -- 1-206-242-2743 Systems Support, HopOne Internet Corp. SEA2 NOC Bandwidth & full range of carrier/web host colo + networking services: http://www.hopone.net
Re: LACNIC to start allocating from 189/8 and 190/8
My results match Randy's. I looked at these blocks from several networks (ATT, Cogent, PSI, XO, Comcast). All have the routes showing. ICMP Echo packets do not come back via any of them. Either the machines aren't listening, the echos are being blocked, or there's widespread blockage. Traces appear to make it to Brazil before dying in all cases, pointing at an issue closer to where your test machines are located. At 01:24 PM 10/20/2005, Randy Bush wrote: > Commenting myself, there is an machine in the first address of > each the announced blocks. Just in the case someone want to > ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) > I forgot to mention this before. from a quite competent dsl provider in hawai`i roam.psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss from a machine dual-homed to to major tier-1s in seattle psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss and they are in the routing tables randy
Re: multi homing pressure
> Rewriting would IMHO not work easily, but encapsulation would. > Admittedly, this idea has occurred and lead to MPLS > implementations (which are weak at interconnecting ISPs anyway). > Why wouldn't rewriting work? The "encapsulation" you show below is little different from the rewrite I propose. First, let's start with something that looks a little more like an IPv6 datagram: [Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]] Now, let's look at what the first DFZ router would do to the packet: [RLI: Z Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]] or [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: ...]]] So... Nobody outside the DFZ needs to change anything, all the checksums and such at hosts that should check them still work, and, even IPSec packet tampering would not detect this since the 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. > Well, let's see what else we can do, that MPLS maybe cannot. > Perhaps become ubiquitous implementation in the DFZ? > If the end user does not determine the RLI themselves, but > their ISP does (on edge routers), it looks like this: > 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. > A is the customer, Internet access provided by X > B is the customer of Z > Y is an intermediate system > > A -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> X > X -> Add envelope -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] > X -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> Y > Y -> [RLI: Z [something]] -> Z > Z -> Remove envelope -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] > Z -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> B > > Routing decision is thus made by looking up paths for Z. > Multihoming works the same, but we get multiple RLIs in the packet. > 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. If you start playing with changing RLI along the way, then, you run into serious difficulty with looping possibilities. 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 the packet. > If B is multihomed, I am not in favour of A (or X) selecting the > location of B to be used. I believe the routing system should > be able to determine that, like it's done right now. > Look... The first DFZ router selects the location of B to be used in todays world, why should this change? > We have some major points here, and one possible ballbreaker: > > + Prefixes (ESI) have gone from the routing process That's a GOOD thing. > + Customers are hidden behind their ISPs I'm not sure what you mean by that. > + Packets carry their routing information (instead of ESI info) No. Under my proposal, packets carry both RLI and ESI information, but, in separate fields. > + Packets may as well be deeply inspected, if necessary > That already happens, but, it is not necessary under my proposal. > - Edge routers need to be extremely powerful, because they > have to determine all the ESI <-> RLI information > Nope. DFZ routers (which already need to be extremely powerful) need to be able to perform lookups for ESI->RLI (one way, btw) mapping. This could be accomplished by a protocol similar to DNS, but, more secure and authenticated. Trading a lookup at first sight of destination prefix, then cache against trying to manage a 32 bit routing table (4 billion routes?) is likely a scalability win. Even if it's just 1 million routes, I think it is a win. > Ballbreaker (shared with Owen's idea): > - This scheme needs the ISPs' edge routers to do the looking > up, and if we do not find a way to incorporate updating > the lookup table into part of the routing system, we are > in violation of Par. 2.1.20 of draft-irtf-routing-reqs-03.txt, > which is a very sensible requirement IMHO. > No... This scheme needs DFZ routers to do the lookup. This is going to require significant changes to RFCs for full implementation anyway, and, no, the whole point of my proposal is for routers NOT to have to carry full lookup information, so, it is my intent to modify that requ
Re: design of a real routing v. endpoint id seperation
> A customer with a prefix assigned from this chunk has to connect with an > ISP who has > > * a Very Large Multihoming (to handle scaling concerns) router somewhere > in its network that peers to other ISP Very Large Multihoming routers. > > ISP operating a VLMrouter to offer multihoming service to their > customers would originate the entire multihoming space prefix to their > customers AND to all their peers. > > These would have ALL the prefixes from the Multihoming Space. > So... Let me get this straight. You think that significantly changing the economic model of every ISP on the planet (or at least every large ISP on the planet) is easier than changing the code in every core router? ROTFLMAO Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpBRESUz7vDv.pgp Description: PGP signature
Re: multi homing pressure
On Oct 20, 2005, at 5:37 AM, [EMAIL PROTECTED] wrote:
http://nms.lcs.mit.edu/ron/ronweb/#code
(Part of my thesis work,
Hehe, google for "vixie ifdefault".
Paul's use of Squid is mentioned in this NANOG
posting:
http://www.cctec.com/maillists/nanog/historical/9702/msg00431.html
Here are the notes from the SF NANOG presentation:
http://www.academ.com/nanog/feb1997/multihoming.html
Right. Though the details are very sparse, this is stock Squid
running in accelerator mode. The solution I described is quite
different (for one, it's normal-mode squid for _outbound_ requests,
and second, it actually probes the links to see if they're working).
A commercial solution that looks a lot more like the stuff we built
are products by Stonesoft ("Multi-Link Technology") and Fatpipe
("Redundant Array of Independent Lines"). RadWare's "LinkProof" has
a similar style, though the actual technique they use is more link-
centric instead of path-centric.
-Dave
Re: /24 multihoming issue
>>> Is 7018 preferring 19094 over 701 regardless of >>> AS-PATH length? >> the convention is that, if 19094 is a customer of >> 7018, then it will always prefer it. and it was confirmed that this is the case for the prefix in question > And this is a good reason not to cross "tiers" of your > transit providers. Either have both "transit free" or > both should have transit. why? when it get up to tier-1s it will be the same, the one(s) who heard it from customers will prefer the customers. and tier-Ns should be preferring customer routes as well; see discussion here between vaf, asp, and me in about '96. randy
Re: /24 multihoming issue
On Oct 20, 2005, at 3:51 AM, Randy Bush wrote: Is 7018 preferring 19094 over 701 regardless of AS-PATH length? the convention is that, if 19094 is a customer of 7018, then it will always prefer it. And this is a good reason not to cross "tiers" of your transit providers. Either have both "transit free" or both should have transit.
Re: LACNIC to start allocating from 189/8 and 190/8
Same from here. I get to brasil telecom then nothing. Routes are in the table... Chris Randy Bush wrote: Commenting myself, there is an machine in the first address of each the announced blocks. Just in the case someone want to ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) I forgot to mention this before. from a quite competent dsl provider in hawai`i roam.psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss from a machine dual-homed to to major tier-1s in seattle psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss and they are in the routing tables randy -- Chris Griffin[EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 392-2061 Network Services / Florida LambdaRailFax: (352) 392-9440 University of FloridaGainesville, FL 32611
RE: /24 multihoming issue
Hi. How long did you wait to see your block come back during testing? I've seen it take > 60 seconds in some cases. For redundancy with non PI IP space, It's generally only important that the ISP you are getting the IP block from can see both routes, and that it sees it at the same level of localpref. (as path differences are okay, as long as they are consistent.) Since the isp providing the ip space will announce an aggregate larger than your block, you should be reachable as long as they can see both routes to you. -e > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Kyaw Khine > Sent: Wednesday, October 19, 2005 11:39 PM > To: nanog@merit.edu > Subject: /24 multihoming issue > > > 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
Re: LACNIC to start allocating from 189/8 and 190/8
Sprint's not playing nice. All of my upstreams appear to dump it to sprint at some point and I get: 10 sl-bb22-orl-14-0.sprintlink.net (144.232.19.130) [AS 1239] 64 msec 68 msec 72 msec 11 sl-st20-mia-14-0.sprintlink.net (144.232.8.56) [AS 1239] 84 msec 84 msec 84 msec 12 sl-brazi-1-0.sprintlink.net (144.223.244.26) [AS 1239] 188 msec 188 msec 188 msec 13 * * * Ricardo Patara wrote: Hello, Commenting myself, there is an machine in the first address of each the announced blocks. Just in the case someone want to ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) I forgot to mention this before. Ricardo Patara
Re: LACNIC to start allocating from 189/8 and 190/8
> Commenting myself, there is an machine in the first address of > each the announced blocks. Just in the case someone want to > ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) > I forgot to mention this before. from a quite competent dsl provider in hawai`i roam.psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss from a machine dual-homed to to major tier-1s in seattle psg.com:/usr/home/randy> for i in 189.0.0.1 189.128.0.1 190.0.0.1 190.128.0.1; do ping -c 5 $i; done PING 189.0.0.1 (189.0.0.1): 56 data bytes --- 189.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 189.128.0.1 (189.128.0.1): 56 data bytes --- 189.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.0.0.1 (190.0.0.1): 56 data bytes --- 190.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss PING 190.128.0.1 (190.128.0.1): 56 data bytes --- 190.128.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss and they are in the routing tables randy
Re: Are ISP's responsible for worms and viruses
On 10/20/05, [EMAIL PROTECTED] wrote: > Mind you, it would help if some of the anti-abuse groups > would band together under some umbrella organization that > ISPs could join. Botnet researchers, SPAM fighters, etc. The Messaging Anti-Abuse Working Group (MAAWG) and the Anti-Phishing Working Group (APWG) are conducting a joint meeting in Montreal next month, largely focusing on phishing and zombies. http://www.maawg.org/ -- you don't have to be a member of either organization to attend the main sessions. -- J.D. Falk a decade of cybernothing.org <[EMAIL PROTECTED]> registered 24 June 1995
Re: Are ISP's responsible for worms and viruses
> RSA Europe 2005 ISPs must be made liable for viruses and other bad > network traffic, Bruce Schneier, security guru and founder and CTO of > Counterpane Internet Security, told The Register yesterday. Are local town councils responsible for crack dealers and crack users when that activity takes place within the bounds of the town? In some countries, the answer is yes. http://www.brent.gov.uk/www.nsf/0/19fbe6f14c0f0a8f80256ee600411b1c?OpenDocument To summarize: Brent is one of the boroughs that forms the English city formerly known as Greater London. Like most town councils in the UK, they own housing developments that provide homes for those unable to afford their own place to live, i.e. welfare housing. Even though there was not enough evidence to convict the powerful drug dealers, the council was able to leverage the Anti-Social Behviour Act to eject the residents of a particular house/property. These ASBOs (AntiSocial Behaviour Orders) are also used in the UK to deal with noisy neighbours, unruly people on buses, football hooligans, people with habits of getting drunk and disorderly, abandoned cars, etc. Note that "The Register" is a UK publication. Also note that the substance of the above-quoted article is that various groups COOPERATED and WORKED TOGETHER to solve the problem. This included the police, the owners of the property, the users of neighbouring properties. I hope you see the parallels here. Mind you, it would help if some of the anti-abuse groups would band together under some umbrella organization that ISPs could join. Botnet researchers, SPAM fighters, etc. That way there could be some sort of good housekeeping seal of approval that ISPs can use to competitive advantage in the marketplace. At that point, money starts to talk and there is an economic incentive to clean up your act and get that "seal". --Michael Dillon
FCC Outage Reports ..(.was Verizon outage in Southern California?)
I wasn't thinking in terms of automatic monitoring, that would open up
a can of worms security wise.
Just looking at some way of getting the manual reporting (that is still
taking place to the FCC) back in the (semi?)public domain. Due to
terrorism concerns, that information is no longer available online. I'm
pretty sure the LEC's and IXC's like it that way also, as they no longer
have to air their dirty laundry. I was able to get some information
under the Freedom of Information act for an outage that affected me
directly , but that takes days or weeks. As close to real-time
information as possible is what's needed to assess and respond to a
major outage, i.e. routing voice/data via different carriers, being able
to explain to end users why their email or phone calls didn't go through
, etc. and eliminating the need to open tons of trouble tickets during a
major event. One master ticket - such as fiber cut affect xxx OC48's
would suffice.
Not sure how this can be balanced against DHS perceived needs
though...any suggestions?
-Original Message-
From: Vicky Rode [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 19, 2005 5:45 PM
To: Wallace Keith
Subject: Re: Verizon outage in Southern California?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wonder how would Telcos, ISPs and GOV agencies feel about a third
party polling their devices, not to mention security.
I think netcarft comes close to what you're suggesting.
regards,
/virendra
Wallace Keith wrote:
> All this speculation!!
> Remember the good old days when you could see faxes of FCC outage
> reports online?
> Was sure nice to know what was going on, before the FCC took these
> offline (due to DHS?) It would really by nice to have some sort of an
> online clearing house, and gain some visibility again into overall
> network status. This will become even more important as things
> continue to converge. DACS and DC Power failures tend to affect
> multiple services and in the case of power, multiple carriers that
> are colo'd in the CO.
> -Keith
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Vicky Rode
> Sent: Wednesday, October 19, 2005 1:29 PM
> To: [EMAIL PROTECTED]
> Cc: nanog list
> Subject: Re: Verizon outage in Southern California?
>
>
> I wonder what ever happened to redundancy? I guess 5 9s (dunno what
> the going number is) got blown out of the water for them.
>
>
>
> regards,
> /virendra
>
> David Lesher wrote:
>
>>>Speaking on Deep Background, the Press Secretary whispered:
>>>
>>>
I'm not completely familiar with the telco jargon.
Does Tandem mean the same as a local central office, where POTS
lines terminate at the switch? Long Beach has a population of
470,000. The C/Os I know of are:
>>>
>>>
>>>
>>>A "Central Office" switch talks to subscribers aka end-users.
>>>On its backside, it talks to other CO's and tandems. Time was, that
>>>was also VF copper pairs, but it's long since all
>>>DS1 and up.
>>>
>>>A tandem is a switch that talks not to subs, but only to CO's. In
>>>days
>
>
>>>of old, when a {dialup} call went to the other side of town, chances
>>>are it went you-yourCO-downtown tandem-joesCO-joe. {copper all the
>>>way...}.
>>>
>>>A tandem was always housed in large CO building, but might have been
>>>ATT's vice the operationg company, etc...
>>>
>>>But ESS's and ""classless switching"" and massive expansion of the
>>>plant really muddled the picture. An ESS could be both a CO switch
>>>[for multiple prefixes and even multiple NPA's..] AND act like a
>>>tandem.. And oh, the actual "line cards" can be remoted 100 miles
>>>away
>
>
>>>in a horz. phonebooth box alongside the road in Smallville
>>>with DS1's/OC coming back.
>>>
>>>My guess is a DACS, a cross-connect point that is an software-driven
>>>patch panel, lost its marbles. [engineering term of art.] A DACS
>>>could have dozen->MANY dozen DS1/DS3/OC-n going hither and yon. Some
>>>will be leased circuits. Others will be the CO trunks going from one
>>>switch to another. It may/may not have muxes internal, so that what
>>>arrives on a DS1 leaves in a OC96..
>>>
>>>I note it went down at 2:20 AM. That SCREAMS software
upgrade/cutover.
>
>
>>>What's to bet GEE, no...VZEEE, was doing just that and there was a
>>>major ohshit.
>>>
>>>Sean noted a long while back that somehow, DACS crashes always seem
>>>to
>
>
>>>take hours to recover. Maybe the backups are on Kansas City standard
>>>tapes, I donno.. but this sounds like that..
>>>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDVr5HpbZvCIJx1bcRApndAKCyFEbNgzqSeqxfCj8I6A/Eq4x/QQCgoFRj
CuS3SSCRkdL7vtHE+Bsto3E=
=MQzx
-END PGP SIGNATURE-
Are ISP's responsible for worms and viruses
Bruce Schneier seems to think so... // http://www.theregister.co.uk/2005/10/19/schneier_talks_law/ By John Oates in Vienna 19th October 2005 RSA Europe 2005 ISPs must be made liable for viruses and other bad network traffic, Bruce Schneier, security guru and founder and CTO of Counterpane Internet Security, told The Register yesterday. He said: "It's about externalities - like a chemical company polluting a river - they don't live downstream and they don't care what happens. You need regulation to make it bad business for them not to care. You need to raise the cost of doing it wrong." Schneier said there was a parallel with the success of the environmental movement - protests and court cases made it too expensive to keep polluting and made it better business to be greener. // Let's one up this and blame vendors like Microsoft and hold them liable too. http://news.google.com/news?hl=en&ned=us&q=microsoft+patch+worm&btnG=Search+News =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey
Re: Scalability issues in the Internet routing system
[EMAIL PROTECTED] (Tony Li) wrote: > Please expect that your idea has been discussed before. We're an old > bunch. ;-) I've just answered on a mail from Owen, so maybe you get the feeling of "oh, we discarded that long ago" when you read it. Please tell me ;-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <[EMAIL PROTECTED]>) --[ ELMI-RIPE ]---
Re: multi homing pressure
I wanted to answer on this, because I thought along the same lines. [EMAIL PROTECTED] (Owen DeLong) wrote: > 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. My idea (somebody had it before, I'm sure, but then, it is my head that got invaded by it, so here she comes...): Rewriting would IMHO not work easily, but encapsulation would. Admittedly, this idea has occurred and lead to MPLS implementations (which are weak at interconnecting ISPs anyway). Well, let's see what else we can do, that MPLS maybe cannot. If the end user does not determine the RLI themselves, but their ISP does (on edge routers), it looks like this: A is the customer, Internet access provided by X B is the customer of Z Y is an intermediate system A -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> X X -> Add envelope -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] X -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> Y Y -> [RLI: Z [something]] -> Z Z -> Remove envelope -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] Z -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> B Routing decision is thus made by looking up paths for Z. Multihoming works the same, but we get multiple RLIs in the packet. If B is multihomed, I am not in favour of A (or X) selecting the location of B to be used. I believe the routing system should be able to determine that, like it's done right now. We have some major points here, and one possible ballbreaker: + Prefixes (ESI) have gone from the routing process + Customers are hidden behind their ISPs + Packets carry their routing information (instead of ESI info) + Packets may as well be deeply inspected, if necessary - Edge routers need to be extremely powerful, because they have to determine all the ESI <-> RLI information Ballbreaker (shared with Owen's idea): - This scheme needs the ISPs' edge routers to do the looking up, and if we do not find a way to incorporate updating the lookup table into part of the routing system, we are in violation of Par. 2.1.20 of draft-irtf-routing-reqs-03.txt, which is a very sensible requirement IMHO. I'm not saying this solves all problems, but I did not want this idea lost in the mists of time; maybe it's a starting point, maybe it is not (I'm still not through with the draft). But at least it differentiates between DFZ (aka Internet Core) routing and edge routing. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <[EMAIL PROTECTED]>) --[ ELMI-RIPE ]---
design of a real routing v. endpoint id seperation
This is what I meant by suggesting that source routing was an original
attempt at a seperation from routing/locating and endpoint identifiers.
You can replace the concept of "source routing" in below with mpls TE,
l2tpv3 or any other suitable encapsulation mechanism.
The concept is that there would need to be some hierarchy of global
routing tables in order for routing to scale.
Currently circulated ideas for independence between routing and endpoint
identifier have certain modes for operation.
A)
- end node sends packet to destnode
- destnode location is looked up in <--- Today that is the
Global routing tables, indexed by destnode ID
- sent to there
Most proposals wish to replace/supplement SOMEWHERE with some amorphous
protocol and/or some external VeryLargeDatabase.
B)
- end node sends packet to destnode
- destnode location is routed through normative route table lookups
- inband signalling provides other alternatives for
session/transaction/conversation continuation
C)
- end node performs locator lookup
- end node encaps
- destnode decaps
This could be as easy as performing IPinIP with srv records and DDNS.
This is in direct contrast to all other proposals in that it is much
closer to being implementable Today with Todays technology.
A chunk of ipv6 space is carved off. This is assigned to multihoming
desiring sites.
All routers that currently carry Global Routing Tables {can | should }
filter this space from their tables
completely by default - except the single prefix covering the entire space.
A customer with a prefix assigned from this chunk has to connect with an
ISP who has
* a Very Large Multihoming (to handle scaling concerns) router somewhere
in its network that peers to other ISP Very Large Multihoming routers.
ISP operating a VLMrouter to offer multihoming service to their
customers would originate the entire multihoming space prefix to their
customers AND to all their peers.
These would have ALL the prefixes from the Multihoming Space.
* the customer would peer with the VLMrouter, receive no routes and
advertise their prefix.
* source routing allowed on ingress IF the destaddr is in the multihoming
space AND the route-option is the Very Large Multihoming router
* source routing is allowed within the ISP network
The VLMrouter would make a SOURCE routing decision, putting a source
route destination to the customer.
* The ISP allows egress source routed packets
What this means is that there are 2 tables on the internet, the table
that ALL internet routes need have (like today) and the table that only
an ISP offering access to multihoming need have. The ISP offering such
access would only need, say one box per POP or so.
So the scaling problem becomes much smaller in scope. Now only ISP
wishing to offer multihoming services need to track the multihoming
table. Additionaly, the tables are actually halved, the VLMrouter need
not contain the normal internet routes and vice versa.
The downside is that an ISP performing as multihoming table hoster would
be a magnet for traffic that would possibly transit in and out.
Smaller multihoming hosting ISPs would probably try to prepend the
prefix mightily, or arrange not to originate it at all, and simply
receive prefix source routed from an ISP they connect to who also hosts
multihoming hosting AND originates the prefix.
No changes to stacks, endpoint nodes or anything else needed.
(if source routing still works in ip6?)
Some source routing filtering capabilities needed for border patrolling
something like this
config-if#ip source-routing prefix-list multihoming-prefixes
access-group allowed-source-routes
Joe
Re: LACNIC to start allocating from 189/8 and 190/8
Hello, Commenting myself, there is an machine in the first address of each the announced blocks. Just in the case someone want to ping/traceroute. (189.0.0.1, 189.128.0.1, 190.0.0.1, 190.128.0.1) I forgot to mention this before. Ricardo Patara -- L A C N I C On Tue, Oct 18, 2005 at 03:02:24PM -0200, Ricardo Patara wrote: | | 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 | | |
Re: multi homing pressure
> > http://nms.lcs.mit.edu/ron/ronweb/#code > > > > (Part of my thesis work, > > Hehe, google for "vixie ifdefault". Paul's use of Squid is mentioned in this NANOG posting: http://www.cctec.com/maillists/nanog/historical/9702/msg00431.html Here are the notes from the SF NANOG presentation: http://www.academ.com/nanog/feb1997/multihoming.html --Michael Dillon
RE: /24 multihoming issue
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:[EMAIL PROTECTED] Gesendet: Thursday, October 20, 2005 1:43 AM An: Kyaw Khine Cc: nanog@merit.edu Betreff: Re: /24 multihoming issue [EMAIL PROTECTED] (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, <[EMAIL PROTECTED]>) --[ ELMI-RIPE ]---
Re: /24 multihoming issue
[EMAIL PROTECTED] (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, <[EMAIL PROTECTED]>) --[ ELMI-RIPE ]---
Re: /24 multihoming issue
> Is 7018 preferring 19094 over 701 regardless of > AS-PATH length? the convention is that, if 19094 is a customer of 7018, then it will always prefer it. randy
