Been a long time I played with policy based routing, tampering with metrics etc. so want some opinions and assistance for today's best practice or what have you for a customer requirement. Dual 7604 as WAN edge in a new data center buildout each with a telco provided hi speed fiber pair. Customer has now purchased a pair of ONS boxes and are installing them between new and old datacenters and getting ready to light that dark fiber up as a DC to DC direct connection. Customer advised they want certain vlans from the DC core to use the ONS internal link as primary, and remaining vlans to use the vendor provided connection as a primary, but allow them to use the ONS connection in the event of a failure on the telco side. What is the cleanest and most efficient ways of meeting these needs today ? At first glance policy-routing comes to mind and could probably do something as simple as match an ACL with vlans to primary on ons, set next hop to be router ip at other end of that locally connected ONS link, same for remaining vlans, set next hop telco router and I assume in the event of failure in either one, the policy will be ignored when that next hop is unreachable or that interface is down, therefore following normal rules of routing and taking the backup, or only other remaining link.
Based on that "simple" scenario is that the most efficient ?? On 7604's running nearly latest and greatest code does this still require process switching as back in the day ??
ALSO, this DC has ALOT of 10gig uplinks, downlinks, sidelinks between core networking routers/switches. I remember from years back when I first started deploying gigabit that the formula used in OSPF to calculate cost for a link was based on speed of link divided by 100,000 or something close to that if memory serves. Meaning that FastE gets a cost of 10, and Gigabit, a cost of 1, but now anything above 1G my 10gig backbone in this example will also have a metric of 1 and will not prefer ten gig link over gig link. Back then we upped the default metric (forget exact command) under the ospf routing process and changed that value in which it derives its calculations. I forget what we set it to back then, just remember a couple more zero's I think but wanna know what others are using as a "standard" or "best" practice today or defacto standard if there is one for that value with us now deploying 10Gig more often and the advent of higher speed links on the horizon ?? Once again this is a new buildout and just starting to run thru and document test plan so this is the time to make the change to the OSPF process in all the 6509's running layer3 in the DC to ensure all in the area have same value.
Thanks in advance for time and assistance..
for OSPF reference bandwidth nowadays a reasonable value is 100 Gbps, the command takes the value as Mbps.
The limit is that metric value for a link is 16 bits wide so you will have 10 for a 10 giga link, 100 for a gigabit link, 1000 for a FE.
The upper limit is 65535 = 0xFF that is an unusable link you will be fine if you haven't links with bandwidth less then 2Mbps.
You may need to set manually cost on T1 links (if any). Here in Europe we have E1 so we are fine with 100Gbps reference value.
About PBR: as explained by Edison it can be done very efficiently if the supported commands are used in the route maps for the match and set action.
Modern TCAM tables have a next-hop field so implemeting PBR means setting the next-hop field in TCAM table = next-hop address configured in the route-map used for PBR. This also why a set interface is not supported in HW
to be noted if a complete segregation was required you could have used VRFs but here in case of fault all traffic needs to go via the remaining link.
You can make one link more attractive with lower metric and you can do PBR for the traffic that you want to divert on the second link on both sides.
Hope to help