GRE tunnel and VRF

[iores]

Hi,

I have created simple topology with two routers directly connected over Gig0/0 interfaces. Loopback0 interfaces are used as GRE tunnel source/destination. Loopback99 interfaces are just mimicking the customer subnets.

When I try to

ping vrf customer 10.1.1.1 (from R1) or ping vrf customer 10.0.0.1 (from R2)

it doesn't work.

R1 configuration:

interface Loopback99
 ip vrf forwarding customer
 ip address 10.0.0.1 255.255.255.0
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 192.168.0.2
!
interface GigabitEthernet0/0
 ip address 192.168.0.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
...
ip route vrf customer 10.1.1.0 255.255.255.0 Tunnel0
!

R2 configuration

interface Loopback0
 ip address 192.168.2.2 255.255.255.255
!
interface Loopback99
 ip vrf forwarding customer
 ip address 10.1.1.1 255.255.255.0
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.2 255.255.255.0
 tunnel source Loopback0
 tunnel destination 192.168.0.1
!
interface GigabitEthernet0/0
 ip address 192.168.0.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
...
ip route vrf customer 10.0.0.0 255.255.255.0 Tunnel0
!

Please help.

[MHM Cisco World]

ip route vrf customer 10.1.1.0 255.255.255.0 Tunnel0<- use Gi0/0 instead of tunnel in static route 

[MHM Cisco World · Accepted solution]

FRINED DO THIS CHANGE AND IT WILL WORK.
hope that.

interface Loopback99
 ip vrf forwarding customer
 ip address SUBNET-R1 MASK 
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.1 255.255.255.0
 tunnel source Loopback99
 tunnel destination SUBNET-R2
!
interface GigabitEthernet0/0
 ip address 192.168.0.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
...
ip route vrf customer SUBNET-R2 MASK gi0/0 global
ip route vrf customer LO-R2 MASK tunnel0

interface Loopback0
 ip address LO-R2 MASK
!
interface Loopback99
 ip vrf forwarding customer
 ip address SUBNET-R2 MASK
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.2 255.255.255.0
 tunnel source Loopback99
 tunnel destination SUBNET-R1 MASK
!
interface GigabitEthernet0/0
 ip address 192.168.0.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
...
ip route vrf customer SUBNET-R1 MASK gi0/0 global 

[Seb Rupik · Accepted solution]

Hi there,

The tunnel sources and destinations don't match. The tunnel destinations on both routers configred to use the directly attached Gi0/0 interfaces. Also if you are using loopback interfaces then each router will need to know how to reach the loopback located on the other router.

I assume R1 loop0 uses the IP address 192.168.2.1/32

Try the following:

! R1
!
int loop0
ip address 192.168.2.1 255.255.255.255
!
interface Loopback99
 ip vrf forwarding customer
 ip address 10.0.0.1 255.255.255.0
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 192.168.2.2
!
interface GigabitEthernet0/0
 ip address 192.168.0.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
ip route 192.168.2.2 255.255.255.255 192.168.0.2
!
ip route vrf customer 10.1.1.0 255.255.255.0 Tunnel0
!

! R2
!
interface Loopback0
 ip address 192.168.2.2 255.255.255.255
!
interface Loopback99
 ip vrf forwarding customer
 ip address 10.1.1.1 255.255.255.0
!         
interface Tunnel0
 ip vrf forwarding customer
 ip address 172.16.0.2 255.255.255.0
 tunnel source Loopback0
 tunnel destination 192.168.2.1
!
interface GigabitEthernet0/0
 ip address 192.168.0.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
ip route 192.168.2.1 255.255.255.255 192.168.0.1
!
ip route vrf customer 10.0.0.0 255.255.255.0 Tunnel0
!

cheers,

Seb.

[iores]

It worked!

Additional question: how routing in this case works? VRF customer has the information how to reach the tunnel, and the default routing table knows how to reach the physical interface of the destination router.

Does this mean router uses these two routing tables interchangeably?

[MHM Cisco World]

the Router see traffic is out via GRE interface <- here the routing of VRF is use
the GRE is add new header (tunnel source & destination )
router now need to routing new packet (with additional header) <- here the routing using global.

[paul driver · Accepted solution]

Hello
You need to apply static routes for the loopback 0 interfaces which reside in the global route table (GRT)  plus static routes in the vrf customer route table for the loopback 99 interfaces.

Example:

R1
ip route 192.168.2.2 255.255.255.255 GigabitEthernet0/0 192.168.0.2
ip route vrf customer 10.1.1.0 255.255.255.0 Tunnel0 172.16.0.2

R2
ip route 192.168.2.1 255.255.255.255 GigabitEthernet0/0 192.168.0.1
ip route vrf customer 10.0.0.0 255.255.255.0 Tunnel0 172.16.0.1

[iores]

Hi @paul driver 

I got things working, and then I tried to run EIGRP for specific VRF. This is what I used on both routers, but it doesn't work:

address-family ipv4 vrf customer autonomous-system 1
network loopback99_address 0.0.0.255

[iores]

@paul driver 

Here's the update:

I ha e managed to establish EIGRP adjacency over the GRR tunnel by adding the route to Loopback0 of R2 into the global routing table of R1, and by adding the same route to the VRF customer but with global keyword.

I have repeated the process on R2.

Two routers exchanged the network prefixes. Under the EIGRP proccess I needed to advertise the IP addresses of tunnel interfaces, and particular network prefixes from the VRF.

However, now I have a couple of question regarding routing:

1. If I have advertised the tunnel interfaces, how come there is no GRE recursive error? Is it because the addresses of Loopbacks 0 and tunnel addresses are in separate VRFs?

2. How routing process works exactly in this case? I have noticed that adjacency wouldn't come up until the tunnel interfaces were advertises.

[Seb Rupik]

Hi there,

recursive routing occurs when a tunnel is configured to terminate on an IP address which subsequently becomes advertised via the tunnel itself. This is usual mitigated by adding a static route to the remote IP /32 address via the same interface as the default route. When the routing peer at the other end of the tunnel begins sending routing updates, even say the remote IP /32, it will have a higher AD than the static route and recursive routing will not occur.

In your topology things are slightly different. The global routing table deals with tunnel endpoint routing, whereas the 'customer' VRF deals with any routing updates originating via the tunnel. The two routing tables cannot mix and you will not experience recursive routing.

Regarding your EIGRP config, you need to specify the tunnel subnet to indicate to the EIGRP process that you wish to run the protocol on that interface.

cheers,

Seb.

[iores]

@Seb Rupik 

Just want to check my understanding about one more thing.

EIGRP adjacency can be established between routers for VRF customer over tunnel interfaces only because the tunnel 'interconnects' them. This would be as if the routers are directly connected with physical link and if we don't activate EIGRP on those interfaces first the routers won't become neighbors. Am I correct?

[Seb Rupik]

Correct. In this topology the GRE tunnel forms an overlay network which abstracts a physical network with multiple hops into a single hop. This therefore allow the non-routable EIGRP multicast address 224.0.0.10 to function within the tunnel and allow an adjacency to form.

cheers,

Seb.