August 2003 - Test - lists.nanog.org

Force Majeure
by Brian Cashman 26 Aug '03

26 Aug '03

In the opinion of folks on this list, did the recent power failure in the northeast (started 8/14 and lasted several days in some places) constitute a force majeure event? Thanks, Brian Cashman Merit

5 4

Re: [Re: Lazy Engineers and Viable Excuses]
by Joshua Sahala 26 Aug '03

26 Aug '03

Joe Abley <jabley(a)isc.org> wrote: [cut] > .. if everybody used the IRR to build explicit filters everywhere, if > everybody kept their objects in the IRR up-to-date, and if there was > some appropriate authorisation scheme in place to allow you to trust > the data in the IRR implicitly, it'd be a perfect world. not perfect, you would still need to filter at the customer ingress, making sure that they weren't spoofing a 'properly registered route object' that wasn't part of the aup that they had signed....they did sign an aup right??? > The IRR is currently a reasonable tool to use to avoid listening to > routes which are advertised by mistake from peers who populate the IRR > accurately. It's not a reasonable tool for avoiding maliciously bogus > routes, since sticking maliciously bogus information in the IRR is > trivial. trivial yes, but it would be nice if there was at least a minimal effort to filter unregistered route objects, especially on transit from certain regions of the world....we can deal with the registration issue separately. /joshua > Joe > > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

Looking for Verizon Contact - default UDP port filtering is hurting our service
by dani-nanog＠roisman.com 26 Aug '03

26 Aug '03

Greetings, I'm trying to find Verizon NOC contact information to discuss their port filtering. We have customers on Verizon DSL who cannot use our service due to _alleged_ default filtering of high-numbered UDP ports. I've tried puck, but the information is not there :( If anyone is listening in, or can send me the contact info off-list, that would be much appreciated. If anyone has a URL that officially details blocked protocols/port numbers, please share with the list. Mimimally, I'm looking for confirmation of Verizon's policies in effect. Ideally, I'd like to convince them to allow our mutual customers to enjoy our services. Thank you, - Dani

1 0

DSL restrictions for CLECs?
by Len Sassaman 26 Aug '03

26 Aug '03

Sorry for the somewhat off-topic post, but I figured this was the best place to ask. I've been trying to get a new DSL installation in my apartment complex. After being told by Covad that I was unable to get ADSL through them, even though I was only 13K feet from the CO, I called SBC to find out what the problem with my line was. After two days of talking to people of widely varying clue levels at SBC, this is what I've learned: I'm on a digital pair gain line out of a local RT. There are nothing but DPG lines run from the CO -- copper is not, and never was, an option for this neighborhood. SBC will not allow CLECs to access their DPG lines either in the CO or in the RT -- "use the copper" is the response. Is this standard practice? Is this legal? I am basically in a situation where DSL availability should be a non-issue, except that SBC/Yahoo! has constructed a scenario where they are the only possible provider due to their decision to replace copper pair with DPG, and to refuse to allow CLEC DSLAMs on the DPG lines. What are the options for the CLECs that want to provide DSL, particularly if this practice continues and last mile DPG lines with local RTs becomes standard? --Len.

2 1

RE: bgp route-map
by Michel Py 26 Aug '03

26 Aug '03

> Haesu C. wrote: > However: On prefixes being announced to me INBOUND, is there a > feature to set in route-map so that it checks whether the > advertised prefix is already existing in local RIB? If I understand correctly, what you want is the same as conditional advertisements: http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_examp… except that it needs to be applied to received routes instead of advertised routes. In other words, it's not enough for you to dump the bogon traffic in a blackhole; you also want to dump bogonish routes received from your peers before they even get to your RIB. If I understood it right, a naïve look at it would be that since the function already exists in the other direction it should not be too big of a deal to do it the other way, but I'm not the one compiling IOS. Michel.

1 0

RE: Rules and Regs for a LEC's and Non LEC's
by McBurnett, Jim 26 Aug '03

26 Aug '03

-RBOCs (note, not ILECs) cannot move inter-lata traffic without being -approved by PUC in each state for "interstate long distance". (I believe -this is part of 1984 MFJ). -CLECs have no restrictions on that. Neither do non-CLEC ISPs. ---alex I thought this only applied to VOICE traffic. AS far as I know Internet access traffic is non-regulated. I used to work at a CLEC and we never worried about PUC complaints on an Internet access level of service. now if the T-1 level was down, that was a different story. -J

3 2

Extreme + Nachi = ipfdb overflow
by Joshua Coombs 25 Aug '03

25 Aug '03

After battling Nachi and it's flood of icmp traffic, I've discovered that it's not the Cisco gear that gets hit hard by it, it was the Extreme gear. Nachi generates enough 'random' traffic to flood and subsequently thrash the ip forwarding DB on the Summit 1i we were using so badly as to drop it from gigabit capible to barely eeking out 6mb/sec. Before I redeploy the switch, I need to find a way to keep the ipfdb from flodding while allowing it to be the primary carrier of traffic. ACLs blocking ICMP on the Extreme act too late, by the time the cpu sees the packet to drop it, it's already horned its way into the ipfdb. Does anyone have any suggestions on ways to allow the switch to participate as an L3 router while minimizing the chances of a worm taking it out so easily again? Joshua Coombs GWI Networking

5 4

exchangecolo 200paul san francisco issues?
by Haesu 25 Aug '03

25 Aug '03

Is anyone aware of any problems/issues with 200 paul ave SFO? -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu(a)towardex.com Cell: (978) 394-2867

6 5

Layer 5+ inspection at the border?
by Rick Ernst 25 Aug '03

25 Aug '03

I'm looking for a beast that is roughly a combination of Cisco NBAR and Foundry URL inspection. NBAR worked pretty well for CodeRed, but I'd rather have a dedicated device rather than overloading a router with non-routing functions. I haven't used Foundry's URL inspection, but it looks reasonable, too. I would, however, like something that can do generic Layer 5+ inspection/alteration so things such as SMTP headers can also be inspected and processed/blocked/altered. I'd prefer a switching device that can replace the switches between my border and core, but allow transparent manipulation of the packets, preferably at wire-speed. Any suggestions? The idea is to have a central location that can watch for and block 'bad payload'. It looks like F5 may have a solution, but I'd like comments and experiences from those that have deployed such a device. Thanks, Rick

1 0

RE: TNT issues "workaround"
by Ejay Hire 25 Aug '03

25 Aug '03

In response to this, I'd like to comment on Lucent's excellent response to this issue. Never before have I seen such an effective application of hear-no-evil, see-no-evil, and speak-no-evil. While other vendors were wasting our time sending out notifications of bugs / vulnerabilities with workarounds / fixes, Lucent's response was much more efficient and eloquent. Here is a summary of the responses I've received over several days phone calls, calling for my current employer who does not have a service contract, and one for one of my consulting customers who does have a service contract. If you have a service contract, I'm allowed to tell you we aren't aware of any issues. If you don't have a service contract, I'm allowed to sell you a service contract. On that note, I might have some TNT's for sale pretty soon. -Ejay -----Original Message----- From: Brian Wallingford [mailto:brian@meganet.net] Sent: Saturday, August 23, 2003 12:41 AM To: nanog(a)merit.edu Subject: TNT issues "workaround" I haven't seen specific details posted here, so: Like many others, we've had a few TNTs online for years without hiccups or reboots until this week. Beginning late Sunday, we saw seemingly random blade reboots, and total system crashes. Errors ranged from memory leaks to infinite loops on the controller blade, but all blades were susceptible. HDLC2 blades seemed to be particularly vulnerable. We saw boxes that had been rock-solid for very long periods suddenly rebooting at periods ranging from 20 minutes to 4 hours, with no obvious cause (i.e., nothing more specific than the above). Border and core filtering of icmp echo * did little good. On the suggestion of some folks on another list, and against my better judgment, we disabled route caching in order to free up additional memory (though memory did not appear fragmented). This stabilized all involved boxes, and surprisingly, did not result in significant degradation of end user performance. Granted, it's not a true fix, but it may get you a few extra Z's at night. hth, brian

3 2