Hi Mike,
On 29 August 2010 12:30, Mike <[email protected]> wrote: > Hello, > > I have a BRAS terminating many pppoe sessions (>2000 lets say). I would > like to allow my bras to participate in OSPF and I am wondering what the > collected wisdom about doing so is. I want to be able to assign some of > these sessions fixed subnets for example, and this is one motovator. Another > is that even for connected interface addresses, I sometimes want special > routing (eg: instead of core -> bras -> end user, I may want core -> > intermediate -> bras -> end user) which I can use ospf to override. Has > anyone done this and has anyone any references where I might see an example > or some documentation on pitfalls and so forth? A few things can affect you're outcome (especially the stability of the PPPoE sessions) but generally I would advise against using OSPF in this scenario. The main reason is the fact that every single time a session is established or dropped the whole OSPF area has to re-run SPF algorithm, depending on the hardware involved this might or might not be a big problem. Next thing is scalability - if you expect significant growth in number of routes - I'd suggest you move to BGP, OSPF is likely to get slower as number of routes increases. The last reason is ability to control routing - we use BGP communities to mark various prefixes so the other devices can make a decision how and where to re-advertise particular routes, OSPF gives you some abilities as well, but not as extensive as BGP. We run a setup with multiple BRASes, some with over 40k subscribers. We use ip pools on the devices, with dynamic IPs allocated from those pools. BRASes only advertise the aggregate pool routes to limit the number of prefixes seen by the rest of the network. Only customer that have static IPs or networks get 'advertised' into the rest of the network. We use BGP between the BRASes and the rest of the network, our BRAS is a PE and for 'special' routing needs we place the PPP sessions directly in to the VRF that provides the expected connectivity. kind regards Pshem _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
