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 0.0.0.0/0 100.23.1.90
ip route 0.0.0.0/0 10.10.20.10 2
ip prefix-list PFX-AS1234-V4 seq 10 permit 1.2.3.0/24
ip prefix-list PFX-AS1234-V4 seq 11 permit 4.5.6.0/24
ip prefix-list PFX-AS1234-V4 seq 95 deny 0.0.0.0/0 ge 32
ip prefix-list PFX-AS1234-V4 seq 100 deny 0.0.0.0/0 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 100.30.2.1/30
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
remove-private-as
address-family ipv4 unicast
send-community
route-map RPL-AS1234-IN-V4 in
route-map RPL-AS1234-OUT-V4 out
maximum-prefix 5
default-originate
soft-reconfiguration inbound
neighbor 100.30.2.2
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 0.0.0.0/0 10.10.20.10 vrf default
ip route 193.XXX.XXX.XXX/32 100.23.1.90 vrf default
interface Tunnel100
vrf member test-sym
ip address 100.30.2.1/30
tunnel source 37.XXX.XXX.XXX
tunnel destination 193.XXX.XXX.XXX
no shutdown
How can i set the next hop to 10.10.20.10 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?
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 (100.30.2.1) to 100.30.2.2. 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 10.10.20.10 next hop rather than the 100.23.1.90 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 100.23.1.90.
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:
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.
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.
Ensure VRF Connectivity to the Internet or Next Hop: If your next hop (10.10.20.10) 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.