GRE tunnel source address and PBR

[lukasz-buchla]

Hi,

I have the following case:

In HQ I have two routers (ISR 4000) connected to the Internet which:
1. Each router on the Gi0/0/0 interface is connected to a different ISP.
2. Routers on the interfaces to ISPs (Gi0/0/0) have VRF configured
3. A DMVPN tunnel is set up where Gi0/0/0 is given as the source interface.

Now I run BGP with two ISPs (I have my own AS and PI addressing).

And I have the problem that the DMVPN tunnel that is pinned on the router A interface Gi0/0/0 (with IP addressing from ISP-A) tries to exit through router B, where the ISP-B is blocking that source address (it is neither from my PI pool nor from addressing received from ISP-B).

How can I configure the router so that DMVPN tunnels always exit through the local ISP (regardless of the routing table).

I tried configuring route-map and using the ip local policy route-map command, but it doesn't work. 

I don't have a "tunnel route-via" command.

Do you have any idea how to solve it?

I know I can configure loopback interfaces with addressing from PI pool and get them up as source GRE tunnel interfaces, but would prefer to do on addressing received from ISP (and have branches with two independent tunnels over two different links)

Configuration of interfaces below:

interface GigabitEthernet0/0/0

 description WAN

 vrf forwarding ISP

 ip address 1.1.1.1 255.255.255.252

end

interface Tunnel2

 ip address 10.10.10.1 255.255.255.0

 no ip redirects

 ip mtu 1400

 ip nhrp authentication xxxxxxx

 ip nhrp network-id 1001

 ip nhrp redirect

 load-interval 30

 if-state nhrp

 tunnel source GigabitEthernet0/0/0

 tunnel mode gre multipoint

 tunnel key 123

 tunnel vrf ISP

 tunnel protection ipsec profile DMVPN-IPSEC-PROFILE

end

[paul driver]

Hello

trying to understand why the first HQ router is trying to use the Second HQ router via their public assigned ip address

Both of these rtr should i would say should have a lan facing interface in the same subnet for the resilience and most probably a direct connection for ibgp peering.

You should definitely make sure your two HQ routers are not become a transit path for each upstream ISP

can you confirm these two rtr are ibgp peers and are using there respective ibgp addressing as source to each other’s received isp ebgp routes -neighbour xxx next-hopself 

[Georg Pauwen]

Hello,

I agree with Paul, it is odd that the traffic exists through the other router. Can you post the configs of both routers ?

[lukasz-buchla]

Why is it weird? The router uses the routing table received by BGP, where in some cases the second router indicates this route as more attractive.
Unfortunately, tunnel interfaces are "pinned" on the operator's interface, where his address is, not mine from the PI pool.

[Giuseppe Larosa]

Hello @lukasz-buchla ,

>> And I have the problem that the DMVPN tunnel that is pinned on the router A interface Gi0/0/0 (with IP addressing from ISP-A) tries to exit through router B, where the ISP-B is blocking that source address (it is neither from my PI pool nor from addressing received from ISP-B).

You have clearly an iBGP session between the two routers that is causing this.

The iBGP session can be good for providing redundancy for internet access and return path but this is creating issues to DMVPN on RouterA.

As an approximate quick fix you can use the weight

router A

router bgp your-AS

neighbor  <ISP-A> weight 40000

This may impact on traffic distribution to the internet but should fix the issues for DMVPN unless ISP-B is providing more specific prefixes for the destination public addresses of spoke branch sites on ISP-A.

So after the proposed change using the list provided by NHRP on RA you should check that all the remote spokes are registered and their NBMA public address is routed via ISP-A. To be noted if any is missing is because ISP-B is providing a more specific prefix as noted above.

To be noted using local-preference could move the issues on RB as local-preference is AS wide. This is one case where the weight being local to the router and not sent to any iBGP neighbor is useful.

Hope to help

Giuseppe