On 08/18/2014 09:50 AM, Arie Vayner (avayner) wrote:
You may actually want to look at summarizing this. The best practice would be
to have a per-LNS pool (either locally managed or from RADIUS) and advertise
the summary from the LNS up to the network.
You may need to redistribute also connected routes for "fixed IP" services
where a user may have a custom IP from the RADIUS.
Not summarizing means that every connection (and disconnection) is a BGP update
driving your CPU utilization across the BGP domain...
The issue at the time was that there were 2 lns and the subscribers all
had essentially fixed ips in their radius profiles, and no way to ensure
they connected on the lns that also had the 'pool' with their /32 in it.
I agree however; if you can summarize then do it. But iBGP is still the
solution here either way.
Mike-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
