GRE Tunnel Path Control

[Bit_Jockey]

I thought this would be a simple task, but I've gone off track somewhere.

I have 2 equal cost paths between Routers 1 and 4 on the network and I'd like to set up a GRE tunnel between them.  Since there are 2 paths, I would like to choose which path the tunnel forms over.

I thought this would be easy using PBR, however its not catching any traffic for policy routing.  I have applied the policy to the tunnel source interface as well as the local policy.

Anyone set this up before?

I can provide configs, but this is so basic, I didnt think it was necessary.  At this point, my policy looks like this:

R1#show ip access-lists
Extended IP access list 100
    10 permit gre any host 192.168.0.6
    20 permit ip any host 192.168.0.6

R1#show route-map       
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop 192.168.0.2
  Policy routing matches: 0 packets, 0 bytes

R1#show ip policy
Interface      Route map
local          PBR
Fa0/0          PBR

[wintermute000]

Source from loopbacks and fix those /32 routes

[Bit_Jockey]

If I source from a loopback on the near end, then I must update the destination on the far end as well, correct?  If so, that's not what I'm trying to do.  Even though 2 paths exist, I only want the tunnel to ever form over 1 path and the tunnel to fail if that 1 path is broken.

And what do you mean by fix the /32 routes?  I think I understand what you mean, but I want to be sure.

[wintermute000]

There are tricks available

fix the /32 routes = the routes for your src/dst loopbacks = change the metrics manually for those routes only using say BGP, or the distance per prefix on your IGP, or use a static (if you want redundancy, make it a floating static i.e. tie it to an IP SLA)


PBR is probably not working as PBR applies only ingress to an interface, the router is probably not perceiving self sourced traffic as ingress on the interface. If you applied PBR inbound and sourced the tunnel from a router behind the PBR router then it would work

[that1guy15]

Ran into this the other week. Cisco requires the next-hop set by PBR to be directly connected and not a tunnel destination. You can match on a tunnel inbound but not outbound.

Do a debug ip policy and you will see these errors:
"FIB policy rejected - normal forwarding" and "Not Attached; Nexthop rejected"

[Bit_Jockey]

PBR is probably not working as PBR applies only ingress to an interface, the router is probably not perceiving self sourced traffic as ingress on the interface. If you applied PBR inbound and sourced the tunnel from a router behind the PBR router then it would work

Ah yes, of course, I believe you're right.

I am currently using floating static routes (/32's) to influence the tunnel path, but that means any traffic sourced behind the router is also affected.  For the most part it's not a big deal, it just messes with a system that does monitoring on the network.  A possible solution might be to use PBR for the monitoring box, not the tunnel.  I'm going to have to think on this for a bit more.  Thanks for the feedback.

[Fred]

Even though 2 paths exist, I only want the tunnel to ever form over 1 path and the tunnel to fail if that 1 path is broken.

If I understand the nature of the problem, and I'm not sure that I do, why don't you create two tunnels that stay active, and use a routing protocol to decide the best one to use?  In my experience, it's better to have two always-available paths, and let the IGP pick the better one, rather than to try to fire one up an alternate path when the first one fails. 

Having two always-on connections means that you can monitor both so you'll know when your backup dies and fix it before it becomes an issue, and the backup path takes minimal traffic to keep alive.

[wintermute000]

Fred's on the right track re: design
That1guy, thanks for the tip, didn't know that, will remember (I wonder if its the same on IOS-XE)

[that1guy15]

Fred's on the right track re: design
That1guy, thanks for the tip, didn't know that, will remember (I wonder if its the same on IOS-XE)

Dont have a clue. All the PBR docs I found where vague on this issue. The best I found on it was for N7K but I was only able to test on a 2900 ISR.

[Bit_Jockey]

Fred's on the right track re: design

I'll cheers to that!  Poor design coupled with no budget is the whole reason that brought about this hack in the first place.   

The example I used in the original post is not exactly what I'm working with.  I thought it would be more direct to ask about a simple network with variables removed, rather than describe a production network.  Essentially I have a network topology between locations that looks like a C.  Trying to tunnel over a provider network to make it look more like an O.  Naturally the tunnel wants to form over the inside links, but I'd like it to form over the provider links to reduce convergence time.  I'd prefer to spin up another physical link, but that just aint gonna happen.

I'm open to suggestion if you've seen this dog and pony show before

[wintermute000]

Put up a diagram

[icecream-guy]

Put up a diagram

I think He did

problem
C

Solution
O

issue: can't connect the ends of the C to make the O

[wintermute000]

i was hoping for at least a cameraphone pic of a napkin drawing


in general though: alter the routing metrics to primary/backup.


Use PBR to steer a nominated set of less important/less time dependent traffic via the backup path. Put an IP SLA on the PBR so theres some redundancy.

[Fred]

Possibly as easy as adding static /32 routes to the GRE tunnel endpoints.