12-17-2020 09:21 PM
Hello,
I am labbing up a tunnel between two vrfs. Routes are being exchanged with OSPF to a second router. Everything is working including pings to physical interfaces and loopback interfaces. The only problem is that the tunnel won't come up? I don't know why. Would appreciate an explanation if possible.
Router#show running-config interface tunnel 10
Building configuration...
Current configuration : 148 bytes
!
interface Tunnel10
vrf forwarding blue
ip address 10.10.10.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel destination 10.0.34.4
end
Router#show running-config interface tunnel 14
Building configuration...
Current configuration : 147 bytes
!
interface Tunnel14
vrf forwarding red
ip address 10.10.10.4 255.255.255.0
tunnel source GigabitEthernet0/3
tunnel destination 10.0.13.1
end
Router#show ip route vrf blue 10.0.34.4
Routing Table: blue
Routing entry for 10.0.34.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.13.3 on GigabitEthernet0/0, 00:13:08 ago
Routing Descriptor Blocks:
* 10.0.13.3, from 10.0.34.3, 00:13:08 ago, via GigabitEthernet0/0
Route metric is 2, traffic share count is 1
Router#show ip route vrf red 10.0.13.1
Routing Table: red
Routing entry for 10.0.13.0/24
Known via "ospf 2", distance 110, metric 2, type intra area
Last update from 10.0.34.3 on GigabitEthernet0/3, 00:13:24 ago
Routing Descriptor Blocks:
* 10.0.34.3, from 10.0.34.3, 00:13:24 ago, via GigabitEthernet0/3
Route metric is 2, traffic share count is 1
Router#show ip interface tunnel 10
Tunnel10 is up, line protocol is down
Internet address is 10.10.10.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1476 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
VPN Routing/Forwarding "blue"
Downstream VPN Routing/Forwarding ""
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: MCI Check
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled
Router#show ip interface tunnel 14
Tunnel14 is up, line protocol is down
Internet address is 10.10.10.4/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1476 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
VPN Routing/Forwarding "red"
Downstream VPN Routing/Forwarding ""
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: MCI Check
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled
Solved! Go to Solution.
12-18-2020 09:47 AM
Hello,
the tunnels come up when I add the lines marked in bold:
interface Tunnel10
vrf forwarding blue
ip address 10.10.10.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel destination 10.0.34.4
--> tunnel vrf red
!
interface Tunnel14
vrf forwarding red
ip address 10.10.10.4 255.255.255.0
tunnel source GigabitEthernet0/3
tunnel destination 10.0.13.1
--> tunnel vrf blue
This is because the tunnels are part of their respective VRF, but use the tunnel destination and source addresses from the routing table of the respective other VRF...
Hope that makes sense...
12-18-2020 12:16 PM
Hello
so basically the physical interfaces are in their own route table and not in the global route table as such the tunnels do not know how to reach them adding the command @Georg Pauwen @posted told the rtr to look on the respective vrf route tables thus the tunnel established
if you remove the physical interface from their respective vrfs you would t need that command and the tunnels should come up
12-18-2020 12:51 AM
Hello,
the routers don't seem to be directly connected ? Post the full configs (sh run) of all routers involved...
12-18-2020 08:10 AM
They are not. I have added both of the routers config to this chain.
12-18-2020 02:24 AM
Hello
By default the tunnels should be in a up/up state unless that is keepalive is applied, so try disabling it on the tunnels
Int tun x
no keepalive
12-18-2020 07:54 AM
Keepalive is NOT enabled. Also I am not seeing the tunnel go down with debug tunnel interface it just IS down when I check it. Shows up when I "no shut" then IS down when I verify.
Thanks for your help!
Router(config)#interface tunnel 10
Router(config-if)#no keepalive
Router(config-if)#exit
Router(config)#interface tunnel 14
Router(config-if)#no keepalive
Router(config-if)#end
Router#
*Dec 18 15:48:52.535: %SYS-5-CONFIG_I: Configured from console by console
Router#show interfaces tunnel 10
Tunnel10 is up, line protocol is down
12-18-2020 08:02 AM
12-18-2020 08:09 AM
12-18-2020 08:23 AM
Helo,
where do these two configs belong to ? One config has no VRF. Post all configs of all routers, and include a diagram of how they are connected, so we can lab this.
12-18-2020 08:32 AM
The topology is very simple. Two routers connected via two links gi0/0 vrf blue and gi0/3 vrf red ON Router 1 and gi0/0 and gi0/3 NO VRF on router 2. Tunnel is expected to leave gi0/0 vrf blue and go through router 2 to terminate back on gi0/3 vrf red of router 1. FYI I have added the two configs to this chain above.
Thanks for your help!
12-18-2020 08:47 AM - edited 12-18-2020 08:50 AM
12-18-2020 09:17 AM
Hello,
sorry for the misunderstanding, I am not sure where this goes wrong. You said earlier the two routers are not directly connected, so I assume there must be at least three (or more) routers in your topology ? What we need are the full configurations of all three (or more) routers, that is, the output of 'sh run' of each router. This in order to be able to exactly recreate the topology that YOU have created.
Hope that makes sense...
12-18-2020 09:22 AM - edited 12-18-2020 09:24 AM
The whole topology diagram and all configs have been posted in this thread. Logically they are not directly connected. Physically there are only two routers.
Thanks for your help!
Edit: Getting the sense that this just doesn't work. Wondering if anyone else is seeing the same thing in their labs. So far I have not heard anyone say it works in this configuration for them.
12-18-2020 09:32 AM
OK. I'll lab it up like you configured it and get back with you...
12-18-2020 09:47 AM
Hello,
the tunnels come up when I add the lines marked in bold:
interface Tunnel10
vrf forwarding blue
ip address 10.10.10.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel destination 10.0.34.4
--> tunnel vrf red
!
interface Tunnel14
vrf forwarding red
ip address 10.10.10.4 255.255.255.0
tunnel source GigabitEthernet0/3
tunnel destination 10.0.13.1
--> tunnel vrf blue
This is because the tunnels are part of their respective VRF, but use the tunnel destination and source addresses from the routing table of the respective other VRF...
Hope that makes sense...
12-18-2020 09:56 AM
Of course that works. Thank you so much. To be honest I am not following why that is though. Tunnels are part of their vrf. In terms of what a tunnel knows it should not need any awareness of the other vrf which is part of the separation that the vrf provides, I would think. But I do understand your explanation of needing that information which is only available with knowledge of the others routing table. Wonder if there is an easy to over come this. Maybe static routes? I'll keep playing around with it. Thanks.
Thanks for your help!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide