I have an OSPF network injecting default routes off the edges. All that is working well. I have two Internet ISP's, each in a physical different location. I have different /27's on each side.
We have branch routers hanging off a MOE. The branch routers have equal cost paths to the default routes. However, branchA needs to route out Internet 1 (static NAT with customerA) and branchB needs to route out Internet 2 (static NAT with customerB).
I can't change upstream costs/bandwidths, etc., because some branches don't have the static NAT's req's. Every branch on the MOE shares the same 2 paths to the Internet. I know I can give customerA and customerB two static IPs (1 from each ISP), but I am trying to avoid that...for now (still trying to persuade mgmt into using BGP...).
Is there any way to force branchA to prefer Internet 1, but still use Internet 2 as their backup...and to force branchB to default route out Internet 2?
You cannot modify the cost upstream, right? but can you add different metrics to the default routes?
I assuming you have a primary default route and a secondary default route, is that correct?
router ospf 1
default-information originate metric 10 <--- it will be preferred by lowest metric.
router ospf 1
default-information originate metric 20
So if you are announcing a default route, the branch will prefer the default route with lowest metric.
Hope it is useful
I can't do that because that would impact routing for all my branches. Some branches I need to go out Internet A, while other branches I need to go out Internet B (for most branches it doesn't matter). Each branch has the same cost to the injected default route.
I really need a way, at the branch level, to somehow control the default route. I played around with removing the default-information originate, and setup a static default route. The problem with that is it created asynchronous routing for return traffic.
Do you mean asymmetric routing and if you do how is that happening ?
Is the network in effect a L2 network ie. the next hops from the branch sites are the HQ sites where the ISPs are located ?
Take a look at the pic I attached. If I static route branch A to R1, and Internet A goes down, branch A does not know the Internet is down so still default routes to R1. The core will know from the default-information originate that Internet B is primary so it routes it via the 10gb link to site B core. That return traffic coming back from Internet B is now going back to branch A via R2.
We have L2 services from the ISP's for the links between the MOE sites and the fiber link between cores...all running L3 protocols.
Okay few things to consider here.
Firstly if you are using the other ISPs as backup for those specific sites don't you need a public IP for the NAT or are you accepting that will be unavailable while the primary link for each site is down ?
Secondly you could use IP SLA with your static route and track the availability although from your description I am not understanding why the asymmetric traffic is a problem unless you want to keep it off the 10Gbps link. It would only be a problem if the traffic exit and entered via different firewalls but that doesn't seem to be happening.
Lastly I am assuming the branch sites see R1 and R2 as OSPF neighbors. If so there is a way to set a per neighbor cost to routes but the network must be configured as an OSPF point to multipoint (which I have never used). Not sure how applicable this is to your setup but it could possibly be a solution to your problem.
Perhaps Julio could comment on that ?
Thank you Jon, As you I don't understand why it could generate as asymmetric traffic. Lowest cost over the secondary link will be preferred than the primary. And if you want to use the secondary ISP for this specific branch, @matthubach you can use PBR to set a next hop at the HQ from the incoming branch traffic to be pointing to other gateway.
could you please share the following info from the branch routers, also a diagram should be useful to have:
show ip ospf topology
show ip route 0.0.0.0
Thank you in advance.