- NANOG - lists.nanog.org

Odd Default Gateway Address
by HongJin Choi 26 Aug '03

26 Aug '03

Hi!! I use CISCO Catalyst 6509. And, My PC use WinXP. Default Gateway Address is 172.16.4.200. But, in case that default gateway address chage 1.1.1.1, communication with other segment is O.K. I think that Communication can't establish to other segment. When i look at the ARP Table, the MAC address of 172.16.4.200 and 1.1.1.1 is same. How do i correct this problem?? Thanks in advance!! ---------------------------------------------------------------------------- ------- HongJin, Choi Manager, ITG Team/Infra Biz. Division, HANWHA S&C CO., LTD. HANWHA Bldg., 20F, #1, Janggyo-Dong, Jung-Gu, Seoul, 100-797, KOREA Email : dunkhong(a)hanbit.net Tel : +82-2-729-4828 Fax : +82-2-729-4680 Mobile : +82-11-9894-2358

2 1

Scitec SAT3000 DSU console pinout?
by Joe Abley 26 Aug '03

26 Aug '03

Hi, Does anybody happen to know the pinouts for the console port on a Scitec SAT3000 E1 DSU? (I am at a particularly remote site, and local information is hard to come by) Joe

1 0

MAx TNT Filter -- Actual FILTER
by Sean Watkins 26 Aug '03

26 Aug '03

TNT Users: Apologize: I know I am posting to multiple lists, but multiple lists with Ascend users.. none so far have posted and numerous are asking for it... Including myself! Hopefully recommendations will follow After several hours of trial and error - after I setup the recommended Cisco filters upstream from TNT equipment. I have been constantly watching log entries, to find people blasting away with ICMP/UDP Port 135/ TCP Port 137 the most. I have come up a filter, for the TNT: new FILTER set filter-name = pre-nachi2 set input-filters 1 valid-entry = yes set input-filters 1 Type = ip-filter set input-filters 1 ip-filter protocol = 6 set input-filters 1 ip-filter Dst-Port-Cmp = eql set input-filters 1 ip-filter dest-port = 135 set input-filters 2 valid-entry = yes set input-filters 2 Type = ip-filter set input-filters 2 ip-filter protocol = 17 set input-filters 2 ip-filter Dst-Port-Cmp = eql set input-filters 2 ip-filter dest-port = 137 set input-filters 3 valid-entry = yes set input-filters 3 forward = yes set input-filters 3 Type = ip-filter set input-filters 3 ip-filter protocol = 1 set input-filters 3 ip-filter dest-address-mask = 255.255.255.255 set input-filters 3 ip-filter dest-address = X.X.X.X set input-filters 4 valid-entry = yes set input-filters 4 Type = ip-filter set input-filters 4 ip-filter protocol = 1 set input-filters 5 valid-entry = yes set input-filters 5 forward = yes set input-filters 5 Type = ip-filter write -f ; This filter blocks UDP Port 135, tcp port 137, allows ICMP to X.X.X.X, drops all other ICMP, and then allows any other traffic out. Basically, X.X.X.X is a machine here we can use to have customers ping us/ we ping them. This filter seems to work for 90% of people, but for unknown reasons, ICMP still seems to leak in. Any ideas? I'm applying this filter to data under answer-defaults, session-info. I've set iproute-cache-enable = no, Disabled proxy arp... Everything. Still we are dropping packets at peak times left right and center for unknown reasons. show ip cache flow on upstream Cisco gear shows basically regular traffic. Ideas/comments etc? Sean > > > ----- Original Message ----- > From: "Dave Birkbeck" <dbirkbeck(a)ikano.com> > To: "'Tony Bunce'" <tonyb(a)go-concepts.com>; "'Sean Watkins > (northrock)'" > <sean(a)northrock.bm>; <radiator(a)open.com.au> > Sent: Monday, August 25, 2003 7:27 PM > Subject: RE: (RADIATOR) MAx TNT & MSBlast > > >> All, >> >> In addition to having the ACL's that Cisco recommends. Has anyone come >> up with a Radius ascend-data-filter that will slow down the spread of >> these crazy viruses? Or better yet, a filter that will block ICMP. >> >> Again, I know this is probably not the list for this discussion, but >> this topic is definitely for the greater good of the Internet. >> >> That being said does anyone know of a list that discusses various NAS >> topics?

1 0

RE: Virus
by Ingevaldson, Dan (ISS Atlanta) 26 Aug '03

26 Aug '03

Wesley- There is no evidence that the patch does not fix the vulnerability. You may be getting infected during the patching and cleaning process. Best bet is to patch, reboot, then clean. Regards, =============================== Daniel Ingevaldson Engineering Manager, X-Force R&D dsi(a)iss.net 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net =============================== -----Original Message----- From: Wesley Vaux [mailto:Wesley.Vaux@globalknowledge.com] Sent: Monday, August 25, 2003 11:25 AM To: nanog(a)merit.edu Subject: Virus Has anyone noticed that after patching and cleaning machines that they become infected again? Is this just me? What is your process for remove Nachi.worm. Sorry for bringing this back up. Wes Vaux, CCNA, CCDA Network Security Engineer, 9000 Regency Pkwy Ste 500 Cary, NC 27511 t 919.463.6782 f 919.463.1290 Global Knowledge Experts Teaching Experts http://www.globalknowledge.com

4 3

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