- Test - lists.nanog.org

Re: i'd like to know your opinions on the com/net wildcard issue
by Paul Vixie 13 Oct '03

13 Oct '03

> > see http://sa.vix.com/~vixie/comnetsurv/ > > An incentive to take the survey: If you fill it out, it'll tell you the > aggregated results so far, which are, lemme tell you, pretty surprising. > Who knew that NANOG subscribers would anonymously admit they were > clueless? :-) that's just bad ui on my part. this is a two hour perl script and probably ought to allow people to fix their mistakes but that would be Hard, so "no."

1 0

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

13 Oct '03

Randy, Thank you very much for your feedback, I really appreciate all the comments I am receiving. Please don't hesitate to contact us if you have any more questions. Best Regards, Shazad -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: 13 October 2003 16:03 To: Shazad - eServers Subject: RE: Extreme BlackDiamond > DISTRID : 2 * Extreme BlackDiamonds with redundant routing engines. (highly > considering the BigIrons) > > AGGREG : These would be a mix of Extreme Alpines/BigIron4000 - 8000/Summit > 48i's depending on whether we are offering colo, ded-hosting, managed > services etc... > > ACCESS : Extreme Summit 24e3 or Foundry series. go with foundry. better even just as switches. extreme has weak control of software, so bugs at all levels. randy

1 0

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

13 Oct '03

Shawn, London, UK. Please don't hesitate to contact us if you have any more questions. Best Regards, Shazad eServers - driving the "e" into your business. -----Original Message----- From: Fisher, Shawn [mailto:SFisher@Bresnan.com] Sent: 13 October 2003 15:54 To: 'shazad(a)eservers.biz' Subject: RE: Extreme BlackDiamond Shazad, Where is your datacenter located? Shawn -----Original Message----- From: Shazad - eServers [mailto:shazad@eservers.biz] Sent: Monday, October 13, 2003 10:52 AM To: 'Matthew Sweet' Cc: nanog(a)merit.edu Subject: RE: Extreme BlackDiamond Matt, Yes we are that is correct. We will be offering COLO and dedicated hosting and need some serious horse-power. Right now, we are set on this..,. ROUTER : 2 * Juniper M40's, these will be connected from day one to darkfibre. DISTRID : 2 * Extreme BlackDiamonds with redundant routing engines. (highly considering the BigIrons) AGGREG : These would be a mix of Extreme Alpines/BigIron4000 - 8000/Summit 48i's depending on whether we are offering colo, ded-hosting, managed services etc... ACCESS : Extreme Summit 24e3 or Foundry series. Please don't hesitate to contact us if you have any more questions. Best Regards, Shazad eServers - driving the "e" into your business. -----Original Message----- From: Matthew Sweet [mailto:msweet@deadnet.net] Sent: 13 October 2003 15:43 To: Shazad - eServers Subject: RE: Extreme BlackDiamond Shazad, Are you going to do colocation or something like metro-area ethernet access services to office / colo buildings? The reason I am asking this is a company called Yipes (yipes.com) uses a similiar setup: Black Diamond for high-density switching and Juniper M20/40s for the routing services. I cannot say anything for the Black Diamond, except Yipes uses them. I am using Alpine 3808s and Summit 48sis, along with Juniper M10 routers at my datacenter. The Alpine switching have alot of nice features on them. If you are doing dedicated server/colocation, I would assume you need a higher density than I am needing. Anyways, just wanted to put my $.02 in. Matt

1 0

.name TLD - resolution issues
by Suresh Ramasubramanian 13 Oct '03

13 Oct '03

Hi there We operate webmail services for the .name TLD (MX and DNS resolution are handled by the nic.name people). After the recent Verisign brouhaha, several of y'all patched their nameservers to stop believing Verisign (so did we). Just that quite a few of you also seem to have set up your resolvers to do the same thing with other wildcarded TLDs. .name is a wildcarded TLD and does have legit domains on it. Right now we are seeing a lot of problems with .name domains being treated as unresolvable thanks to this, and mail from .name users is not getting through as mailservers are configured not to accept mail from unresolvable domains. I know, .name domains don't have zones or NS records attached to them - but yes, this is a legit wildcard (kind of like .museum, but this one is for vanity domains). I'd request DNS admins here to not treat .name as delegation-only. thanks --srs -- srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

1 1

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