- NANOG - lists.nanog.org

Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

I have 2 core routers (CR) and 3 access routers (AR) currently connected point-to-point where each AR connects to each CR for a total of 6 ckts. Now someone has decided to connect them with Gig-E. I was wondering about the benefits or disadvantages of keeping the ckts each in their own individual LANs or tying them all into one VLAN for a "Transit LAN" as those folks that decided on going to Gig-E aren't doing any logical network architecting (is that a real word?). Anyone got any suggestions, comments or helpful hints? Thanks, scott

12 15

Re: Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

----- Original Message Follows ----- From: "Stephen Sprunk" <stephen(a)sprunk.org> To: "Patrick W. Gilmore" <patrick(a)ianai.net> Cc: "North American Noise and Off-topic Gripes" <nanog(a)merit.edu> Subject: Re: Transit LAN vs. Individual LANs Date: Sat, 25 Feb 2006 13:56:37 -0600 > Thus spake "Patrick W. Gilmore" <patrick(a)ianai.net> > > On Feb 24, 2006, at 9:03 PM, Scott Weeks wrote: > >> I have 2 core routers (CR) and 3 access routers (AR) > >> currently connected point-to-point where each AR > connects to >> each CR for a total of 6 ckts. Now someone > has decided to >> connect them with Gig-E. I was > wondering about the benefits >> or disadvantages of > keeping the ckts each in their own >> individual LANs or > tying them all into one VLAN for a >> "Transit LAN" as > those folks that decided on going to Gig-E >> aren't doing > any logical network architecting (is that a >> real > word?). > > > Personally, I like the to KISS, so one big 'transit > LAN'. > > ITYM two big transit LANs -- one must be prepared for a > switch to fail. These're going to be router-to-router connections (each AR is connected to both CRs) and I had thought about tying them all into one VLAN vs. PTP Gig-E. I was just trying to find out the operational benefits of either design. scott

2 1

Re: Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

> --On February 25, 2006 11:04:12 AM -0500 "Patrick W. > Gilmore" <patrick(a)ianai.net> wrote: > > On Feb 24, 2006, at 9:03 PM, Scott Weeks wrote: > > > >> I have 2 core routers (CR) and 3 access routers (AR) > >> currently connected point-to-point where each AR > connects to >> each CR for a total of 6 ckts. Now someone > has decided to >> connect them with Gig-E. I was > wondering about the benefits >> or disadvantages of > keeping the ckts each in their own >> individual LANs or > tying them all into one VLAN for a >> "Transit LAN" as > those folks that decided on going to Gig-E >> aren't doing > any logical network architecting (is that a >> real > word?). > > In my experience either solution has tradeoffs and the > correct one depends greatly on your traffic patterns. > Having said that, what I find causes most of the problems > in either solution is when the Layer 3 topology starts to > diverge from the Layer 2 topology. Hi Guys, Apologies for the late response, I had to do an unexpected outer island trip and got back late last night. I am just using OSPF area zero between the CRs and ARs. So, it's full mesh over a LAN if I do the "transit LAN". Is that what you're referring to? Could you elaborate? Thanks, scott

1 0

Re: DNS deluge for x.p.ctrc.cc
by Barrett Lyon 27 Feb '06

27 Feb '06

I thought I would chime in quickly, one of my customers has been one of the targets of this attack. The x.p.ctrc.cc DNS server was shut down on the 15th, the response itself had a 360000 TTL so that should be expired by now. On this end of it, the largest traffic spike we received was around 8 Gbps. The last time we saw this traffic was on the 21st around 2 GMT with traffic at about 2 Gbps, it has lost a lot of steam. If you see unusual DNS traffic to AS32787 or 72.52.0.0/18, chances are it is part of this attack or the attacker setup a new RR to query against. I've yet to see a copy of the malware that is doing the spoofed queries itself. If anyone has it, I would like to take a look. Thanks and I am really impressed with everyone's reaction to this attack. Especially Rob Thomas, he really has a grip on it. Cheers, -Barrett

2 1

Re: DNS deluge for x.p.ctrc.cc
by Rob Thomas 27 Feb '06

27 Feb '06

Hi, NANOGers. ] other cctld servers have seen what are effectively ddos. rob thomas ] seems to have the most clue on this, so i hope this troll will entice ] him to speak. Did someone say "troll?" :) Yes, this is a real problem. These attacks have exceeded several gigabits per second in size, and during one attack 122K DNS name servers were abused as amplifiers. Ouch! This abuse can be mitigated. Here are a few tips. Limit recursion to trusted netblocks and customers. Do not permit your name servers to provide recursion for the world. If you do, you will contribute to one of these attacks. Watch for queries to your name servers that ask for "ANY" related to a DNS RR outside of the zones for which you are authoritative. This DNS RR will be LARGE. Limit UDP queries to 512 bytes. This greatly decreases the amplification affect, though it doesn't stop it. Scan your IP space for name servers that permit recursive queries. It's amazing just how many of these name servers exist. Refer to the following guides for some excellent insight and suggestions. <http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf> <http://cc.uoregon.edu/cnews/winter2006/recursive.htm> <http://dns.measurement-factory.com/surveys/sum1.html> Note we have our own Secure BIND Template which will help on the BIND side of life. <http://www.cymru.com/Documents/secure-bind-template.html> If you need assistance with any of this, have endured one of these attacks, or have any other questions, please don't hesitate to ping on us at team-cymru(a)cymru.com. We're here to assist! Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);

13 17

Re: DNS deluge for x.p.ctrc.cc
by Paul Vixie 27 Feb '06

27 Feb '06

i'd writ: # > speaking of which, f-root has about 35 nodes world wide, and about a third # > to a half of them aren't reachable by udp/161, and the blockage is not in # > our immediate neighbors but rather on transit paths. this is due to the # > cisco snmp vulnerability five years or so ago. filtering in the core to # > protect vulnerable edges has to be done a LOT more carefully than that. # > (BCP38 is an example of how to do it well, but apparently impractically?) someone followed up anonymously: # Filtering UDP/161 and TCP/161 directed towards -one's own infrastructure- is # a BCP, irrespective of SNMP vulns, etc. It should of course be allowed to # transit for folks who insist on doing SNMP across 'the Internet', but in # reality, one ought not to be allowing this at all. A lot of folks didn't # understand or didn't take the time to incorporate this into organized iACL, # and so ended up blocking it for transit traffic, as well, unfortunately. "yum." (folks who control backbone router meshes without fully understanding the impact of changes they make or time to fully digest and incorporate BCPs.) # Yes, filtering ports is a losing proposition (how long until all 64K of TCP # and UDP are filtered, heh?), but in this case, there's a practical reason to # do so, at least for traffic ingressing towards one's own devices. i just don't agree that filtering ports on internal infrastructure access buys anything. the boyz who run ISC's network filter by source-IP. that means if somebody needs to SSH to one of our routers they have to be coming from some fairly nearby/trusted place. i believe this is also what UUNET does, and it's what we were doing at MFN as of the time i left. i thought THAT was a BCP? after all, the combination of not letting outsiders spoof your internal IP range, and not letting your customers spoof IP ranges not assigned to them, ought to make IP ACL's containing internal source addresses fairly dependable?

1 0

DKIM for ISPs
by Dave Crocker 24 Feb '06

24 Feb '06

Folks, Prior to the MAAWG meeting in San Francisco, next week, there is a breakfast planned for any ISP folk wishing to learn more about DKIM. It will be at 7:30-9am, 1 March. We are seeking to gain adoption and use sooner, rather than later. Please see: <http://www.dkim.org/breakfast.pdf> for details. Please pass this note to anyone you feel might be interested in hearing about it. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking <http://bbiw.net>

1 0

Dallas meeting stats
by Susan Harris 24 Feb '06

24 Feb '06

NANOG 36 February 12-15, 2006 Dallas Host: Yahoo ---------------------- Total attendance 338 Women attendees 6% NAPs represented 11 (5 outside N. America) Univ./Colleges repr. 14 Non-US/Canada/Mexico attendees 41 Attendee occupation breakdown: Vegas Seattle LA Dallas ----- ------- --- ------ ISPs/NetOps 44% 50% 42% 45% Hardware vendors 20% 15% 13% 13% Software vendors 3% 4% 3% 4% R&E 11% 9% 10% 11% Government 4% 3% 3% 2% Consultant 4% 3% 3% 5% Content provider 3% 4% 4% 6% Other 11% 12% 22% 14% (IXPs, registries, misc.) Maximum RealMedia streaming participants: 72 Support: Meeting coordination: Merit Network Host: Yahoo Squid, DNS, DHCP: Measurement Factory Multicast, v6 feed: Merit Sponsors: Arbinet, Arbor, Cariden, Cisco, Foundry Juniper, Renesys, Tellabs PS - what else would you like to see in this report?

1 0

DNS deluge for x.p.ctrc.cc
by Estes, Paul 24 Feb '06

24 Feb '06

We have recently noticed a deluge of DNS requests for "ANY ANY" records of x.p.ctrc.cc. The requests are coming from thousands of sources, mostly our own customers. There are currently no records for x.p.ctrc.cc, or even for p.ctrc.cc. A google search for x.p.ctrc.cc comes up with only 2 hits. One is a DNS log showing references to this name. The other one shows that somebody else is seeing the same behavior as we are: http://weblog.barnet.com.au/edwin/cat_networking.html However, this site has the benefit or providing a history that p.ctrc.cc had (a week ago) delegated NS record pointing to 321blowjob.com. At that time, 321blowjob.com's nameserver was responding with a TXT record for x.p.ctrc.cc. It would appear that ctrc.cc was the victim of some DNS hijacking. Whatever malware is attempting to lookup this name, however, is doing so at a horrific rate. I have some addresses that have made >250000 requests for this name in a short period of time. I was thinking that I could simply put an authoritative zone for p.ctrc.cc in our nameservers and return something for the lookups, however based on the writeup on the above mentions blog, I am now not certain this will have any effect. As you'll note, that individual had only 2 machines hitting his name server, and even though a response was provided to the lookup, the hosts continued to hammer his access link. When the lookup flood occurs, every host starts at the same time, as can be seen on the graphs of traffic to and load of our nameservers. It's all or nothing - the flood is either on or off. There's no background trickle. Is anybody else seeing these events? --Paul

6 7

RE: DNS deluge for x.p.ctrc.cc
by Estes, Paul 24 Feb '06

24 Feb '06

Actually, what we are seeing does not appear to be an amplification attack. It appears to be a request flood from infected machines. We have anti-spoofing filters on our upstream connections as well as our subscriber's access lines. The source addresses are not spoofed. They are valid subscriber source IP's. Based on some cached entries I have found in other nameservers, CTRC.CC was apparently hacked and was delegating a number of subdomains to another nameserver that was issuing the 4K TXT record. The delegation has now been removed, and the nameserver they were delegated to appears to be offline. --Paul -----Original Message----- From: william(at)elan.net [mailto:william@elan.net] Sent: Friday, February 24, 2006 9:47 AM To: Estes, Paul Cc: nanog(a)merit.edu Subject: Re: DNS deluge for x.p.ctrc.cc On Fri, 24 Feb 2006, Estes, Paul wrote: > We have recently noticed a deluge of DNS requests for "ANY ANY" records They are trying to abuse similar holes that caused most of us add "no ip redirects" and "no ip directed broadcast" to routers, but this time its about dns > of x.p.ctrc.cc. The requests are coming from thousands of sources, > mostly our own customers. Why am I not surprised .... > There are currently no records for x.p.ctrc.cc, or even for p.ctrc.cc. http://www.completewhois.com/cgi-bin/whois.cgi?query=28242102&options=re trieve I don't think this is a hacker-setup domain, probably their dns servers were at some point hacked. They are associated with legacy ip block 192.238.16.0/21. It is also notable that CTRC.CC A record points to 192.168.202.72 > A google search for x.p.ctrc.cc > comes up with only 2 hits. One is a DNS log showing references to this > name. The other one shows that somebody else is seeing the same behavior > as we are: > > http://weblog.barnet.com.au/edwin/cat_networking.html > > However, this site has the benefit or providing a history that p.ctrc.cc > had (a week ago) delegated NS record pointing to 321blowjob.com. At that > time, 321blowjob.com's nameserver was responding with a TXT record for > x.p.ctrc.cc. > It would appear that ctrc.cc was the victim of some DNS hijacking. > Whatever malware is attempting to lookup this name, however, is doing so > at a horrific rate. I have some addresses that have made >250000 > requests for this name in a short period of time. > > I was thinking that I could simply put an authoritative zone for > p.ctrc.cc in our nameservers and return something for the lookups You might want to consider returning the same thing in lookups as ctrc.cc themselves have for direct A lookups... , [snip]

2 1