October 2003 - Test - lists.nanog.org

RE: Extreme BlackDiamond
by Shazad - eServers 13 Oct '03

13 Oct '03

Firstly, a BIG BIG thanks to all the replies. I would like to add one comment onto this, the Black Diamonds would be used for purely switching and nothing else. The Junipers would do the routing, BGP tables etc... As for as TheTollyGroup how much credibility do these guys hold? Thanks again. -Shazzy -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Shazad - eServers Sent: 13 October 2003 02:16 To: nanog(a)merit.edu Subject: Extreme BlackDiamond How are these for CORE SWITCHES (distribution) compared to BigIron and the CISCO 6509? >From what I have heard and reports they are very solid switches. Thanks in advance -Shazzy

2 1

BGP and OSPF
by Jean-Yves Le Boudec 13 Oct '03

13 Oct '03

It is known that redistribution of routes learnt by BGP into an IGP is considered harmful, but I am still wondering how you can route without redistribution of BGP routes in an OSPF cloud that connects to several external networks. I have the following scenario. RA (AS100) | RB (AS101) ------------------------ R1 R2 R0 (AS559) R3 R4 ------------------------ RC (AS201) | RD (AS202) All routers except R0 run BGP. R0--R4 are in the same AS and run OSPF. RA-RD are all in distinct ASs. RA is BGP peer to R1, RB to R2, RC to R3 and RD to R4. The addresses and numbers are fake. The ASs are peers, not customers. Assume that R1 learns a route to a network in AS100, says 1.1/16, with next hop = 3.3.3.1 (the IP address of the p2p link R1-RA). Now assume a data packet with destination address in 1.1/16 is received by any router in AS559, say for example R0 or R4. The router has to know where to forward it. Since AS559 connects to different peer ASs in different locations, it does not seem feasible to use default routes. (Method 1) One way to is to assume that R1 redistributes the route 1.1/16 into OSPF, which will then propagate it as a type 4 LSA. Then R0 and R4 can build a forwarding table (using OSPF) and set a forwarding entry to 1.1/16. This method is what is described in Huitema's book "Routing in the Internet". Now I understand that this is not done in practice (I am right ?) since it forces OSPF to carry all the IP prefixes seen by BGP, which in that case might be all prefixes in the world. (Method 2) An alternative is to have recursive table lookup in forwarding entries at all border routers (R1 to R4). R4 writes that the destination address 1.1/16 is to be sent to NEXT-HOP = 3.3.3.1. R4 learns this over I-BGP from R1. The data packet with destination address in 1.1/16 uses loose source routing inside AS559 and is sent to the link R1-RA. The job of OSPF is only to propagate how to route to all addresses in AS559 (including 3.3.3.1) and there is no redistribution of BGP into OSPF. Border routers need to update the forwarding tables using their RIB learnt from BGP. Now source routing is obsolete in IPv4, does any one use it ? (Method 3) Same as method 2, but IP in IP encapsulation is used instead of loose source routing. Seems heavy weight for a high speed backbone. (Method 4) Same as method 2, but Tag Switching (or MPLS) is used instead of loose source routing. Can any one help me understand what is done in practice among Methods 1 to 4, or any other one that I missed ? Thanks in advance, JL

4 4

Re: Extreme BlackDiamond
by Andrew - Supernews 13 Oct '03

13 Oct '03

>>> I can understand how a virus like Welchia can affect a flow-based >>> architecture like Extremes. I was under the impression that CEF >>> enabled Cisco gear wouldnt have this problem, but Cisco has >>> instructions on their webpage on how deal with it and cites CPU >>> usage as the reason. With CEF I thought the CPU wasn't involved? >>> CEF is perhaps differently implemented on different plattforms? >> >> I think CEF in HW is the key, ASIC based and not Flow based. I'm >> not all-knowlegable on which platforms do this, but the 7500, >> 12000, 2948G-L3, 4908 have it. Whether CEF is ASIC-based or in software is not an issue as such. CEF is _not_ flow routing; CEF tables contain only destinations (not source+destination or port numbers), they contain entire destination prefixes not single IP addresses, they are pre-built and maintained from the routing tables rather than added entry-by-entry as traffic arrives. CPU is still an issue in some cases because when a destination is on an attached network and has no ARP entry, there is no CEF adjacency for it; accordingly, when traffic arrives for that destination it is punted to process level in order to trigger an ARP. Once the ARP succeeds the adjacency is set up and further packets are routed via CEF (whether hardware or software according to platform). However, if the destination is not adjacent, this does not apply (since the ARP entry for the next-hop router will already be present) and all packets will be CEF-switched. (Enabling CEF is often mentioned in Cisco docs as a workaround for worm traffic problems.) -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services

1 0

Re: Extreme BlackDiamond
by sthaug＠nethelp.no 13 Oct '03

13 Oct '03

> > I can understand how a virus like Welchia can affect a flow-based > > architecture like Extremes. I was under the impression that CEF enabled > > Cisco gear wouldnt have this problem, but Cisco has instructions on their > > webpage on how deal with it and cites CPU usage as the reason. With CEF I > > thought the CPU wasn't involved? CEF is perhaps differently implemented on > > different plattforms? > > I think CEF in HW is the key, ASIC based and not Flow based. > I'm not all-knowlegable on which platforms do this, but the 7500, 12000, > 2948G-L3, 4908 have it. Yup. We have 6509s with Sup2/MSFC2/PFC2, and have had no problems with ICMP in connection with recent virus/worm attacks. Oh yeah, we also find the 6509s work very well as routers. Full routing tables, etc. YMMV. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

next blaster coming up?
by Tomas Daniska 13 Oct '03

13 Oct '03

maybe not 100% acknowledged, but still good to know From: 3APA3A <3APA3A_(a)_security.nnov.ru> Date: 11 октября 2003 г. Subject: Bad news on RPC DCOM vulnerability -------------------------------------------------------------------------------- Dear bugtraq(a)securityfocus.com, There are few bad news on RPC DCOM vulnerability: 1. Universal exploit for MS03-039 exists in-the-wild, PINK FLOYD is again actual. 2. It was reported by exploit author (and confirmed), Windows XP SP1 with all security fixes installed still vulnerable to variant of the same bug. Windows 2000/2003 was not tested. For a while only DoS exploit exists, but code execution is probably possible. Technical details are sent to Microsoft, waiting for confirmation. Dear ISPs. Please instruct you customers to use personal fireWALL in Windows XP. http://www.security.nnov.ru -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

1 0

Bell South (DSL?) network changes South Florida
by Alan Spicer 13 Oct '03

13 Oct '03

Does anyone know anything about Bellsouth network changes, possibly South Florida (or more areas involved?) affecting DSL? I remember they sent out an email recently that they were making service enhancing changes and that everyone had to add @bellsouth.net to their log-on id's, but I haven't seen or heard anything about something going on tonight. Around 11:30pm last night (Oct. 12th - EDT Florida/New York Time) my connection stopped handling data. I tried to reset it and it would not come back online. FastAccess support told me it was an outage (she answered way too fast) in the 954 area and it would be about an hour. Over 3-hours later it still will not come back online. I rebooted to Linux and ran "ethereal" and checked the packet traffic. I have a link back to the DSLAM (I believe a Mini-Ram in the DLC box right down the street) ... and it is getting this far: 1.) PADI, PADO, PADR, PADS (Session confirmation) 2.) LCP - PPP Request, Request, Ack, Ack (One for each side, this all looks good!) 3. ) PPP Chap Challenge, then my system does like 6-7 PPP Challenge Responses. It repeats this 3 times and then 3.) LCP and PADT terminated requests originating from Bellsouth.net's end (Nortel Equipment). Then my end tries again and repeats the whole process and fails again. So what is screwed up so that I can't authenticate???? I just called support again and described this ... and he says some upgrade is being done to a different link method other than PPPoE or PPPoATM, but when I asked if I had to change something since I _AM_ using PPPoE and he said no. This should all be fixed by 7am. Does anyone know what they are doing? I don't recall receiving any notification about this. And when I brought that up the guy started to say ... "...This no planned maintenance...". So what's that mean they screwed up something? Or are they doing surprise unplanned maintenance? * Is anyone else affected by this? --- Alan Spicer (a_spicer(a)bellsouth.net) Systems and Network Administration http://aspicer.homelinux.net

1 0

DCC-Exploit for mIRC 6.x
by Mehmet Akcin 13 Oct '03

13 Oct '03

yo It might be wrong place to inform, but since we might have people interested in IRC, and using mIRC 6.x, there is an exploit found. For more info visit link http://www.irchelp.org/irchelp/mirc/exploit.html Mehmet Akcin

1 0

Abuse Departments
by Andrew D Kirch 12 Oct '03

12 Oct '03

After 3 Denial of Service attacks in the last 4 days, I'm beginning to wonder if there should be a standardization of some sort of abuse departments. Or perhaps if there are some companys that should REALLY THINK (TM) about perhaps installing some. When my domain is under attack by yours, that means you've done something WRONG, and you need to take care of it, the same as I would if mine is under attack. How it's even concievable that you can operate without someone that has the authority to act on abuse 24/7 from your AS number's Org-Abuse is inconceivable. Quite frankly the FBI cares not at all about Denial of Service attacks, because if they did such attacks wouldn't happen. If I try to break into and cease the abusive actions of these hosts, I am myself committing a felony to defend my site from attack. They however don't have someone on hand to stop the attacks and quite honestly the damage of not having a connection to the internet isn't expressable simply in monatary loss. Real change needs to happen as far as accountability across the internet. If everyone's going to run windows and kiddies are going to have packetnets that extend to millions of hosts, then someone needs to be on call at large consumer ISP's to yank cords when their customers boxes get compromised, the next ISP that tells me "we'll have someone call you about that tomorrow is going to get listed on nanog, and CC'd to an ISP hall of shame somewhere of my own making. Please, please impart clue on your abuse department. Allowing hosts in your domain to participate in DoS attacks is WRONG. -- Andrew D Kirch | trelane(a)2mbit.com | Security Admin | Summit Open Source Development Group | www.sosdg.org

8 13

Re: AOL mail server problems?
by Brian Bruns 12 Oct '03

12 Oct '03

----- Original Message ----- From: Joshua Levitsky To: Brian Bruns Cc: jlewis(a)lewis.org ; nanog(a)merit.edu ; Suresh Ramasubramanian Sent: Sunday, October 12, 2003 3:10 PM Subject: Re: AOL mail server problems? > What is the PTR record for your mail server? If you don't have one or if it reads like a residential one then I've heard of that > getting blocked. Also be advised you can contact postmaster(a)aol.net or AOL Postmaster HelpDesk at 1-703-265-4670 or 1- > 888-212-5537. > Before you email or call you should try this to verify that you have a PTR and that it doesn't read like a residential. (For example >dsl081-214-123.nyc2.dsl.speakeasy.net. ) Ah yeah, we have an ameritech PTR right now (working on that problem as well). I guess I'll have one of my guys call ameritech and complain about the PTR. -------------------------- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org ICQ: 8077511

1 0

RE: BellSouth prefix deaggregation (was: as6198 aggregation event)
by McBurnett, Jim 12 Oct '03

12 Oct '03

> > IMHO, I think we should create a route-set obj like call > it... RS-DEAGGREGATES and list all the major irresponsible > providers's specific /24's in it... CASE: Business has a /24 from X provider in order to multihome. That /24 is de-aggregated from a /19, with this policy that /24 may not be routed. possible exception: When 2002-3 get passed by ARIN, this could even take on new meaning. ARIN says they will use a single /8 for the handing out of /22-/24 for multihoming end users. will you then filter those /24's also? Also: What happens when that /24 for Business Y noted above is dual routed by ISP A and ISP B, and ISP A's upstream filters but ISP B's does not? Will there be asymmetric routing? Finally: Can anyone from BellSouth, explain the end goal of the de-aggregation? I suspect with 40 + ASs they may be rebuilding their network with a recently announced list of new IP services and DSL growth as asked for under the Federal government Rural DSL regulations... (I'm not trying to defend them, just giving some possibilities) > So some ASes who wish to not accept deaggregated specifics > using RPSL can update their AS import policy to not import > RS-DEAGGREGATES... > > Just my humble opinion.. Comments/critics welcome :) > > -hc > > -- > Haesu C. > TowardEX Technologies, Inc. > Consulting, colocation, web hosting, network design and implementation > http://www.towardex.com | haesu(a)towardex.com > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > Fax: (978)263-0033 | POC: HAESU-ARIN > > > On Sun, Oct 12, 2003 at 11:26:49AM -0400, Jared Mauch wrote: > > > > On Sun, Oct 12, 2003 at 01:02:57PM +0000, Stephen J. Wilcox wrote: > > > > > > > Can anyone from BellSouth comment? What if a few other > major ISPs were > > > > to add a thousand or so deaggregated routes in a few > weeks time? Would > > > > there be a greater impact? > > > > > > one word - irresponsible > > > > This clearly stands out to me as a reason to keep and use > > prefix filtering on peers to reduce the amount of junk in > the routing > > tables. If bellsouth needs to leak more specifics for load > balancing > > purposes, fine, just make sure those routes don't leave > your upstreams > > networks and waste router memory for the rest of us that > don't need to > > see it. > > > > - Jared > > > > > > (Note: The above numbers are based on data from > cidr-report.org. Some > > > > other looking glasses were also checked to see if > cidr-report.org's view > > > > of these AS's is consistent with the Internet as a > whole. This appears > > > > to be the case, but corrections are welcome.) > > > > > > > > -Terry > > > > > > > > > -----Original Message----- > > > > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > > > > > Behalf Of Terry Baranski > > > > > Sent: Sunday, October 05, 2003 3:01 PM > > > > > To: 'James Cowie'; nanog(a)merit.edu > > > > > Subject: RE: as6198 aggregation event > > > > > > > > > > > > > > > > > > > > James Cowie wrote: > > > > > > > > > > > On Friday, we noted with some interest the > appearance of more > > > > > > than six hundred deaggregated /24s into the global routing > > > > > > tables. More unusually, they're still in there > this morning. > > > > > > > > > > > > AS6198 (BellSouth Miami) seems to have been > patiently injecting > > > > > > them over the course of several hours, between > about 04:00 GMT > > > > > > and 08:00 GMT on Friday morning (3 Oct 2003). > > > > > > > > > > If you look at the 09/19 and 09/26 CIDR Reports, > BellSouth Atlanta > > > > > (AS6197) did something similar during this time > period -- they added > > > > > about 350 deaggregated prefixes, most if not all /24's. > > > > > > > > > > > Usually when we see deaggregations, they hit > quickly and they > > > > > > disappear quickly; nice sharp vertical jumps in the > table size. > > > > > > This event lasted for hours and, more importantly, > the prefixes > > > > > > haven't come back out again, an unusual pattern for > a single-origin > > > > > > change that effectively expanded global tables by > half a percent. > > > > > > > > > > That AS6197's additions are still present isn't encouraging. > > > > > > > > > > -Terry > > > > > > > > > > > > > > > > > -- > > Jared Mauch | pgp key available via finger from > jared(a)puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My > statements are only mine. > >

2 1