GRE tunnel & VRF

[geeksy]

Hi,

I have a 2 routers connected via transit network. First I setup a GRE tunnel between A & C and EIGRP over it. This works absolutely fine. Now I am trying to setup another GRE tunnel for a VRF on the same devices, but having issues with it. Please see the attached diagram.

Tunnel4 is up, EIGRP over the tunnel is working. Tunnel5 was up/down and I am unsure what exactly I did (think I removed the keepalives) but now it is up/up but I can't ping between 172.35.1.1 & 172.35.1.2, EIGRP is not coming up either. I can however ping between the loopbacks 2 on both the routers, so the routing for the source is fine.

Can anyone see any issue with the config and help me please?

Config as below.

R01
int lo1
ip address 10.10.10.1 255.255.255.255
!
interface Tunnel4
ip address 192.168.1.1 255.255.255.0
keepalive 10 3
tunnel source lo1
tunnel destination 10.10.10.2
end
!
int lo2
ip address 10.10.10.3 255.255.255.255
!
interface Tunnel5
vrf forwarding RED
ip address 172.35.1.1 255.255.255.0
tunnel destination 10.10.10.4
end

R02
int lo1
ip address 10.10.10.2 255.255.255.255
!
interface Tunnel4
ip address 192.168.1.2 255.255.255.0
keepalive 10 3
tunnel source lo1
tunnel destination 10.10.10.1
end
!
int lo2
ip address 10.10.10.4 255.255.255.255
!
interface Tunnel5
vrf forwarding RED
ip address 172.35.1.2 255.255.255.0
tunnel destination 10.10.10.3
end

[Deepak Kumar]

Hi,

On both routers, you missed a Tunnel source command under tunnel 5.

interface Tunnel5
vrf forwarding RED
ip address 172.35.1.1 255.255.255.0
tunnel destination 10.10.10.4
tunnel source <>
end

Regards,

Deepak Kumar

[Jaderson Pessoa]

as kumar said, tunnel source is missing.

interface Tunnel5
vrf forwarding RED
ip address 172.35.1.2 255.255.255.0
tunnel destination 10.10.10.3
end

[geeksy]

The source is set, it was just missing in the config that I pasted.

interface Tunnel5
vrf forwarding RED
ip address 172.35.1.1 255.255.255.0
tunnel destination 10.10.10.4
tunnel source Loopback2

R02
interface Tunnel5
vrf forwarding RED
ip address 172.35.1.2 255.255.255.0
tunnel destination 10.10.10.3

tunnel source Loopback2

Forgot to add earlier, my loopbacks are in the VRF, not sure if this is an issue.

"interface Loopback2
vrf forwarding RED"

I can ping 10.10.10.3 from 10.10.10.4, Tunnel interface is up but can't ping 172.35.1.2 from 172.35.1.1. EIGRP doesn't come up.

[Jaderson Pessoa]

There is a route for this destination on both sides?

[Deepak Kumar]

Hi,

Is loopback R1 to loopback R2 is reachable? Please share the routing table output. 

Regards,

Deepak Kumar

[geeksy]

Hi, Yes the loopbacks are reachable between them.

[Deepak Kumar]

Hi,

The mentioned configuration is tested in the lab and I am sure it will work if you have a route in the routing table and both Loopback must be reachable.

One more point I want to clarify that your loopback interface is in the Global VRF. Is it correct?

If yes then Please share the "Show IP route" and running configuration from both routers.

Regards,

Deepak Kumar

[grabonlee]

Hi,

Your topology is not attached. 

Anyway, based on the configuration that you posted, the 2nd GRE tunnel will not come up. The reason is that your transport, which is Loopback 2 is in a VRF, while your transit network is known via the Global routing table.

Do the following:

1. Remove loopback 2 on both routers from vrf RED

2. Add VRF RED network to your EIGRP instance. For example:

     router eigrp 1

       address-family ipv4 vrf RED autonomous-system 1
       network 172.35.1.0 0.0.0.255

Make sure that you use specific static routes for the loopbacks pointing to your transit network and don't advertise the loopbacks in EIGRP. This would prevent recursive routing.

After you're done, you can verify adjacencies for Tunnel 4 and 5 with:

sh ip eigrp neighbors

sh ip eigrp vrf RED neighbors

[paul driver · Accepted solution]

Hello

Seems like your missing some configuration to make the vrf instance work see the below configuration example for Rtr 1 and perform the same on rtr 2 but obviously with the correct addressing.

Basically you need to remember that vrf is a virtual router within the physical router and as such you need to tell the physical router how to route to the vrf and vice versa

Rtr1

ip route 10.10.10.3 255.255.255.255 Loopback2  <-- tells the rtr how to reach the addressing in the vrf loopback interface
ip route 10.10.10.4 255.255.255.255  (interface x/x) (next hop ip) <- basic static route to rtr 2
ip route vrf RED 10.10.10.4 255.255.255.255 (interface x/x) (next hop ip) global <-- vrf static route pointing to the global rib table

router eigrp xx
address-family ipv4 vrf RED <---- vrf eigrp instance
network 172.35.1.1 0.0.0.0
no auto-summary
autonomous-system xx

[Deepak Kumar]

Hi @paul driver 

Sorry but I think you made me confused.

ON RTR1:

 ip route 10.10.10.3 255.255.255.255 Loopback2  

The lookback 2 interface is having IP 10.10.10.3 on the RTR1 so This route will not do anything on the routing table.

ip route vrf RED 10.10.10.4 255.255.255.255 (interface x/x) (next hop ip) global <-- vrf static route pointing to the global rib table

Why he need this route? Tunnel source is already available in the Global VRF.  

As he mentioned that Loopback to loopback communication is working fine. He can ping RTR2 loopback2 using the source of Lookpack2 from the RTR1. 

Regards,

Deepak Kumar

[paul driver]

Hello

---

@Deepak Kumar wrote:

Hi @paul driver 

Sorry but I think you made me confused.

---

Hey Deepak dont worry -  I make my wife confused every day!

---

ON RTR1:

 ip route 10.10.10.3 255.255.255.255 Loopback2  

The lookback 2 interface is having IP 10.10.10.3 on the RTR1 so This route will not do anything on the routing table.

This loopback interface is indeed on the router however as its in a vrf  the router doesnt know it exists so it wont be able to route from the global rib into the vrf rib without this static route in the global rib towards the vrf interface, As the transit network isnt vrf'd

---

ip route vrf RED 10.10.10.4 255.255.255.255 (interface x/x) (next hop ip) global <-- vrf static route pointing to the global rib table

Why he need this route? Tunnel source is already available in the Global VRF.  

---

You would need this so within the vrf tunnel  each others destination loopback address can be reached (if required to do so)

---

As he mentioned that Loopback to loopback communication is working fine. He can ping RTR2 loopback2 using the source of Lookpack2 from the RTR1. 

---

Correct but they wont be able to communicate when they are put into a VRF without the above config otherwise why use a vrf in the first case?

[Deepak Kumar · Accepted solution]

Hi,

This is my lab configuration:

R1:Configuration
interface Loopback2
 ip address 10.10.10.10 255.255.255.0
!
interface Tunnel1
 ip vrf forwarding RED
 ip address 192.168.1.1 255.255.255.0
 tunnel source Loopback2
 tunnel destination 11.11.11.11
 tunnel key 1
!
interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.0
 duplex half
!
router eigrp 1
 network 1.1.1.0 0.0.0.255
 network 10.10.10.10 0.0.0.0
!
!
router eigrp 2
 !
 address-family ipv4 vrf RED autonomous-system 2
  network 192.168.1.0
 exit-address-family
!

R2:Configuration

interface Loopback2
ip address 11.11.11.11 255.255.255.0
!
interface Tunnel1
ip vrf forwarding RED
ip address 192.168.1.2 255.255.255.0
tunnel source Loopback2
tunnel destination 10.10.10.10
tunnel key 1
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.0
duplex half
!
router eigrp 1
network 1.1.1.0 0.0.0.255
network 11.11.11.11 0.0.0.0
!
!
router eigrp 2
!
address-family ipv4 vrf RED autonomous-system 2
network 192.168.1.0
exit-address-family

R1#sho ip route
Gateway of last resort is not set
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, FastEthernet0/0
L        1.1.1.1/32 is directly connected, FastEthernet0/0
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.10.10.0/24 is directly connected, Loopback2
L        10.10.10.10/32 is directly connected, Loopback2
      11.0.0.0/24 is subnetted, 1 subnets
D        11.11.11.0 [90/156160] via 1.1.1.2, 00:07:16, FastEthernet0/0
R1#
R1#sho ip eigrp vrf RED neighbors
EIGRP-IPv4 Neighbors for AS(2) VRF(RED)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.2 Tu1 12 00:04:50 36 1470 0 1
R1#

R1#sho ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 1.1.1.2 Fa0/0 14 00:10:26 31 186 0 4
EIGRP-IPv4 Neighbors for AS(2)
R1#

I hope it is working fine without pushing the loopback interface router into a VRF because Loopback is already available into Global VRF.

Regards,

Deepak Kumar

[paul driver]

Hello

@Deepak Kumar 
I am not saying it not possible but if i am not mistaken in the OP shows having two loopbacks on R1 with 2 eigrp peerings over a shared transit path ? -  Now the point of the vrf is to segregate traffic so the suggested configuration i would probably do in this case would be to put all SIP/DIP addressing of the vrf tunnel in the vrf not just the tunnel addressing, Then as such you WOULD require the configuration i suggested previously.

[Deepak Kumar]

Hi,
As he shared the configuration and details with us, right now only one tunneling (tunnel 2) IP address in the VRF RED and all other in the Global VRF.

Regards,
Deepak Kumar