Opinions on Policy type routing solutions

Answered Question
Jun 22nd, 2010

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..

Dave

I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 6 years 5 months ago

Hello Dave,

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

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Edison Ortiz Tue, 06/22/2010 - 14:44

PBR remains as the solution for source-based routing.

In order to have PBR with hardware assist  for route-map sequences that use the match ip addressset ip next-hop, and set ip  default next-hop PBR keywords.

Any other match|set statement will be performed in software.

Regards,

Edison

DAVE GENTON Wed, 06/23/2010 - 14:11

Thanks !  Much appreciated, that's what I need, how to do it, yet avoid process switching.

dave

Correct Answer
Giuseppe Larosa Tue, 06/22/2010 - 23:50

Hello Dave,

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

Giuseppe

gatlin007 Wed, 06/23/2010 - 07:38

Having untangled PBR disasters in several networks I’m biased and believe PBR should only be used as a break-fix action and immediately replaced with a predictable, scalable and supportable solution.  With the availability of VRF technology on most Cisco layer 3 platforms the need for PBR disappears.  IP networks should always route based on destination address in order to be supportable  The moment we start routing based on source address we lose degrees of predictability.  Our life expectancy as engineers is tied directory to our ability to predict the affect a change has across the entire enterprise network.


Chris

DAVE GENTON Wed, 06/23/2010 - 14:14

Completely agree, and have done such a good job at avoiding PBR for so long, shows by having to post it for opinions and direction due it being so long since I have had to.   In the entire 10 years since I passed the CCIE lab, and several prior to that I have worked in the Enterprise environment exclusivley, with very little exposure to service provider space either as a customer or as an employer, and they typically have the reasons for breaking the rules of routing protocols whether valid or not, they find a reason and do it

thanks

dave

DAVE GENTON Wed, 06/23/2010 - 14:23

Thanks for the time, investigated fully and understand, much appreciated.  I see there's no defacto standard, but what you pointed out is the general best value to choose logically based upon the 16 bit limitation for that field and that while allowing for room to grow beyond our current 10gig links by it's calculated cost being 10, leaves us wiggle room while cutting the low end off at 2MB links which are going to the way side.  Much fewer slow <2MB links to manually configure to properly cost to prefer a T1 over a fractional T1 or I suppose still possible, a serial 9.6k circuit of some type, each of which would equal the max of 65535 with the new auto-cost reference-bandwidth value added.  In this case, it's win win for me because no circuits exist that low, and this particular site, has gig and higher connectivity for WAN links, if we find something that's fast ethernet, that would be our slowest link, requiring the highest cost values within this OSPF area being deployed, have to like that !!

Thanks again for your time and assitance, to you and ALL !

Dave

PS:  time to play with vrf's as a solution I suppose, I have yet to implement outside a lab, but today, its PBR for this instance, at least for awhile, despite what you say and how much I may agree, we all know one thing in this crazy world of consulting, the customer is always right at the end of the day, and if they know they want PBR, and have to have PBR, there is no convincing argument against, PBR

Actions

This Discussion