GRE egress interface selection

[mattp0002]

Long story short, I have a single router with two Ethernet interfaces connected towards two different ISPs.  Each interface has a different (isp-provided & advertised) public IP address used to peer with the ISPs across a /30 p2p subnet.  eBGP routing is enabled across both connections and I'm accepting a default route from each and advertising my one /24 prefix to both.  Local pref is used to prefer one outbound route over the other while both ISP circuits are online, and each would take all the traffic load in the case of a single circuit failure.  Pretty basic config.

I'd like to turn up two GRE tunnels from this router across the internet.  Each would be sourced from the different ISP-provided public /30 IP addresses.  Both GRE tunnel destinations would be the same IP address of another router across the internet somewhere.

I'd like the traffic from each GRE to stay on it's own ISP symmetrically.  I believe since this router has one route table, whichever default route is currently installed from the RIB would take all the outbound traffic - regardless of the GRE source IP address.  (I understand the return traffic for each GRE should ingress via the proper ISP automatically, I'm talking here about egress from my router towards the internet)

I don't think I can use PBR to set the next-hop for each tunnel, because PBR can't be applied on an egress interface - and these GRE tunnels are sourced at this router rather than passing in and through the router.

Is this type of architecture possible?  How can GRE egress interface be enforced?

Thanks!!

[Peter Paluch]

Hello Jose,

In the solution you propose I do not see one thing and this is how would be reachable these loopbacks through Internet, as the tunnel source must be the addressing of the providers, which is configured in the /30 WAN interface.

Not necessarily. I have assumed that 192.0.2.1/32 and 192.0.2.2/32 are addresses that are a part of the IP space assigned to Matt's company and whose covering prefix (say, 192.0.2.0/24) is already being advertised via BGP to both ISPs.

I think it would be easier to just configure the WAN interfaces in different VRFs like this:

I respectfully disagree as putting the WAN interfaces into VRFs would break the connectivity of routes in the global routing table. Do not forget that there are other directly connected (or IGP-learned) networks on Matt's site in the global routing table. Moving the WAN interfaces to independent VRFs will make the situation more complex, both from the viewpoint of running a routing protocol over VRF interfaces, and from the viewpoint of providing default routing to the global routing table via egress interfaces that are in separate VRFs.

Best regards,
Peter

[mattp0002]

Just want to follow-up with a final update on this.  Peter and Jose have suggested multiple correct ways to do what I need to do.  I will summarize them as below:

1.  (Jose) Use the "tunnel route-via" command.  This is the simplest way to do it, although there may be a bug in ios 15 which prevents the command from being displayed when you issue a "show run" command.

2.  (Peter) Create a loopback interface and route all traffic to the remote destination first to that local loopback.  Apply a PBR policy inbound on the loopback and, based on source ip, set the next hop either outbound via one ISP or the other ISP.  This has been labbed up by the Cisco TAC (who were monitoring this thread - thanks to Israel P.) and Cisco has confirmed the operation of this "hack" to quote Peter.

3. (Peter & Jose) Use separate VRFs to route to the endpoint via each ISP.  Establish 2 GREs, each bound to each VRF using the "tunnel vrf" command.  Route traffic into the tunnel interfaces using the global routing table like 2 regular GREs.  I did not lab this one out, because the first option is so much simpler, but it should be possible.  Also I am not using VRFs in this environment so I'd rather not add the complexity.

Thanks everyone for your help with my issue.  It is appreciated!