Hey Neal,
> This (show ip bg ne advertised-routes) is also something I had never >used - I just always trusted the route servers for that sort of >information. Makes things much clearer. This command and it's peer, show ip bgp neighbor x/x received-routes are very helpful and show the rib-out and rib-in respectively. Especially when doing policy, it is critical to verify that you are sending what you think you are sending. Keep in mind however, the much of the route modification outbound is not show by cisco (prepends for example don't show up) which can make things a little more vague. > > > > Route server wise, route-server.ip.att.net I'm sure you've found. 701 does > > not maintain one and I am pretty sure sprint doesn't either. It would be > > really nice if they did :) Lost of ppl have told them this. There are a bunch of these out there. route-server.exodus.net still works, and there are a few more out there. A little google poking around should help. > I found 7018's route server, Sprint and UUNet must be pestered each >time you want to know what is going on inside them, and another fellow >from this list told me about this thing - its *very* handy - kind of >like what AT&T provides only with views to a large (100+) number of >ASes. > >--- IMPORTANT --- > >telnet route-views.oregon-ix.net > >--- IMPORTANT --- > > > > > > > > Troubleshooting wise, I have been bitten by ATT's policy of matching > > distribute-lists in's (routes accepted via whatever cisco means they chose) > > with ip access-group ins. In some cases, they'll take the route, but not > > the traffic. This can be a major pain to find until you get used to their > > doing that (source verification for dos/ddos prevention) > > > I found this one early on in the game. I love how accessible their >tech support is, too - I have enable on one of their peers, the peer has >me entered as an official maintainer, and they're still nearly useless. >I must say that they don't suck as badly as XO/Concentric's support, but >its close. > > > > > Solution wise, I would tend to be destructive during a maint window to > > ensure that both control and forwarding work, and beyond that, ping your > > transit providers for shots of their rib-in from you, along with a shot of > > your routes as they see them. You likely did this already and are troubled > > that you read this much only to find out that you did it all already :) > > > I am thinking a spare Cisco 1750 somewhere on net, peered with both >ASes using ebgp multihop and a private AS might just be a good solution >- apply same policies to it that I apply at the borders of the other >networks and see what comes from it. This is not a bad idea at all. > > > > At 12:17 AM 9/2/2002 +0000, Neal Rauhauser wrote: > > >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 >-- >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=52559&t=52559 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
