I'll start this out by saying that I'm frustrated enough with the final verification of this thing to publish the running configs of all relevant routers, provide shell access to production boxes, and to set up an open 48 meg 1750 inside AS 25943 with IBGP sessions to all routers involved. I *think* its running as intended - I'm having trouble with verification of my policies - this is my first 'carrier class' network.
BGP layout is like so - I own 25943 and I have admin control of the 20333 routers: AS701AS20333AS25943AS25943AS25943AS1239 AS7018--^ AS20333 (Exanium) gets service from AT&T(AS7018) and UUNet(AS701) on a 128 meg Cisco box taking full routes. The AS25943/AS1239 connecting point is also a 128 meg box taking full routes. The internal routers in AS25943 are all 64 meg 26xx, including the machine at the AS20333/AS25943 peering point. The diagram is somewhat simplified - I show one purely internal AS25943 router when there are actually two now and another two being commissioned within the next thirty days. These other boxes are actually leaf nodes from the internal AS25943 box pictured - it sits at the center of a star topology. Geographically it is somewhat complex also - the AS20333 router and its AS25943 peer are within 12' of each other, that router and the central AS25943 router are about three miles apart, and the central router and the AS25943/AS1239 peering point are about 2.5 miles apart - so no rearranging of cables for a simpler topology will be allowed as a solution :-) One of the IBGP remotes is actually multihomed with a link to the central router and a link to another undepicted 64 meg 26xx aggregation box in the same rack as the AS25943/AS1239 peering point. IP wise the following blocks are involved: 12.36.200.0/23, 12.36.210.0/23, and 12.108.204.0/22 originating from the AS20333 router. They're anchored with static routes to null0 and the owner of AS20333 is happy with the behavior as is. 63.170.237.0/24, 63.170.238.0/23, 12.108.206.0/24, and 12.108.207.0/24 are all allocated to AS25943 via Sprint or allocated to AS25943 via Exanium. The AS25943 IP allocations are deployed as individual /24s with one being given to each router insides the AS. The objective here is that if we lose a microwave link in this network the customers on the Sprint peered side will go to Sprint while the customers on the Exanium peered side will go to Exanium. As you can easily see this demands a /24 be allocated to each router and its associated customers. I've already made a mess of our first allocation, 12.108.207.0/24, so you may assume this one is the sacrifice subnet when things go wrong. It has one critical host in it (DNS) and that machine is in the same rack as its home router - the AS20333/AS25943 peering point. Its other uses are purely transit for the other subnets so its 'invisibility' in the event of network partition shouldn't be an issue. IGP wise its all OSPF with a proper backbone and at least one OSPF area allocated to each router that hosts a /24. My long term intent is to aggregate the /24s at each 'home' router and only show /24s in the backbone but for the moment 50 or so routes isn't a problem and its handy to be able to see detailed topology as I move things around in this growing network. AT&T has proven to be quite a pain in the ass to work with but I've got good service out of Sprint and UUNet - both have route filters in place to accept all the subnets involved from both AS20333 and AS25943, and engineers from both companies have gone the extra mile and provided me with the results of various show commands on their side - I believe I can present all routes to either UUNet or Sprint and have them work as expected. Now the trouble starts: I wanted to verify that my config was working so I started poking around on other systems on the net to look at the AS20333/AS25943 cluster from an outside perspective. I have access to routers in AS22325 and from there I couldn't see what I was looking for - namely paths to all subnets originating in AS20333/AS25943. I went further and used http://nitrous.digex.net, then went to http://traceroute.org. On traceroute I found the AT&T internal perspective router - an open system at 12.0.1.28 - I'm still searching for its equivalent at UUNet and Sprint so I don't have to keep hassling their engineers. I would have expected to be able to see both paths but I've had my nose stuck in Halabi this afternoon and I think I might just be a tad confused about how BGP works. If this is the case, and my prepended routes for AS25943 being sent to AS20333 are making it now further than AS20333's peers at AS701 and AS7018, HOW DOES ONE VERIFY THAT TRANSIT IS WORKING VIA A NONDESTRUCTIVE TESTING METHOD? I've contacted the peers and the information I get there seems to show that the config is doing as I expect but I've been wrestling with this for a while and I can't figure out how to confirm operation without involving someone else. I've also poked around in RADB.NET and I see that Level3 has kindly proxy registered my subnets and AS20333's subnets since I haven't taken the time to get AS20333/AS25943 a proper RADB login. This is the best proof I have that the config is working globally. So, there it is in a rather large nutshell - my first carrier BGP job and I feeling a bit overwhelmed by the whole business - anyone got any helpful suggestions? -- Neal Rauhauser CCNP, CCDP voice: 402-301-9555 mailto:[EMAIL PROTECTED] fcc : k0bsd "I've seen the angels wearing their disguise, ordinary people leading ordinary lives" - Tracy Chapman Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=52500&t=52500 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
