Three default routes out of WAN - how to route out via location

[michael.mastropaolo]

I will try to keep this simple.  We are looking to redo our WAN which peers with another WAN that we own (different ASNs).  We'll call these WAN1 and WAN2.  These span across the nation for arguments sake.  We have 3 eBGP peers throughout the nation.  

If WAN2 were to advertise a default route to WAN1, is there a way to have it so edge gear will route out based on location?  For example, lets say one peer is in NYC and another one in Denver.  A server in Florida would route out the NYC default route because it's the best path, where as a server in California will route out the Denver one, but also provide redundancy should one of them fail.

As mentioned, and i'm not sure if this complicates things, but we need to have 3 peers.

Any help would be appreciated.  Thank you.

[Muhammad Uzair]

Since I am not fully aware of your network topology, my best guess is to use IGP metric for the best path selection if all the previous criteria are same (Local preference, Origin Type, AS Path Lenght and MED) if you need further assistance you can share your network topology for better understanding.

Thank you.

Kindest regards,

uzzi

[michael.mastropaolo]

Thank you for the reply.  I uploaded a quick diagram to (hopefully) help illustrate the network.  Let me know if you have any further questions.  I appreciate it.

[Georg Pauwen]

Hello,

I can't tell from your diagram what routers are involved and what they are peering with. If you receive three default routes on the same core router, you can use the weight attribute in conjunction with a route map to influence which default route is chose (you obviously need the 'maximum-paths 3' command as well, and likely also the 'bgp bestpath as-path multipath-relax' command). 

Can you refine the diagram to include the actual routers and the actual peering between them ?

[michael.mastropaolo]

Hi.  I just uploaded it again.  I hope it's more clear.  Let me know if you have any questions.  Thank you for your time.

[Georg Pauwen]

Hello,

so, as you said in your initial post, Florida and California are routers in the core ? How are they peering with the other routers in the core ? What I meant was a diagram with all actual routers and connections.

[michael.mastropaolo]

The Florida and California mentions is just edge gear (servers).  Sorry for the confusion.  I wrote this up on several different sites and each description was tweaked so I initially thought I just used fictitious locations not based on my real topology.

We have 3 eBGP peering points, 1 in NY, 1 in Philadelphia and 1 in Denver.  The network is very complex.  I could get a diagram together, but just the core alone is rather big with a partial mesh design/connections all over.  Then when you get to the distribution layer and edge, we have apps that keep track of the design as it's way too large to manage.  It's roughly 4 to 5,000 devices.  That's why I just put the rest of the core in a cloud, for simplicity sake.  If you need me to break out the core, I can for sure.

[Muhammad Uzair]

As per your diagram and discussion above there are 2 solutions.

(1) Every router in core (18 routers) should have these 3 default routes (coming from ISPs) and you can redistribute these default routes into your IGP (OSPF, ISIS) and they will propagate within your internal network and forwarding decision will be done as you require (nearest path) with redundancy..

(2) You can make BGP peering between each router to 3 ISPs (18 into 3 = 54 This is surely complex but will surely work) now it depends which one is feasible for you, both can fullfil your requirement.

Thank you.

Kindest regards,

Uzzi

[Muhammad Uzair]

Correction please, in second solution it should be iBGP with your 3 edge routers (18 into 3 = 54).

Thank you.

Kindest regards,
uzzi

[michael.mastropaolo]

Thanks for the reply Uzzi.  I understand solution one as you laid out.  What i'm not familiar with is, which default route would be preferred?  You state that the forwarding decision will be done per nearest path with redundancy.  Is that a 100% statement?  I don't understand how that routing logic would happen based on the BGP best path algorithms.

The second solution wouldn't work for us unfortunately.  I'll keep it in my back pocket as a last resort though.

I appreciate the assistance :)

-Michael

[Muhammad Uzair · Accepted solution]

Surir it will not take routing decision based on bgp the decisoon will be taken on IGP path cost as we redistribute the default route from ebgp into IGP even if on a core router the default route exist in both IGP and Ibgp routing table, igp path will be preferable since IBGP admin distance is 200 which is greater than commonly used IGP (ospf, isis, rip). The only thing that's need to be assured (depending on your IGP topology) that all 3 redistributed default routes from WAN 2 are visible with their respective IGP cost on all your internal routers.

Kindest regards

Uzzi

[michael.mastropaolo]

I appreciate the assistance Uzzi.  This, along with another reply, will be implemented and we shall see how everything works out.  Thank you again.

[Muhammad Uzair]

You are most welcome sir.

Kindest regards

Uzzi

[Deivid85_]

Hello,


Regarding your first post, I would use local-preference to announce to your router in Florida a higher LOC_PREF for the default route advertised by the NYC router and a lower one for the default route advertised by the Denver router for redundancy.


Regarding California server, I would use again local-preference to announce to your router in California a higher LOC_PREF for the default route advertised by the Denver router and a lower one for the default route advertised by the NYC router for redundancy.


Do not use weight because it is router local attribute (It is not included on the BGP updates) because you need to propagate different route priorities" for the sake of the redundancy. Set iBGP for those nodes such as NYC and Denver in which you need this redundancy but it would be advisible to establish a iBGP full-mesh to avoid suboptimal routing.

[michael.mastropaolo]

This most likely would work for egress traffic.  I say most likely because I would need to REALLY deep dive and work out how the core would receive these default routes.  The main 3 sites outlined in my diagram have the bulk of the edge hanging off of them, with the other routers having mainly mcast traffic and some edge gear...minimal though (in the grand scheme of things).

I didn't want to include the core because it would just complicate things and I wanted to try and lay out a scenario with everyone as simply as possible.

I like the input.  Much appreciated.  

The NEXT question now is, is there a way we can ensure symmetrical routing for ingress?  

The problem i'm having with this is, if we have a /14 and 2 /16's, as in the diagram, they are broken up (not very smartly) all over WAN1 (64002 in diagram) so we can't really be more specific, plus, the goal was to not TRY to be more specific either.  Any ideas here?  :)

-Michael