Lobo wrote:
This customer's requirements for bandwidth can be met if they use the local connection only but should the connection go down, they would most likely saturate the intercity connection and impact everyone else. What has been proposed is that they will use the local connection to get internet access and should this access go down, they want the bgp session to be dropped or something equivalent that will make sure they don't go over the intercity.
We have the ability to do this in our network through the use of communities. We'd tag the customer's incoming routes with our-ASN:2XX02, and the trailing '2' would tell the local city to advertise it (by matching the XX POP code) and the remote cities to not advertise it (by not-matching the XX POP code). We'd selectively filter what routes we sent to the customer by limiting them to our-ASN:2.... (any customer in any POP), our-ASN:3.... (our routes in any POP), and our-ASN:4XX.. (upstream routes in this POP). In this case, the session wouldn't go down, but the customer's routes wouldn't go to other markets (and therefore out the main upstream connection), and the customer would only receive external routes from the local connection(s).
We do this by sticking a coded community on EVERY route that goes into BGP at the point that the route enters our BGP mesh. We redistribute connected and static routes into BGP through a route-map, and apply an inbound route-map to all BGP neighbors, then "send-community" to the rest of our iBGP mesh. The coded community is our-ASN:ABCDE, where A represents the type of route (customer, ours, upstream), BC represents the POP number (I sorted them alphabetically; any new POPs just go on the end of the list), D represents how strong/weak we want the traffic to come in (useful by customers who want to use us a little less or as pure backup), and E signals our georouting (MED) logic (0 means bring it in through any POP, 1 means steer it towards the nearest POPs, 2 means this POP only). It's worked exceptionally well in a huge variety of scenarios, and I'm painfully having to extend it to our parent network now that we've been acquired.
pt _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
