- Test - lists.nanog.org

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

23 Jan '02

> Are there plans to release this tool you describe to the community > in the link you posted? No, we're not able to release it at this point. Still, the basic approach may be useful for other networks, especially if the parsing and the checks performed by the tool are tailored to the policies of those networks. A more general solution (parsing all configuration commands for all router products and supporting generic ways to specify policy checks) would be great, though it would be a rather ambitious undertaking. -- Jen

1 0

Re: traffic filtering
by Stephen Griffin 23 Jan '02

23 Jan '02

In the referenced message, Walter Klomp said: > As far as I know .0 and .255 are network and broadcast addresses > respectively, NEVER should a workstation be configured on these addresses, > unless something drastically changed in the RFC's for IPv4 which I am not > aware of... only on a /24. on /0 - /23 only the first .0 is network, and the last .255 broadcast. on /25-/30 it depends on where the network begins and ends. /31 has no directed broadcast. /32 is a single host and similarly has no directed broadcast. > I for one am filtering .0 and .255 at my border routers, and also rate > limiting echo at a reasonable rate... and have never gotten a complaint > about people not being able to reach or be reached... > > Walter Klomp

3 2

lost Cisco contract
by E.B. Dreger 23 Jan '02

23 Jan '02

Greetings, Anyone know how to retrieve a lost contract number from Cisco? Have a client who can't find the contract, which still has a year remaining... and Cisco isn't much help. Any ideas? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

3 2

QWest/USWest telco contact?
by E.B. Dreger 23 Jan '02

23 Jan '02

Greetings, Sorry to post this to NANOG... but does anyone happen to have a number for a clueful phone-side contact at USWest? Usual avenues aren't working well. It seems that they're giving incorrect information for roadside assistance queries. Periodically get a couple of these at home, but just got three on top of one another. (The phone number that people think they're dialing is correct; USWest seems to be giving bad 411 info.) Always from someone who called USWest for directory assistance, too. Customer emergencies in the middle of the night are one thing. Getting awakened because someone in Montana has a flat tire, however... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

1 0

(no subject)
by Matt Levine 23 Jan '02

23 Jan '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPE5olcp0j1NsDQTPEQJYtwCgrtYyZrjQneWEWqHe4lopQ+sy8mIAnRsv nD5802lqr8O6Gt4qm7bvpKMT =7LLh -----END PGP SIGNATURE-----

1 0

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