- NANOG - lists.nanog.org

Looking glasses with programmatic interface?
by Stephane Bortzmeyer 23 Jan '02

23 Jan '02

I'm surprised to see that every looking glass I know is only reachable via an interface made for humans, not for programs. When you want to query the LG via a program (for instance to monitor your routes on a distant LG), you need to emulate an human being and parse HTML (or sometimes Cisco text) replies. Does anyone operate looking glasses with an interface made for programs such as XML-RPC <URL:http://www.xml-rpc.org/>, SOAP <URL:http://www.soapware.org/>, Java RMI, Corba (no, I'm joking) or Microsoft COM (joking again)? What do you think of a standard XML-RPC API for looking glasses?

5 5

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

23 Jan '02

hey justin, 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). 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 consolidating your news server farms or mail server farms. One approach on the BGP front 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. 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. That's a start. my 0.02 cents worth. Btw, if you make it to nanog, make sure to grab josh fleishman/jeb linton of mindspring/earthlink a line. They also went through a big AS consolidation a few months ago. Miguel de Leon Dimayuga God does not ask us to be successful, Networks & Technologies only to be faithful. Cbeyond Communications -Mother Teresa of Calcutta

3 2

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