We have HQ1 and HQ2 separated geographically via a private MPLS cloud; peering is eBGP to the MPLS provider.
HQ1 (east coast) and HQ2 (west coast) advertise the default 0.0.0.0/0 to the MPLS cloud so all remote sites can communicate with the Internet.
HQ1 and HQ2 advertise via eBGP peering, 0.0.0.0/0 to the MPLS cloud BUT HQ2 AS-path prepends the 0.0.0.0/0 route so
HQ2 is only used if HQ1 is down.
Remote sites use HQ1 as the primary gateway.
We do not have the full Internet routing table on HQ1 nor HQ2 as we are a sub-peer of a bigger organization.
All remote sites have a different private AS# and only have a single link to the MPLS cloud; while the MPLS cloud is just a single private AS#.
This setup has been working great!
Now management wants to have 50% of the remote sites utilize HQ1 as the primary Internet gateway and the other 50% utilize HQ2 as the primary Internet gateway. This make since as 50% of the sites are located on the west coast where HQ2 is also physically located.
WHAT WE HAVE DONE TO TROUBLESHOOT:
In our current setup, we advertise our internal prefixes to the MPLS cloud; the MPLS provider just passes our prefixes to each remote site. The MPLS provider does not filter, manipulate, strip AS numbers or change any of our prefixes. However, they only forward HQ1’s default route (0.0.0.0/0) to 100% of the remote peers as the 0.0.0.0/0 from HQ2 has a longer AS-path. If we remove HQ2’s AS path-prepend from 0.0.0.0/0, there is a 50/50 chance which way traffic will flow. We tried peering directly from HQ1 and HQ2 to each remote site (eBGP multi-hop; the eBGP peering is established but the internal MPLS cloud routing fails.
How can we force (in non-failure mode) the west coast sites to always use HQ2 as the primary Internet gateway while the east coast sites always use HQ1 as their primary Internet gateway? Could this be accomplished via communities? Any thoughts?
Hey Mr. Miller, Thanks for the feedback. This thought came to mind as soon as I clicked on send.
I was thinking that if I want west coast sites to use HQ2 as the primary gateway (in normal non-failed mode), I could send a specific prefix from HQ2 into the MPLS cloud. This prefix would only exist at HQ2. At each west coast remote site that I want to use HQ2 as the primary gateway, I would set a floating static route with an AD of less than 20 to this next hop I.E. ip route HQ2 prefix next hop 10.
EX ip route 0.0.0.0 0.0.0.0 HQ2_prefix 10
show ip ro
S 0.0.0.0/0 [10/0] HQ2-prefix (220.127.116.11) <----- Local static route with AD of 10
B 18.104.22.168/32 [20/0] HQ2 65000, 65550 i <----- BGP prefix with AD of 20, Primary default gateway through HQ2
B 0.0.0.0/0 [20/0] HQ1 65000, 65501 i <----- BGP prefix with AD of 20, this would provide failover.
Even through I thought this would fix the issue, it does not. Traffic will leave the my local remote-site west coast router's egress interface and enter the MPLS cloud. The PE router will perform a lookup to determine where to send this packet. Since the original destination does not exist in the MPLS cloud, this PE router sends to the 0.0.0.0/0 route I.E. HQ1, ignoring my CE routers decision.
Each remote-site router only has a single link to the MPLS cloud and my CE routers do not run MPLS, only BGP. The provider MPLS cloud controls all routing once in the cloud. We influence routing very little.
i think you need to coordinate this with your SP they might do it using BGP community stings where they can influence the path for certain sites to be preferred over others as the path selection in your case is within the SP cloud you have no control, if you have two links per remote site then you can do it using some BGP policies
Regarding this traffic requirement for the MPLS VPN Setup below is my thouhgt process.
In MP-iBGP or rather say iBGP the best path selection rule by default if the first 7 parameters match boils down to Closest IGP Hop..Now when we have two HQs one in East Cost and One in West Coast and both sending default route assuming teh ISP MPLS Backbone to be built up physically such that they have PE -Routers all along west coast cities and PE-Routers all along-East Coast Cities to connect their customers based on geographic proximity ( including your current setup), to my best understanding by default if their is no manipulation on the route west-coast will be served by West-Coast HQ and East-Coast will be served by West-Coast HQ..I don't think that East-Coast customers terminate on West Coast-PE and vice-versa and we would have direct links between East-Coast and West-Coast HQs...
I have faced this issue practically when due to misconfiguration our customers were started to being served by their respective Geographical Proximited HQs.
This is definitely a non-deterministic approach and would not guarantee a 50-50 % behaviour and depends totaly on SP's Backbone Physical and Logical Topolgy in terms of IGP metric but I stll belive there is a more fair chance of achieving what we want here..May be not 50-50 but still 35-65 or 40-60 .
Any other deterministic approach to split the traffic 50:50 between the coast I can not think of as of now but I will keep thinking on it. This approach is quite complex to handle as anypoint of time withing the SP-Cloud at any MPLS-PE they will have only 1 default-route.
As an alternative SP can match on some normal BGP communites tagged uniquely onto the default routes adverised from Each HQ and set the LP to be high per the Coast the MPLS-PE falls in to prefer that default-route from the required coast and advertise same to CEs but I don't know how feasible this will be for the ISP to do as this has to be done on a lot of MPLS-PEs inside the SP-CLoud with a list in hand on where to do what. May be we can put this requirement to ISP and ask them if its feasible from their side to be done or not.
Another approach if the HQ1 is more utilized and we want to utilize the Eat-Coast HQ equally will be to do load-balancing between the HQs for which there is a deterministic solution. If you want to consider it then I can provide my inputs for same.Again this will be done from SP Side only but way less complex as above.
Hope this helps to provide some insight in your traffic requirements.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.