|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: AT&T NYC
> > > Which is exactly what you are doing when you inject nailed routes into bgp. > > > > > > So, why do you need IGP such as OSPF again? > > > > > > Alex > > > > To carry the bgp next-hops around the network? You could add in statics > > for every next-hop on every router, but this kind of configuration is > > complex and prone to errors such as loops in relatively minor cases. > > statically routing every next-hop "does not scale". Not to mention > > that many of us like the "compare igp metric" portion of the BGP decision > > tree. > > Rubbish again. > > *Every* interface that you bring up has a connected route. You redistribute > those routes into IGP. You redistgribute statics from that router into IGP. > Nail those routes into bgp and set internal community on it. > > network xxx.yyy.zzz.www mask ppp.hhh.ooo.lll route-map set-igp-community. > > > Having had the displeasure of having to deal with a network which had > > static routes as its sole igp, I'ld never want to see _that_ again. > > Thankfully, we managed to merely migrate the customers off that network, > > rather than even try to pull apart the twisty maze of static routes. > > Alex So, are you saying: 1) You should have a static route for every bgp next-hop, on every router? Including both router loopbacks and EBGP next-hops? 2) You should have a static route for every router loopback, on every router? 3) You have lots and lots and lots of iBGP sessions not only across loopbacks but between directly-connected interfaces in order to jumpstart the "real" ibgp sessions? 4) something else? And that: you don't use "closest-exit" at all, but haul traffic, wherever, around your network based upon steps below the igp-metric step in the bgp decision tree? The only thing that has been clear is that you redistribute statics into BGP, which I'm fairly certain most people already do. I'm sorry, but so far, I'm not buying how a static net is better. You seem to be trading off the complexity of automatically performing SPF, for the complexity of manually performing SPF. I'ld certainly hate to be in your Ops group when a particular path fails, requiring someone to sit with pad and paper and recompute SPF, by hand, for a hundred routers. On the up-side, the original failure might be fixed by the time the computation is about 50% complete.
|