January 2002 - Test - lists.nanog.org

RE: AS migration
by Miguel de Leon Dimayuga 22 Jan '02

22 Jan '02

> I'm also looking at it from the perspective of making peering > with various > providers or in various exchanges a more compelling business > driver, as > opposed to putting all of the $$ into transit. Yes, definitely. That's one of the main drivers to merge AS'es as well. Consolidating AS'es means aggregating the traffic in a single AS. That's a "GoodThing"TM as far as maintaining and establishing peering sessions. On the transit side, consolidating AS'es allows you to rationalize your transit connections and take out redundant links in a market to the same provider and maybe even afford a distinct backup provider for each market. > Most of the service/server consolidation has already been done. I assume, then, that connectivity between your AS'es are via private lines and not through common transit providers. That's usually one of the other things that is necessary to start on this project. make sure your AS'es are well connected to your chosen surviving AS.... and of course, convert one AS at a time ;) heehhe > > One approach we took before merging AS'es is to make > > sure you have a common local pref and community > > infrastructure among the AS'es you want to merge. > > attempting to go confeds with mismatching local pref > > and community based policies might be a headache. > > I designed both for all of the other ASes so they're all similar in > design. awesome! =) you should then be able to set the proper communities and route-maps between your confederations to make sure that you spill routes across your own AS'es in a controlled manner. Through prepending and local pref tweaks, you should have the ability to make sure you don't overwhelm that DS-3 vs OC-3 to upstream A when you start merging networks. The more automated you make the ability to prepend or change local prefs or filter announcements to peers on a per route basis, the easier the migration will be. You can "automate" this process by having the necessary communities, community-lists and route-maps already in place. Once done, all you need to change the way a network is announced is by attaching a community to it. this is "automation" is necessary to ease control. > My big concern is controlling IGP growth as a whole. Each of the ASes > is running their own independent OSPF implementation. > Dealing with all of > those disjoint backbone areas and rolling them into one AS while > minimizing/eliminating service disruptions for my customers has been a > source of constant brow-beating. Start to look deep into your OSPF implementation and try to minimize the routes in your area 0 via summarization. you can also look into what's in area 0 now in your AS'es. do all the devices in area 0 now have to remain in area 0? can you some of these devices live in a new stubby or even NSSA area? The less routes in area 0, the smaller the number of routers in area 0, the more conceptually and practically easy it is to follow/monitor/verify when you merge backbone areas. Not to mention that its probably good practice. Hope this helps =) Miguel =) Miguel de Leon Dimayuga God does not ask us to be successful, Networks & Technologies only to be faithful. Cbeyond Communications -Mother Teresa of Calcutta

1 0

Need help of a UUNet Guru
by P R 22 Jan '02

22 Jan '02

Can someone from UUNet contact me off list? Im having a problem with a route announcement that is either being sourced from your AS, or is being propagated by your AS. Peter Rohrman _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

RE: AS migration
by Justin M. Streiner 22 Jan '02

22 Jan '02

On Tue, 22 Jan 2002, Miguel de Leon Dimayuga wrote: > Collapsing AS'es has its technical benefits, ultimately > resulting in financial benefits. For starters, you'll > be able to manage your transit traffic better (and thus > grow your pipes in a more sane manner). I'm also looking at it from the perspective of making peering with various providers or in various exchanges a more compelling business driver, as opposed to putting all of the $$ into transit. > You'll also be able to control your inter-AS traffic much > better (especially if you plan to eventually collapse and > use common servers/services across AS'es). An example of > this is collapsing your news server farms or mail server > farms. Most of the service/server consolidation has already been done. > One approach we took before merging AS'es is to make > sure you have a common local pref and community > infrastructure among the AS'es you want to merge. > attempting to go confeds with mismatching local pref > and community based policies might be a headache. I designed both for all of the other ASes so they're all similar in design. > On the IGP front, make sure that your private networks > are distinct among AS'es. Once you merge OSPF entities, > you could have duplicate 192.168.x.x spaces. My big concern is controlling IGP growth as a whole. Each of the ASes is running their own independent OSPF implementation. Dealing with all of those disjoint backbone areas and rolling them into one AS while minimizing/eliminating service disruptions for my customers has been a source of constant brow-beating. > That's a start. my 0.02 cents worth. Much appreciated. jms

1 0

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 21 Jan '02

21 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