I bet most of the ppl will say "no". In fact, hey, what is the point of advertising the route back to someone who knows the route better than you?
Interesting thing is, it depends. When the BGP speaker receiving the route from upstream is Multi-homed, and if it has not configured any outbound policy, it does advertise the same route back to its upstream. Of course the upstream will drop it due to AS loop prevention. I am not sure whether this is a protocol design, or something that is not well defined and Cisco implements it that way.
Such behavior has some adverse effect. The first one in mind is the unnecessary update sent back to the ISP. Imagine the ISP sends 10k route to the Transit router (in most case also customer owned), then 10K route is reflected back to the ISP. Although it is eventually dropped, it does waste processing power and may potentially trigger alerts unnecessarily.
I was hit by the second adverse effect when i am doing a design mock up for customer's MPLS VPN in campus. The simplified version of the network looks a bit like this:
The interesting thing here is that to fulfill MPLS PE/CE route exchange requirement, PE2 has to enable feature allow-as-in (assuming CE 1 is the fusion router routing all VRFs), this breaks the AS loop prevention mechanism. Together with the fact that the VPN routes from remote site are all iBGP routes which is by default very much less preferred, a routing oscillation is observed when CE1 sends the same route back to its upstream (PE1) under the same VRF. Of course the remedy is not that much of rocket science. Just tag the outbound routes from PE2 using any means and configure outbound filter on CE1 to stop the same route under the same VRF from sending back to the MPLS BB will do.
But if you have logging console debuging turned on (mostly default), be prepared to see 99% CPU utilization when you leave the deb BGP update on. :D That should wet quite a lot of pans if it is production
No comments:
Post a Comment