Traffic redirection to another next-hop from tunnel interface


I want to make a GRE Tunnel to another site to establish a BGP session with an another ASN, on Cisco Nexus 9396PX.

I have create a tunnel interface in my default VRF (EBGP are running on), but the traffic going on to my first default route.

feature pbr
ip route
ip route 2 

ip prefix-list PFX-AS1234-V4 seq 10 permit
ip prefix-list PFX-AS1234-V4 seq 11 permit 
ip prefix-list PFX-AS1234-V4 seq 95 deny ge 32 
ip prefix-list PFX-AS1234-V4 seq 100 deny le 32 
route-map RPL-AS1234-IN-V4 permit 100
route-map RPL-AS1234-OUT-V4 permit 100
  match ip address prefix-list PFX-AS1234-V4 

interface Tunnel100
  ip address
  tunnel source 37.XXX.XXX.XXX
  tunnel destination 193.XXX.XXX.XXX
  no shutdown

router bgp MY_ASN_NUMBER
  template peer TP-AS1234-CUST-V4
    remote-as 1234
    address-family ipv4 unicast
      route-map RPL-AS1234-IN-V4 in
      route-map RPL-AS1234-OUT-V4 out
      maximum-prefix 5
      soft-reconfiguration inbound

    inherit peer TP-AS1234-V4
    no shutdown

I’ve tried this configuration using VRF but it seems that not worked, the BGP session broke, I think is not the good method.

vrf context test-sym
  ip route vrf default
  ip route 193.XXX.XXX.XXX/32 vrf default

interface Tunnel100
  vrf member test-sym
  ip address
  tunnel source 37.XXX.XXX.XXX
  tunnel destination 193.XXX.XXX.XXX
  no shutdown

How can i set the next hop to for the traffic coming only from this tunnel?
ip policy route-map doesn’t exist on interface type tunnel on my side (feature PBR is enabled)

Is there a lesson on the site linking my request, or what do I have to look at to be able to do what I want to do?


Hello Léo

I’m not quite sure I’ve understood the problem. Can I ask some clarification questions?

You want to establish a BGP session over a GRE tunnel. Specifically, you want to establish a session from the local router ( to If you don’t use VRFs as in your first example, then the BGP session is successfully established, correct? And the problem you’re having is described here:

So you want the routing to be set up such that any incoming traffic on the GRE tunnel will be able to return via the next hop rather than the next hop. But since your static routing table has an AD of 2 for the former, and an AD of 1 for the latter, it will always choose

If the above is indeed the case, and you can’t use PBR, then consider the use of static routing combined with VRFs to control the flow of traffic from your GRE tunnel. Consider the following:

  1. Dedicated VRF for Tunnel Traffic: Ensure that your GRE tunnel is associated with a VRF that is distinct from the default VRF as you initially did. This segregation allows for more granular control over the tunnel traffic.
  2. Static Routes: Configure static routes within the tunnel’s VRF to direct traffic towards your desired next hop. Given your configuration attempt with vrf context test-sym, ensure that all necessary routes for BGP and GRE tunnel traffic are appropriately defined within this VRF.
  3. Ensure VRF Connectivity to the Internet or Next Hop: If your next hop ( is outside of the test-sym VRF, ensure there’s a route leaking or an appropriate gateway configured to reach this next hop from the test-sym VRF.

Keep in mind that I’m sharing some general guidelines that you can use to troubleshoot and try to resolve the issue. I don’t have clear cut solutions, you will have to try applying these guidelines and refining them as needed. Just keep the following in mind:

  • VRF Route Leaking: If you need to route traffic from your GRE tunnel (in the test-sym VRF) to a next hop in the default VRF, consider using VRF route leaking techniques. This could involve using static routes with the vrf default keyword, as you attempted, or importing/exporting routes between VRFs if supported.
  • Review BGP Configuration: Ensure that your BGP configuration is correctly associated with the VRF. This includes specifying the VRF in your BGP neighbor statements if you’re trying to establish BGP sessions within a non-default VRF.
  • Troubleshooting and Verification: Use commands such as show ip route vrf [VRF_NAME] to verify your routing tables, show bgp vrf [VRF_NAME] summary to check BGP sessions, and show interface tunnel100 to ensure the tunnel is up and correctly configured.

Unfortunately, without the ability to apply PBR directly to the tunnel interface, you will need to rely on static routing and careful VRF configuration to achieve your desired routing outcomes. Such an approach is not ideal, and if this is a production network, you may need to reconsider the whole setup.

Let us know how you get along and if we can be of further help.

I hope this has been helpful!