cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
508
Views
10
Helpful
6
Replies

eBGP and 0.0.0.0/0 via 2 different paths

fsebera
Level 4
Level 4

THE ENVIRONMENT:

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!

:

:

THE CHANGE:

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.

:

:

THE QUESTION:

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?

THANK YOU for any assistance

Frank

6 Replies 6

vmiller
Level 7
Level 7

Is there anything, say like a super block of addressess that differentiates your west coast sites from your east coast sites?

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 (1.2.3.4)       <----- Local static route with AD of 10

B   1.2.3.4/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.

:

Back to the drawing board.

Marwan ALshawi
VIP Alumni
VIP Alumni

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

HTH

if helpful Rate

HI Frank

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.

Regards

Varma

As I mentioned above this can be done only by the service provider

You need to discuss it with them you might propose using some bgp community string so they can distinguish the desired path for each location if they accept that

HTH

fsebera
Level 4
Level 4

There seems to be several solutions. The solution I implemented uses multi-hop BGP via a tunnel.

BTW, no service provider (SP) involment required or needed, the service provider dosen't even know we are running this setup, completly transparent to 'em.

Tks

Frank

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: