If you generate your BGP routes on your edge router (e.g. redist, network statements), then they would override any eBGP routes you receive from outside. But putting that aside, it would be strongly recommended to filter all local routes so you don't receive them from your upstreams.
You might also want to confirm that your upstreams are not running JunOS facing you - as I mentioned in the thread (URL) I referenced yesterday, I'm told that by default JunOS appears to 'look ahead' and not send routes that would cause an as-path loop, so your allow-as in wouldn't do anything. I have no idea if that's behavior that can be changed, and I'm happy to be schooled by a JunOS guru on that one if I'm wrong. j. From: Randy McAnally [mailto:[email protected]] Sent: Thursday, September 03, 2009 9:38 AM To: Herbert, John; [email protected] Subject: RE: [c-nsp] BGP multihop between two sites No, I think you understand it perfectly. The goal is to have 'stateful knowledge' of my own eBGP routes, using the simplest most resilient and cross-platform compatible method. What would be the caveats of the neigbor x.x.x.x allowas-in? It seems too easy, there HAS to be a catch! :) Do I need to change my inbound filters? Right now I am not filtering inbound routes from the directly connected Tier1's. -- Randy ---------- Original Message ----------- From: <[email protected]> To: <[email protected]>, <[email protected]> Sent: Wed, 2 Sep 2009 21:42:22 -0500 Subject: RE: [c-nsp] BGP multihop between two sites > Ah I think I see. Assuming you have no default route learned via eBGP then > (given 3 full routing tables, that's probably a fair assumption), the > question becomes whether you can intelligently maintain a floating static > default based on reachability to the next-hop IP, or if it's better to > implement some kind of BGP peering between the two sites. > > One possibility might be to consider a conditional static default route - use > "ip sla" to test next hop reachability of a provider's router, then use the > track command to monitor and apply to a floating default route (and of > course, you can do this for more than one provider and provide a > predetermined sequence of alternate default routes) > > I am not personally a fan of iBGP "raw" over a public network (and that's > what it would be since the ASNs are the same on both ends), as most of the > protection features in IOS are focused on eBGP. GRE tunnel works, though > there may be caveats depending on MTU/fragmentation issues and hardware > switching support. Maintaining those BGP peers of course assumes that the > remote IP in each case is known in one of the active eBGP sessions at all > time. Probably a reasonable assumption if you're using provider-owned IPs to > peer; maybe less so if you're using IPs that fall within your own larger > block. > > I may be misunderstanding something about your particular topology, so my > apologies if so. > > John. > > ________________________________ From: Randy McAnally [[email protected]] > Sent: Wednesday, September 02, 2009 21:10 > To: Herbert, John; [email protected] > Subject: RE: [c-nsp] BGP multihop between two sites > > > > I'm not quite clear on the floating default? What is it floating "over"? If > > you are receiving a default in BGP, > > then are you / can you receive it from multiple providers for resiliency? > > And if so, under what circumstances > > is the floating static ever active in your routing tables? > > It's a high distance static default route in place, to keep packets flowing > in case of an eBGP malfunction. In this case, it was routing packets between > locations because the prefixes were not in the routing tables. This was not > discovered until the provider the default pointed went down. > > -- > Randy > > > ------- End of Original Message ------- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
