- Test - lists.nanog.org

Re: Lazy Engineers and Viable Excuses
by Brian Dickson 26 Aug '03

26 Aug '03

Joe wrote: >>Haesu wrote: >> You ARE correct. If everyone employs IRR and put explicit filters everywhere, >> it'd be the perfect world.. > >... 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. There is this widely percieved notion that the IRR is a single, unadministered database. This is incorrect. The "Source:" field tells the whole story - there are multiple databases, with varying degrees of trust-worthiness, varying content, and varying uses. > >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. The IRR is the correct tool; what is missing is a little application of the available capabilities of the tool. Here's an example: You have a lot of address space to manage. Some BGP customers, some not. Some worthy of trust, some not. So, you operate your *own* routing registry, and tell the world about it. But, you, and only you, have update access. You mirror the routing registries of only the customers you trust. Your peers operate likewise. Your filter-building accesses the rr's of your peers, either directly, or via a reasonably well-located and well-trusted mirror. Or better yet, you mirror (possibly privately) them, yourself. Any problems with the content of any RR, you know who to contact (and blame). You also now have a mechanism to persuade your peers with, which is the peering agreement you both signed. Update it to include this, if you need to. No cruft, secure enough, no bogons, scalable. Technology that is already well understood, and for which tools have been built. Clear chain of trust, and straightforward means to sever problem servers. I don't see where (other than perhaps attitudes and erroneous assumptions) the problem is. And running a route-registry is *really* no more difficult than querying one, in most cases less so. Certainly less effort than even a small name server serving authoritative data... -- Brian Dickson Email: briand(a)cineclix.com http://www.cineclix.com Tel : +1 604 688 2339

1 0

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 25 Aug '03

25 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 25 Aug '03

25 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