- NANOG - lists.nanog.org

AS migration
by Justin M. Streiner 22 Jan '02

22 Jan '02

One of the projects I'm considering for the future is migrating our existing networks into a more unified network architecture and collapsing them into one large AS. Right now the networks I'm responsible for are networks we've picked up through acquisitions and assumed the responsibility for network management/operations. Each of the networks were running their own separate architectures (BGP, OSPF, etc) at the time we acquired them. Of those, all but a handful are still running as separate ASes with their own transit connections to ${UPSTREAMS} and private circuits back to our network. There are two key questions to answer to determine if the project is feasible and I can sell my management on it: 1) Does it make technical sense to collapse these networks into one AS? 2) Does it make financial sense to do this? The answer to 1) is yes and that the best way to migrate seems to be to migrate from the existing multi-AS architecture to one AS using confederations. This opens up a whole slew of other questions and points to consider. Some of these have been covered recently on NANOG, or in other discussion groups. * What is the most effective way to manage/control IGP expansion, especially if each regional network is already running their own OSPF implementation and meshed IBGP where needed? * Once done, I could probably disconnect some of the upstreams that I don't really need. Will the standard local-pref communities provided by the existing upstreams be sufficient to keep the network sane without requiring a great deal of manual intervention? Put another way, if I have an OC3c to upstream A in one location and a fractional DS3 to upstream A in another location, what is the best practice to keep that fractional DS3 from getting destroyed if the OC3c goes down? * The process of converting to confederations is not trivial. * Customer and upstream-facing BGP configurations for the networks that would be changing their local AS would need to be considered. * Any other significant gotchas I haven't considered? Once I answer all of the technical questions, I can begin answering the financial/administrative piece in question 2). If anyone has been through a project something like this, I'd definitely be interested to hear your thoughts and experiences. If I can make it to NANOG 24, I'll cover your beer and sushi for the night ;-) jms

1 0

RE: DNS DOS increasing?
by James Smith 22 Jan '02

22 Jan '02

I've seen DOS-type behavior where a client will query a resolver for a name that doesn't exist, and the client does not accept the answer that the name does not exist and immediately sends another query, regardless of whether or not the resolver declared itself authoritative for the negative answer. -- /ak Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP. This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have (or don't want to spend) the $$$ to do BGP, or are unable to convince their upstream to cut a hole in their CIDR block and allow a 2nd party to announce that chunk (which for some is as small as /28). James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation

4 5

RE: DNS DOS increasing?
by James Smith 22 Jan '02

22 Jan '02

-----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: Tuesday, January 22, 2002 12:51 AM To: just me Cc: Miquel van Smoorenburg; nanog(a)merit.edu Subject: Re: DNS DOS increasing? That's not the problem. It's ill-behaved clients that ignore TTL and query every 10s no matter what. See some of James Smith's posts... ----- Methinks I have been misunderstood or I have obfuscated my own point... The dns server is set to give a 10 second TTL to the dns client. The entry ages out in 10 seconds, so the client (following expected practice) ages the entry out. 15 seconds later, when they click on the next button on the web page (for example), they have to go get the IP again. This the DOS (DDOS?) like behavior. Sure the dns client is hammering the dns server, but the server is telling it to by giving out an absurdly short TTL... The server is ASKING FOR IT by setting it's TTL to 10 seconds. The client can't help it, it is just doing what it has been told. Why It Does It This Way The mechanism this dns server uses for selecting which IP to respond with is a ping to check upstream connectivity. This box pings constantly, looking for a fail. When link failure is detected, the box starts feeding DNS queries with responses from the other links subnet. The short ttl ensures that dns clients age out the info fast enough to make a near seamless failover to the other link. Since the box is authoritative for the zone, and has interfaces in more than one subnet or provider, the failure of one link means that the normal dns mechanism of going to the next responsive dns server points users to the remaining good link, and the box obliges by serving out responses that point the client back down the good link. James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation I speak for myself, and that gets me into enough trouble. (back to lurk mode...)

1 0

BGP contact at Verestar (AS11908)
by Joe Abley 22 Jan '02

22 Jan '02

Anybody happen to know contact details of a BGP-speaking NOC person at Verestar, AS11908? The usual avenues do not seem to be yielding a human response.

1 0

Re: state of the art in router configuration
by Jennifer Rexford 22 Jan '02

22 Jan '02

Ratul, > 1. how do most operators configure their bgp (text editor or some > high-level configuration tool)? I think this varies a lot depending on the network and the type of configuration change being made. Some folks work directly at the command-line interface (perhaps with some cut-and-paste from previous configs, especially for boiler-plate stuff), some use GUIs provided by router vendors for some types of config changes, others use their own scripts, and still others might use third-party commercial products like Orchestream or Goldwiretech. > 2. are there "configuration checkers" out there that would check whether > an operator has not made a common error while modifying configuration? For this, you might be interested in the paper http://www.research.att.com/~jrex/papers/ieeenet01.ps that appeared in IEEE Network Magazine in Sept/Oct 2001. The paper describes a checker that looks for inconsistencies within and across routers in an AS, by parsing and analyzing router configuration files. -- Jen

4 3

Re: DNS DOS increasing?
by Miquel van Smoorenburg 22 Jan '02

22 Jan '02

In article <cistron.171DAAD54475984F8F41345A0945DF9C39ED49(a)hqexchange.presidio.com>, James Smith <jsmith(a)PRESIDIO.com> wrote: > Get ready for more DOS-like behavior as systems get deployed that have 10 >second TTLs in the DNS. These systems are used to provide multi-isp >redundancy by pinging each upstreams router, and when a ping fails, start >giving out a dns response using the other ISP IP range. Same FQDN, new IP. So what we need is a tunable on the caching DNS server that says min_allowed_ttl = 300; if (ttl < min_allowed_ttl) ttl = min_allowed_ttl; If the above becomes a problem, this will happen. Mike.

3 2

RE: DNS DOS increasing?
by James Smith 22 Jan '02

22 Jan '02

-----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: Monday, January 21, 2002 12:08 PM To: James Smith Cc: nanog(a)merit.edu Subject: RE: DNS DOS increasing? BGP isn't that expensive. ---- For some, it is a cost that can be mitigated by "workaround" technologies that are cheaper. Of course, it could be argued that if you're not willing to make the investment to do it the BGP way, you don't really need it bad enough. Enter the salesman who is heard to tell his prospects "...you don't have the cost of BGP, you get the same effect as BGP, and you don't even have to tell your ISP!". James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation By the way, I speak only for myself, which gets me in enough trouble...

3 2

Network Security Policies
by Hauser, Dewitt C, IV (Clint), SOBUS 21 Jan '02

21 Jan '02

At the moment, we're firming up our policy on access to Networking Devices and the like. In support of this, I'm looking for any links to white papers or other such sources that discuss/support the following things: - Limiting the number of people with access - Scheduled password change/rotation - Password change when someone with access leaves I'm going to be doing research on this to drag things up myself, but I figured I would put this out here to ask to provide some narrowing down of the search and speeding it up. Thanks in advance. -- Clint Hauser AT&T Solutions

4 3

RE: DNS DOS increasing?
by Curtis Maurand 21 Jan '02

21 Jan '02

I'm not seeing this behavior with RH 7.2 128MB and bind 9.n ---- Original Message ---- From: Karyn Ulriksen Date: Mon 1/21/02 11:49 To: LIST, NANOG Subject: RE: DNS DOS increasing? RE: DNS DOS increasing?I've seen this behavior before, also. I thought it was interesting that two servers side by side recieving the same attacks/ratios only serving DNS (BIND 8.2.x*) and acted in this manner: Redhat 6.2 w/dual proc 833 512/ram started "loosing" RR records Solaris 7 on a Sparc 10 (hehe) w/256 rebooted and served the correct records I'm curious to see how other OSes react to these attacks. My guess is that BSD systems (such as FreeBSD and BSDi) will react similarly to the Solaris based on my past experience with these systems. So I am curious too see if the RR record "loss" is an OS specific behaviour, especially since Redhat has priors in misplacing information in earlier versions of the OS. * I say BIND 8.2.x, because this continued to occur through the various BIND 8.2 releases. Best regards, Karyn Ulriksen Valkaryn Internet Group URL: http://www.valkaryn.net email: valkaryn(a)valkaryn.net =========================================== "Decisions should be made in the space of seven breaths." -----Original Message----- From: Karyn Ulriksen [mailto:valkaryn@valkaryn.net] Sent: Monday, January 21, 2002 8:39 AM To: James Smith Subject: RE: DNS DOS increasing? I've seen this behavior before, also. I thought it was interesting that two servers side by side recieving the same attacks/ratios only serving DNS (BIND 8.2.x*) and acted in this manner: Redhat 6.2 w/dual proc 833 512/ram started "loosing" RR records Solaris 7 on a Sparc 10 (hehe) w/256 rebooted and served the correct records I'm curious to see how other OSes react to these attacks. My guess is that BSD systems (such as FreeBSD and BSDi) will react similarly to the Solaris based on my past experience with these systems. So I am curious too see if the RR record "loss" is an OS specific behaviour, especially since Redhat has priors in misplacing information in earlier versions of the OS. * I say BIND 8.2.x, because this continued to occur through the various BIND 8.2 releases. Best regards, Karyn Ulriksen Valkaryn Internet Group URL: http://www.valkaryn.net email: valkaryn(a)valkaryn.net =========================================== "Decisions should be made in the space of seven breaths." -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of James Smith Sent: Monday, January 21, 2002 7:08 AM To: nanog(a)merit.edu Subject: RE: DNS DOS increasing? I've seen DOS-type behavior where a client will query a resolver for a name that doesn't exist, and the client does not accept the answer that the name does not exist and immediately sends another query, regardless of whether or not the resolver declared itself authoritative for the negative answer. -- /ak Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP. This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have (or don't want to spend) the $$$ to do BGP, or are unable to convince their upstream to cut a hole in their CIDR block and allow a 2nd party to announce that chunk (which for some is as small as /28). James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation

1 0

RE: DNS DOS increasing?
by Curtis Maurand 21 Jan '02

21 Jan '02

Except that everyone complains long and hard about BGP advertising /24's or smaller. I know a small operator who's setting up a webhosting company. He's got a single T1 and a /25 for now, but as soon as he gets multi-homed ( and plans that in the next year or so) with a different provider. He'll have the need to run BGP at that point will advertise the /25 or a /24. Numbering requirements and name based hosting as is highly recommended by ARIN will be the cause. The short answer is that small companies will start advertising small blocks in the name of address conservation. We either give out addresses willy nilly or we allow the announcement of small blocks and stop complaining about it. You can't have it both ways. Curtis ---- Original Message ---- From: James Smith Date: Mon 1/21/02 12:38 To: nanog(a)merit.edu Subject: RE: DNS DOS increasing? -----Original Message----- From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] Sent: Monday, January 21, 2002 12:08 PM To: James Smith Cc: nanog(a)merit.edu Subject: RE: DNS DOS increasing? BGP isn't that expensive. ---- For some, it is a cost that can be mitigated by "workaround" technologies that are cheaper. Of course, it could be argued that if you're not willing to make the investment to do it the BGP way, you don't really need it bad enough. Enter the salesman who is heard to tell his prospects "...you don't have the cost of BGP, you get the same effect as BGP, and you don't even have to tell your ISP!". James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation By the way, I speak only for myself, which gets me in enough trouble...

1 0