traces from mae-east and mae-west via nitrous
hey all, just wondering if anyone is seeing strange results coming from traces performed from the coastal mae's via nitrous.digex.net ? tracing to 203.89.226.2 via mae-east i get: 1 atm-east.primustel.com (198.32.187.120) 4 msec 0 msec 0 msec 2 G1-0-10.cr1a.dca.primustel.com (209.227.134.2) [AS 11867] 0 msec 0 msec 4 msec 3 ATM6-0-101.cr1.phi.primustel.com (209.227.128.13) [AS 11867] 4 msec 4 msec 8 msec 4 ATM6-0-103.cr1.jfk.primustel.com (209.227.128.5) [AS 11867] 4 msec 8 msec 8 msec 5 ATM6-0-110.cr1.sjc.primustel.com (209.227.128.78) [AS 11867] 76 msec 76 msec 76 msec 6 209.227.129.242 [AS 11867] 252 msec 256 msec 252 msec 7 vl046.sw02.mel.iprimus.net.au (203.134.50.21) [AS 9443] 252 msec 256 msec 252 msec 8 203.134.50.14 [AS 9443] 256 msec 264 msec 268 msec 9 203-134-48-154.cust.mel.iprimus.net.au (203.134.48.154) [AS 9443] 260 msec 268 msec 280 msec 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * yet tracing to 203.89.226.2 via mae-central i get: 1 dfw10-core1-so-6-0-0.atlas.algx.net (165.117.69.81) 0 msec 0 msec 0 msec 2 ord10-core2-so-0-3-0-0.atlas.algx.net (165.117.200.50) 24 msec 28 msec 24 msec 3 ord10-core10-pos7-0.atlas.algx.net (165.117.192.122) [MPLS: Label 14458 Exp 0] 72 msec 28 msec 24 msec 4 ord2-core3-pos5-0.atlas.algx.net (165.117.56.105) [MPLS: Label 13186 Exp 0] 28 msec 24 msec 28 msec 5 ord2-core4-pos7-0.atlas.algx.net (165.117.48.98) 28 msec 24 msec 28 msec 6 206.220.243.180 56 msec 52 msec 44 msec 7 G1-0-10.cr1a.ord.primustel.com (209.227.140.2) [AS 11867] 60 msec 52 msec 60 msec 8 ATM6-0-101.cr1.ord.primustel.com (209.227.128.61) [AS 11867] 92 msec 96 msec 100 msec 9 209.227.129.242 [AS 11867] 276 msec 280 msec 296 msec 10 vl046.sw02.mel.iprimus.net.au (203.134.50.21) [AS 9443] 268 msec 268 msec 268 msec 11 203.134.50.14 [AS 9443] 296 msec 300 msec 320 msec 12 203-134-48-154.cust.mel.iprimus.net.au (203.134.48.154) [AS 9443] 284 msec 316 msec 284 msec 13 dcr02-g6-0.mlbn01.globalcenter.net.au (64.15.32.20) [AS 9328] 252 msec 260 msec 256 msec 14 64.15.32.51 [AS 9328] 292 msec * 260 msec Hop 9 from mae-east and 12 from mae-central are the same host... anyone seeing similar abnormalities ? thanks heaps, -marc. --- Marc Van Hoof Network Architect Ph: +61-3-9862-7888
Re: selective prepends...one more time
On Mon, 30 Sep 2002, Leo Bicknell wrote: > In general what this means is rather than having a couple of standard > route-map's/route-policies that get configured once and applied to > all peers you end up with a per-peer specific configuration. It > would seem to me that the opportunity for mistakes is grealy > increased. Even if we assume all the people using it really need > it, is it worth risking the performance of 500 or 1000 customers > for the 5-10 who actually use the features? Are you talking about the customer or the provider? A provider with a well thought-out community policy shouldn't need per-customer route-maps. The customer sends the provider the appropriate communities and the standard customer route-map takes the appropriate actions. That's one of the major benefits of communities, match on the community not the customer. I see your point about questioning the cost-benefit; however any provider of reasonable size needs a community policy anyway, so most of the cost is unavoidable. If done right it only needs to be incurred once. A customer, on the other hand, will of course need separate policy per transit to take advantage of provider-specific TE communities. For the typical multi-homed customer with a few upstreams this is hardly unmanageable. Bradley
Re: selective prepends...one more time
On Mon, 30 Sep 2002, Leo Bicknell wrote: > In a message written on Tue, Oct 01, 2002 at 12:16:07AM +0200, Iljitsch van Beijnum >wrote: > > I think most customers don't know how this works. Maybe someone should > > write a book that explains this kind of stuff... > > I'm not so sure I'd come to that conclusion. I think when most > customers see a problem on their transit providers network they Some NOCs, even ones that support this on their network, don't understand it...or at least have staff that don't even come close to grasping it. It wouldn't surprise me at all if it's beyond a great many customers. > Most people I see using this feature fall into two catagories. > The first type doesn't believe the provider can fix the problem > but is forced to use them (due to price, management, whatever) and > uses this to avoid their NOC because it doesn't work. The second > type of person believes they can actually do a better job of routing > than their upstream. This may even be true in some cases (where > the customer has several transit providers all supporting this > 'feature'), however I suspect in many cases the customer is actually > making their own life worse. Consider a network with several transit providers. Each transit pipe is incapable of handling all that network's traffic. The pipes may even be of wildly different sizes. Letting BGP decide where traffic goes (or comes from) with no tuning just won't work. You'd end up with some pipes overutilized and others underutilized. In this case, selective prepends make it possible to shift traffic around or decide "we're going to try forcing all ASxyz traffic to come to us over pipe A." There's also the occasional case of medium to long term overloaded peering between large providers in which case you might want to do all you can to force traffic to/from ASxzy to not come/go via pipe A. > increased. Even if we assume all the people using it really need > it, is it worth risking the performance of 500 or 1000 customers > for the 5-10 who actually use the features? I wonder if anyone from Sprint or C&W is willing/able to say what percentage of multihomed customers utilize these communities? With enough full views from enough route-servers, it might even be possible to analyze the data and see how many use this. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: selective prepends...one more time
In a message written on Tue, Oct 01, 2002 at 12:16:07AM +0200, Iljitsch van Beijnum wrote: > I think most customers don't know how this works. Maybe someone should > write a book that explains this kind of stuff... I'm not so sure I'd come to that conclusion. I think when most customers see a problem on their transit providers network they would rather open up a ticket with their transit provider, and have them solve the problem. Most people I see using this feature fall into two catagories. The first type doesn't believe the provider can fix the problem but is forced to use them (due to price, management, whatever) and uses this to avoid their NOC because it doesn't work. The second type of person believes they can actually do a better job of routing than their upstream. This may even be true in some cases (where the customer has several transit providers all supporting this 'feature'), however I suspect in many cases the customer is actually making their own life worse. In general what this means is rather than having a couple of standard route-map's/route-policies that get configured once and applied to all peers you end up with a per-peer specific configuration. It would seem to me that the opportunity for mistakes is grealy increased. Even if we assume all the people using it really need it, is it worth risking the performance of 500 or 1000 customers for the 5-10 who actually use the features? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: selective prepends...one more time
On Mon, 30 Sep 2002, Leo Bicknell wrote: > I'd like to ask a slightly different question. At the providers > who do support this feature, how many of your customers actually > use it? I can tell you that since this weekend Telia has one more customer using a selective prepend. I'm glad they offer this feature since there wasn't really any other way to avoid a congested path. > The last time I asked a couple of people this question in private > the answer was generally a number of customers that could be counted > on one hand, even at some quite large providers. I think most customers don't know how this works. Maybe someone should write a book that explains this kind of stuff... Iljitsch
List of members at LAAP ?? Re: AP IX locations
Going to the LAAP website yields no list of members. Does someone have a current list. AS20144 would be willing to peer with reasonable folks at the LAAP but lacking a list (and yes its been asked for in the past with no reply) we don't know who is there. John Brown Member of the Peering coordinators team for AS20144 On Mon, Sep 30, 2002 at 01:00:33PM -0700, Celeste Anderson wrote: > > Paul, et al. > > As I have responded privately to to others offlist, while MAE-LA has > withered, the other half of the exchange in LA (LAAP - www.laap.net) > run by the University of Southern California is still active. The > Telehouse LA facility is interconnected to the LAAP exchange and there > are other things in the offing that I am not at liberty to disclose > today, but will be rolled out in the very near future (press releases > being prepared as I write). > > So yes, there are viable options in the Los Angeles area for AP > carriers to exchange traffic with other entities here and vice versa. > > Celeste Anderson > LAAP Operations Manager (among other things) > USC/ISI > [EMAIL PROTECTED] > > --- Forwarded Message > > Date:29 Sep 2002 06:08:40 - > From:Paul Vixie <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: AP IX locations > > > > >I would confirm GM's assertion. Also, if you have the luxury of caring > > >more about a smaller set of large-capacity Tier1 private peers, there is > > >some presence of AsiaPac providers doing this at Equinix SJ. > > > > Actually Equinix-Los Angeles has more Asian based Networks coming in for > > turn-up in October than any other region from details gathered this > > week. Chunghwa is in as of this week. SingTel, Japan Telecom, Hanaro, are > > on track for peer-ready in October. DACOM is considering, etc. > > so what does that make telehouse-la after all these years... chopped liver? > there have been Plenty of asian isp's in los angeles for Quite a while now. > > there also seems to be a PAIX switch inside 1 Wilshire now. (mfn's chap.11 > filing having sawn off any hope we had of opening PAIX-LA.) > - -- > Paul Vixie > > --- End of Forwarded Message >
Re: AP IX locations
> I have heard that the new paix switch will be attached [to laap] as well. > But only rumored not sure if its true. it's true. there was a launch party recently when the paix switch was announced for 1 wilshire, and laap was absolutely mentioned along with the words "just like seattle" with regard to ix interconnect. paix is late with interconnect to nyiix and ames due to fiber delays, but there ought to be no such delays for a 1 wilshire switch.
Re: selective prepends...one more time
On Mon, Sep 30, 2002 at 09:48:18PM +, E.B. Dreger wrote: > > It also seems the people who use selective prepends really like > them. I give stronger recommendations for providers who offer > selective prepends... it appears people generally are oblivious > to its existence, but become intrigued when they learn of it. People like to play with knobs, even when nothing happens. Call it a routing placebo if you will. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: selective prepends...one more time
LB> Date: Mon, 30 Sep 2002 17:09:45 -0400 LB> From: Leo Bicknell LB> I'd like to ask a slightly different question. At the LB> providers who do support this feature, how many of your LB> customers actually use it? This is a bit like asking "how many of your customers use BGP?" LB> The last time I asked a couple of people this question in LB> private the answer was generally a number of customers that LB> could be counted on one hand, even at some quite large LB> providers. It seems most providers don't bother tuning routes unless there's congestion. i.e., proactive attempts to find lower-latency paths are rare. It also seems the people who use selective prepends really like them. I give stronger recommendations for providers who offer selective prepends... it appears people generally are oblivious to its existence, but become intrigued when they learn of it. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: AP IX locations
I have heard that the new paix switch will be attached as well. But only rumored not sure if its true. On Mon, 30 Sep 2002, Celeste Anderson wrote: > > Paul, et al. > > As I have responded privately to to others offlist, while MAE-LA has > withered, the other half of the exchange in LA (LAAP - www.laap.net) > run by the University of Southern California is still active. The > Telehouse LA facility is interconnected to the LAAP exchange and there > are other things in the offing that I am not at liberty to disclose > today, but will be rolled out in the very near future (press releases > being prepared as I write). > > So yes, there are viable options in the Los Angeles area for AP > carriers to exchange traffic with other entities here and vice versa. > > Celeste Anderson > LAAP Operations Manager (among other things) > USC/ISI > [EMAIL PROTECTED] > > --- Forwarded Message > > Date:29 Sep 2002 06:08:40 - > From:Paul Vixie <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: AP IX locations > > > > >I would confirm GM's assertion. Also, if you have the luxury of caring > > >more about a smaller set of large-capacity Tier1 private peers, there is > > >some presence of AsiaPac providers doing this at Equinix SJ. > > > > Actually Equinix-Los Angeles has more Asian based Networks coming in for > > turn-up in October than any other region from details gathered this > > week. Chunghwa is in as of this week. SingTel, Japan Telecom, Hanaro, are > > on track for peer-ready in October. DACOM is considering, etc. > > so what does that make telehouse-la after all these years... chopped liver? > there have been Plenty of asian isp's in los angeles for Quite a while now. > > there also seems to be a PAIX switch inside 1 Wilshire now. (mfn's chap.11 > filing having sawn off any hope we had of opening PAIX-LA.) > - -- > Paul Vixie > > --- End of Forwarded Message >
Re: selective prepends...one more time
In a message written on Mon, Sep 30, 2002 at 03:43:33PM -0400, [EMAIL PROTECTED] wrote: > From last week's thread on Cogent service and selective prepends, I've > compiled a list of transit providers that support BGP communities for > selective prepends when propagating routes to peers. I'd like to ask a slightly different question. At the providers who do support this feature, how many of your customers actually use it? The last time I asked a couple of people this question in private the answer was generally a number of customers that could be counted on one hand, even at some quite large providers. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: selective prepends...one more time
Not the size of Sprint or C&W but we support it also: http://www.eli.net/technical/bgprouting_policy.shtml Regards, Dave [EMAIL PROTECTED] wrote: > > >From last week's thread on Cogent service and selective prepends, I've > compiled a list of transit providers that support BGP communities for > selective prepends when propagating routes to peers. > > sprint > c&w > gblx.net > level3 > Williams Communications Group > internap.com > > Is anyone aware of others, preferably of similar size to Sprint and C&W > (and in the US) that support this? I need to choose an additional > provider real soon and already have Sprint and C&W. We'll be connecting > ideally in Orlando, FL, but can take connectivity in most of the bigger > cities in FL. > > -- > Jon Lewis *[EMAIL PROTECTED]*| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- -- Dave McGaugh, Internetwork Engineer Electric Lightwave, Inc. E-mail: [EMAIL PROTECTED] --
Trying to understand network operator management requirements
Hi, I've put a stake in the ground regarding network management. Below is a URL that discusses the problem. I'm wondering if you would like to send me comments (off list) on what I've gotten right and what I've gotten wrong. This draft compliment's Bill Woodcock's draft, in as much as I'm really summarizing where he is specifying, and I'm also looking in other areas. I welcome your comments on any point you believe to be correct, incorrect, or just poorly written ;-) ftp://ftp.ietf.org/internet-drafts/draft-lear-config-issues-00.txt Thanks in advance, Eliot
Re: selective prepends...one more time
On Mon, 30 Sep 2002, Jared Mauch wrote: > > Verio can: > > http://info.us.bb.verio.net/routing.html#communities > France Telecom can do it as well http://www.ripe.net/perl/whois?AS5511
Re: AP IX locations
Paul, et al. As I have responded privately to to others offlist, while MAE-LA has withered, the other half of the exchange in LA (LAAP - www.laap.net) run by the University of Southern California is still active. The Telehouse LA facility is interconnected to the LAAP exchange and there are other things in the offing that I am not at liberty to disclose today, but will be rolled out in the very near future (press releases being prepared as I write). So yes, there are viable options in the Los Angeles area for AP carriers to exchange traffic with other entities here and vice versa. Celeste Anderson LAAP Operations Manager (among other things) USC/ISI [EMAIL PROTECTED] --- Forwarded Message Date:29 Sep 2002 06:08:40 - From:Paul Vixie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: AP IX locations > >I would confirm GM's assertion. Also, if you have the luxury of caring > >more about a smaller set of large-capacity Tier1 private peers, there is > >some presence of AsiaPac providers doing this at Equinix SJ. > > Actually Equinix-Los Angeles has more Asian based Networks coming in for > turn-up in October than any other region from details gathered this > week. Chunghwa is in as of this week. SingTel, Japan Telecom, Hanaro, are > on track for peer-ready in October. DACOM is considering, etc. so what does that make telehouse-la after all these years... chopped liver? there have been Plenty of asian isp's in los angeles for Quite a while now. there also seems to be a PAIX switch inside 1 Wilshire now. (mfn's chap.11 filing having sawn off any hope we had of opening PAIX-LA.) - -- Paul Vixie --- End of Forwarded Message
Re: selective prepends...one more time
Verio can: http://info.us.bb.verio.net/routing.html#communities On Mon, Sep 30, 2002 at 03:43:33PM -0400, [EMAIL PROTECTED] wrote: > > >From last week's thread on Cogent service and selective prepends, I've > compiled a list of transit providers that support BGP communities for > selective prepends when propagating routes to peers. > > sprint > c&w > gblx.net > level3 > Williams Communications Group > internap.com > > Is anyone aware of others, preferably of similar size to Sprint and C&W > (and in the US) that support this? I need to choose an additional > provider real soon and already have Sprint and C&W. We'll be connecting > ideally in Orlando, FL, but can take connectivity in most of the bigger > cities in FL. > > -- > Jon Lewis *[EMAIL PROTECTED]*| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ > -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
selective prepends...one more time
>From last week's thread on Cogent service and selective prepends, I've compiled a list of transit providers that support BGP communities for selective prepends when propagating routes to peers. sprint c&w gblx.net level3 Williams Communications Group internap.com Is anyone aware of others, preferably of similar size to Sprint and C&W (and in the US) that support this? I need to choose an additional provider real soon and already have Sprint and C&W. We'll be connecting ideally in Orlando, FL, but can take connectivity in most of the bigger cities in FL. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Index of presentations
You'll find new subject & author indices for NANOG presentations here: http://www.nanog.org/subjects.html http://www.nanog.org/authors.html Most talks have an abstract, slides, and RealAudio recording. Only the last six meetings are done, but more will be coming soon. Comments welcome, e.g., do the categories make sense? Please send suggestions to me or [EMAIL PROTECTED], not to the list. PS - our FAQ has been growing too: http://www.nanog.org/listfaq.html Many thanks to contributors Etaoin Shrdlu, Rachel K. Warren, JC Dill, Joe Abley, Richard Steenbergen, Marty Hannigan, Gwendolynn Ferch Elydyr, John Payne, Ginna Musgrove, and Doug Clements.
Re: Internet Core Routing - Ethernet
Thus spake "Bob Martinez" <[EMAIL PROTECTED]> > You are the guy that posted about IBGP Nailed Routes. I love that idea. I > understand your love of L3 and your design is great; however, as a service > provider, you can't always rely on IP. As an ISP, your job is to provide IP. If you -- much less your customers -- can't rely on your IP service, you'll soon be toast in the marketplace. > What about Global Ethernet? The NY, Paris, Tokyo, Seoul, Singapore, > Frankfurt, Moscow, Bankok, Sydney, Hong Kong, London, Cairo, Los > Angeles, Jerusalem, Toronto, Mexico City, Rio (Can I manage this one?) > Internet Exchange? And one errant BPDU can take down your entire network. You're going to need a bunch of PhD-level guys in your NOC with that design. > Simple like you said. Gotta work on the reliability part though. You're just now thinking about reliability after you've finalized your design? Stop, you're killing me... S
Re: Internet Core Routing - Ethernet
Thus spake <[EMAIL PROTECTED]> > > 2. Ethernet is the technology. > > Excuse me if I chuckle, having heard THAT before in the last 2 decades or so. > > I've learned to not take *anybody* seriously when they say something is "THE" > anything. Structured programming wasn't the end-all, nor was ATM, nor was > Java, nor will XML or Ethernet. Yes, 10G-E will probably see wide deployment. > But I'll make a prediction - there will be something else coming out to > replace it long before it finishes replacing what's out there now. > > (For bonus points, compare the level-1 media characteristics of the original > 10mbit-over-thickwire with the 10gig-over-optical, and ask yourself if there's > anything in common other than the name. The electrical characteristics of 10BaseT aren't all that similar to 10Base[25] either. However, all of the 802.3 variants use CSMA/CD for half-duplex operation, and 802.11's CSMA/CA is reasonably similar. All of the 802.3 and 802.11 variants use the same MAC and LLC layers. Sure, the framing and modulation has varied over time. GE's undersize-frame packing was a neat innovation, 10GE's elimination of half-duplex was a bit overdue, jumbo frames could be neat if they ever get deployed, and 802.1p/q opened a lot of doors. However, throughout Ethernet's evolution, it's remained essentially the same beast from the user's perspective, and the L2 operation is still the same. Do I get my bonus points? :) S
Re: Internet Core Routing - Ethernet
Thus spake "Bob Martinez" <[EMAIL PROTECTED]> > >Hmm... so if somebody posts to the list with the problem, and somebody else > >saw that same issue and got a fix from the vendor, they need to send it to the > >vendor for comment, or they can say "Oh, you're being bit by bug (can't say > >because it would identify the vendor) in a (vendor model you can't say) > >several hops upstream from you". > > Is this a problem? Not on my team. When, say, every ISP in the world is bouncing half of its BGP links every time they come up because vendor A's bug aggravates vendor B's bug, it's helpful to know what the problem is. You might have encountered this in your own lab, or magically figured it out before the thousands of others on NANOG seeing the same problem, but odds are you won't. If vendor information is relevant to the discussion, it has merit. Vendor information purely for marketing or bashing is not; this is long established on NANOG and seems to work well. > >And how did we learn the names? Let's see.. Cisco, Juniper, Proteon, Bay, > > Dude, this is exactly what I'm talking about. You didn't mention my vendor. Wah. If you choose to use unpopular hardware, that's your choice. Cisco and Juniper account for around 98% of the Internet, so don't pretend you can ignore the implications of that. > >Now, did you actually *buy* and *use* all of that gear yourself? > > Friends in the community are my most trusted resource. NANOG is a lot of people's link to the "community". > No mistakes to report, sir. NANOG keeps me informed. It is invaluable when > used for operations. The Melissa virus, the WTC disaster, business > disasters. I didn't mention the names of service providers, but I consider > them to be vendors as well. That's funny, I remember a *lot* of vendor names being mentioned during the WTC attack and subsequent complications. Maybe not equipment vendors, but certainly service vendors. There was a lot learned there, and if you ignore who was helping who and which vendors did the learning, you're going to be behind the next time it happens. > A vendor that releases an official press release is more than welcome on > NANOG. Up to you gues. I'm just aginst opinionated vendor information > coming from NANOG. Moderate yourself. Press releases are marketing, and thus are not appropriate for NANOG. If someone wants to provide on-topic technical input, that should be welcome regardless of which ISP/vendor/etc they work for, or whether they hide their affiliation behind yahoo/hotmail. > I can build a network with any vendor. Just like you. Vendor does NOT > MATTER TO ME! If you're posting on NANOG and you don't feel the same, > perhaps you'd better unsubscribe. Do you really think the equipment/circuit/service vendors you choose do not affect how you design your network or the resultant services and availability you deliver to your customers? As Randy says, I encourage all of my competitors to think that way. > The other option may be to study Ethernet. Ethernet isn't a terribly difficult concept. > Everything else you said (below) makes you look like the mad scientist from > my POV. My R&D budget is down 72% from last year. RPR? RUCRAZY? Look > forward to seeing you on the battlefield while I chop you to shreds. Not a > single ATM project on the map nowadays huh? MPLS is out there, but who > needs it 'cept for certain situations sometimes driven by business needs. > When I need it, I hope it is over Ethernet. Ethernet is just another tool in the box. It has its uses, just like T1's, SONET, ATM, and even Token Ring. Perhaps it's more useful today than it was yesterday; we'll undoubtedly have a shiny new toy tomorrow though. > Wouldn't you rather have a reliable, redundant L2 core with isolated > failures and fast recovery? No. You haven't dealt much with STP if you think this is a good idea. > There are many examples of Ethernet in the internet core today. You'd be hard pressed to find any ISP world-wide that didn't use Ethernet. > I know of many service providers using another vendor besides the > two favorites on NANOG. Just about every ISP uses other vendors. Your point? > Ethernet: 2 (Mike Lieber did not challenge Ethernet as a technology) > Valdis: 1 Ethernet is _a_ technology. It's not the only one, and it never will be. S
Re: Internet Core Routing - Ethernet
> >Wrong. None of the vendors wants to help you what so ever. What they want > >to do is to have you spend your money with them by claiming that they > >want to help you. > Cool, I respect that attitude. At least now I know how to deal with you. > The glass is half empty. Very simple. Put a good product in front of me and you wont get this attitude. Tell me that you can do a line-rate filtering when you cant and be bitch-slapped. Should you, as a service provide, not want to be up every second day at 4am because a new super-cool feature that you have deployed broke your entire network, a dose of healthy skeptisism would do wonders to your nerves, your customer service nerves and *gasp* customers not disputing charges for services. > > > Wouldn't you rather have a reliable, redundant L2 core with isolated > > > failures and fast recovery? > > > >No. I hate complicated words and complicated concepts. It reminds me NASA > >spending 10M to invent a pen that writes in 0 gravity instead of using a > >pencil. > > You are the guy that posted about IBGP Nailed Routes. I love that idea. I > understand your love of L3 and your design is great; however, as a service > provider, you can't always rely on IP. You are absolutely correct. One should not rely on IP for everything. One also probably should not use Starwars Network Management Protocolv2 running over an unprotected network (which uses hubs in public places) to not just read telemetry data but also issue march commands. However, using IP as a transport between two encrypting SNMP gateways to do the same thing would do just fine. > What about Global Ethernet? The NY, Paris, Tokyo, Seoul, Singapore, > Frankfurt, Moscow, Bankok, Sydney, Hong Kong, London, Cairo, Los Angeles, > Jerusalem, Toronto, Mexico City, Rio (Can I manage this one?) Internet > Exchange? And see a spectacular cascading failure from NY affecting traffic in Cairo. Brilliant fireworks. I bet New York City's New Year celebration would be nothing compared to the fireworks at the NOC screens. However, should your company offer $500,000 per minute outage insurance policy, I am quite certain that a few of companies I consult for may be interested. > MPLS VPLS over Ethernet Anybody? Eik. > Use your nailed routes trick in the middle (MPLS side) and L2 peering > exchanges in each city. Only problem with this is complexity. No, the only problem with this is lack of clues on the designer's side. > Do this alone or with few partners and you may be able to pull it off > completely L2 without the cost of complexity. Simple like you said. I highly suggest before one jumps into this, he or she should take a few math and physics classes. It may open even some permanently shut eyes. Alex
Re:questionnaire
-BEGIN PGP SIGNED MESSAGE- *** [NOTE -- THIS IS AN AUTOMATED RESPONSE] Thank you for contacting the CERT(R) Coordination Center. We appreciate your contacting us and consider your communications with us to be very important. Because we focus our response efforts to have the greatest impact on the Internet community, we may be unable to provide you with a personal response to your message. Please review the pointers contained in this message for information which may be of immediate use to you. Section A - CERT/CC Current Activity Section B - Incident Reporting Information Section C - Vulnerability Reporting Information If you need additional information from the CERT/CC, we encourage you to begin by looking at our list of CERT/CC Frequently Asked Questions: http://www.cert.org/faq/cert_faq.html == Section A - CERT/CC Current Activity The CERT/CC Current Activity web page provides a summary list of the most frequent types of incident and vulnerability activity currently being reported to the CERT/CC. Please refer to this regularly updated page to obtain immediate assistance in response to frequently reported activity: http://www.cert.org/current/current_activity.html In addition, the latest CERT/CC documents can be found at: * CERT Advisories - http://www.cert.org/advisories/ * CERT Incident Notes - http://www.cert.org/incident_notes/ * CERT Vulnerability Notes - http://www.kb.cert.org/vuls/ * CERT Summaries - http://www.cert.org/summaries/ * CERT Tech Tips - http://www.cert.org/tech_tips/ * What's New - http://www.cert.org/nav/whatsnew.html * CERT/CC Web Site - http://www.cert.org/ For pointers to information about computer viruses and hoaxes, please see: * http://www.cert.org/other_sources/viruses.html == Section B - Incident Reporting Information We appreciate receiving incident reports because it helps us to gain a better understanding of ongoing intruder activities and attack profiles. From the information we receive, we are able to identify and address critical security issues within the Internet community. Because we prioritize our response efforts to have the greatest impact on the Internet community, we are not be able to provide everyone with a personal response. For general information about reporting incidents to the CERT/CC, please see our Incident Reporting Guidelines at: http://www.cert.org/tech_tips/incident_reporting.html To report incidents to the CERT/CC, please send information about the incident in plain text format to [EMAIL PROTECTED] You may wish to use our Incident Reporting Form, located at: http://www.cert.org/reporting/incident_form.txt The CERT/CC considers the following types of incidents to be emergencies: * possible life-threatening activity * attacks on the Internet infrastructure, such as: - root name servers - domain name servers - major archive sites - network access points (NAPs) * widespread automated attacks against Internet sites * new types of attacks or new vulnerabilities If you are reporting such an emergency outside our operational hours - business days between 08:00-17:00 EST/EDT (GMT-5/GMT-4) and require immediate assistance, then please call the CERT hotline: +1 412 268 7090 If you believe the intruder activity is a threat to people's lives or to the Internet infrastructure, please contact us immediately. == Section C - Vulnerability Reporting Information If you would like to report a new type of vulnerability or tool being used by the intruder community, we would be interested in any details that you may have. If you are able, please include any or all of source code, log files of execution, and descriptions of operating dependencies. Please feel free to submit these details in ASCII format files (where possible) of your own design, or if you prefer to use a form, please see the file: http://www.cert.org/reporting/vulnerability_form.txt Please also encrypt the report using PGP if you are able to do so. Instructions are given at the top of the reporting form. == CERT(R) Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA USA 15213-3890 Internet e-mail: [EMAIL PROTECTED] (monitored during business hours) Telephone: +1-412-268-7090 24-hour hotline CERT Coordination Center personnel answer business days 08:00-17:00 EST/EDT (GMT-5)/(GMT-4), on call for emergencies
Williams NOC info?
Hi all. I am considering purchasing additional transit from Williams and I am wishing to get feedback on the support of their NOC department. Things I am looking for feedback on are 1) Availability of competent staff...i.e., do I have to play relay with an operator when I can hear her asking the tech questions but the tech refusing to get on the phone (I won't say who this is in a public forum), 2) response time of NOC on weekends and holidays and 3) ease of reaching the NOC (limited menu hell or transfer from one person to the next to the next. Please reply to me in person in order to limit any bashing if there is to be any... Many many thanks in advance, Jeffrey --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.391 / Virus Database: 222 - Release Date: 9/19/2002
