VRF lab pulling hair out

[Blake.Neumeister]

Hello, I am trying to learn VRFs so I can possibly implement them at work. I've got gre tunnel interfaces that won't come up after adding vrf forwarding to it. What I'm trying to do is force all traffic from R17 down the tunnel 0 interface. I can't even get the tunnel endpoints to come up for basic connectivity let alone accomplish my goal. Please ignore the route map stuff, I was able to achieve the goal within minutes using those, now I am trying to do it with VRFs. The tunnel interfaces are up/down. I've attached a diagram.

What am I doing wrong? Thanks guys! If anyone can figure this conundrum out I'll be quite relieved.

R11 config (using fa1/0 as endpoint)

R11#sh run

Building configuration...

Current configuration : 1616 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R11

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

memory-size iomem 5

ip cef

!

!

!

!

ip vrf detour

!

no ip domain lookup

ip domain name lab.local

!

!

!

!

!

!

!

interface Loopback0

ip address 11.11.11.11 255.255.255.255

!

interface Tunnel0

ip vrf forwarding detour

ip address 123.123.123.123 255.255.255.0

load-interval 30

tunnel source 10.0.0.2

tunnel destination 15.15.15.15

!

interface FastEthernet0/0

ip address 2.2.2.2 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0

no ip address

shutdown

clock rate 2000000

!

interface FastEthernet0/1

ip address 1.1.1.2 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet1/0

ip vrf forwarding detour

ip address 10.0.0.2 255.255.255.0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

area 10 stub no-summary

network 10.0.0.0 0.0.0.255 area 10

network 0.0.0.0 255.255.255.255 area 0

!

ip forward-protocol nd

ip route vrf detour 0.0.0.0 0.0.0.0 123.123.123.124

!

no ip http server

no ip http secure-server

!

ip access-list extended tunneling

permit icmp 10.0.0.0 0.0.0.255 any

permit ip 10.0.0.0 0.0.0.255 any

!

route-map tunneltime permit 10

match ip address tunneling

set interface Tunnel0

!

!

control-plane

!

!

line con 0

exec-timeout 0 0

privilege level 15

logging synchronous

line aux 0

exec-timeout 0 0

privilege level 15

logging synchronous

line vty 0 4

login

!

!

end

R15 config (2nd endpoint using loopback 0)

R15#sh run

Building configuration...

Current configuration : 1185 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R15

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

memory-size iomem 5

ip cef

!

!

!

!

ip vrf detour

!

--More--

*Mar  1 04:53:36.450: %SYS-5-CONFIG_I: Configured from console by console

no ip domain lookup

ip domain name lab.local

!

!

!

!

!

!

!

interface Loopback0

ip vrf forwarding detour

ip address 15.15.15.15 255.255.255.0

!

interface Tunnel0

ip vrf forwarding detour

ip address 123.123.123.124 255.255.255.0

tunnel source Loopback0

tunnel destination 10.0.0.2

!

interface FastEthernet0/0

ip address 5.5.5.5 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 4.4.4.5 255.255.255.0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!

ip forward-protocol nd

ip route vrf detour 0.0.0.0 0.0.0.0 123.123.123.123

!

no ip http server

no ip http secure-server

!

!

control-plane

!

!

line con 0

exec-timeout 0 0

privilege level 15

logging synchronous

line aux 0

exec-timeout 0 0

privilege level 15

logging synchronous

line vty 0 4

login

!

!

end

[Harold Ritter · Accepted solution]

Hi Blake,

The tunnel endpoints should be in the global routing table not in the VRF. You should therefore remove "ip vrf forwarding detour" from fa1/0 on R11 and lo0 on R15 or use other interfaces that are associated with the global routing table as endpoints. This should allow your tunnel to come up.

Hope this helps

[Blake.Neumeister]

Thank you! That was it, I was going off a config I saw on another page which I just read more of and apparently it ended up being wrong.

However, my goal is still not accomplished, which was to, by default, force all traffic down the tunnel interface instead of it being routed globally around the perimiter like this:

R17#traceroute 4.4.4.4

Type escape sequence to abort.

Tracing the route to 4.4.4.4

  1  *

    10.0.0.2 28 msec 20 msec

  2 2.2.2.3 28 msec 28 msec 16 msec

  3 3.3.3.4 44 msec *  56 msec

I need to have all traffic from R17 sucked into that VRF and pushed down tunnel 0. I thought that fa1/0 interface on R11 needed to be included in the VRF so the packets had no other option and were yanked in. What is there to make it prefer tunnel 0 over the global routing table? I've got default statics set up from within the VRF, I just need the traffic to FIND the VRF. Any ideas? Thanks again Harold.

Edit: I still can't ping the tunnel 0 interfaces of 123.123.123.123 and .124 despite the tunnels being up and despite the default route on R11 and vice versa.

R11#sh ip route vrf detour

Gateway of last resort is 123.123.123.124 to network 0.0.0.0

     123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Tunnel0

S*   0.0.0.0/0 [1/0] via 123.123.123.124

Even when pinging from within the VRF:

R11#ping 123.123.123.124 source tunnel 0

Sending 5, 100-byte ICMP Echos to 123.123.123.124, timeout is 2 seconds:

Packet sent with a source address of 123.123.123.123

.....

Success rate is 0 percent (0/5)      

[Harold Ritter]

Now that I carefully look at the diagram, you need to enable "ip vrf forwarding detour" on R11 Fa1/0 so that traffic from R17 gets forwarded in the VRF. You will need to use another interface as the tunnel source on R11, one that is associated to the global routing table. I would suggest you use lo0 for that purpose.

Regards

[Blake.Neumeister]

Ok I added fa1/0 back to the VRF, and the tunnel remains up after using loopback 0 as the tunnel source on R11, so it's looking good except for one small, maybe not so small problem. I've still got no connectivity between the tunnel addresses. Is there something wrong with my static addresses? The route tables are above. Here is the ping command again:

R11(config-if)#do ping 123.123.123.124 source tunnel 0

Sending 5, 100-byte ICMP Echos to 123.123.123.124, timeout is 2 seconds:

Packet sent with a source address of 123.123.123.123

.....

Success rate is 0 percent (0/5)

And for kicks here is the attempt to check traffic flow from R17 acting as a host PC:

R17#traceroute 4.4.4.4

Tracing the route to 4.4.4.4

  1  *  *  *

Thanks so much for help, I'm lost in a VRF myself right now and you're my only connectivity.

[Harold Ritter]

The tunnel being associated to the VRF, you need to ping as follow:

ping vrf detour 123.123.123.124

As for the traceroute from R17, I presume you have a default route on R17 pointing at R11, right?

Regards

[Blake.Neumeister]

R11(config-if)#do ping vrf detour 123.123.123.124

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.124, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R17 is set as a totally stubby through an injected ospf default route from R11. It worked earlier when I didn't have fa1/0 in the VRF (though it wasn't entering the tunnel):

Actually, that default ospf route must be dead now after adding it's routing update source into the vrf. Just added a normal default static to the routing table, still no dice.

The problem is still the tunnel link itself I think, the routing could be wack somehow. Maybe I should try using a routing protocol inside that VRF. I'm hesitant because I don't want to complicate matters by using the address family command set and whatnot.

[Harold Ritter]

I would suggest you start with an extended ping from R11 lo0 to R15 lo0 to verify the tunnel connectivity.

Regards

[Blake.Neumeister]

R11(config-if)#do ping vrf detour 123.123.123.124

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.124, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/48/68 ms

Pretty right? I took the keepalive statements off the tunnel interfaces and it worked. I can also ping 10.0.0.2 from R17, but I can't ping anywhere else but that address (fa1/0.) I think the issue is with the transition from fa1/0.

Here are some debugs of note while pinging 4.4.4.4 from R17 which should be funneled out the tunnel.

*Mar  1 07:39:13.610: IP: tableid=0, s=15.15.15.15 (FastEthernet0/1), d=11.11.11.11 (Loopback0), routed via RIB

*Mar  1 07:39:13.610: IP: s=15.15.15.15 (FastEthernet0/1), d=11.11.11.11, len 124, rcvd 4

*Mar  1 07:39:13.610: ICMP: time exceeded (time to live) sent to 10.0.0.1 (dest was 4.4.4.4)

*Mar  1 07:39:13.614: IP: tableid=1, s=123.123.123.123 (local), d=10.0.0.1 (FastEthernet1/0), routed via FIB

Like all 5 ping requests, the TTL looks like it expired, could the packets just be looping around in between fa1/0 and the tunnel?

You have helped me a ton Harold, we are almost there. Thanks again.

EDIT: I did a packet capture on the other side of the tunnel, the fa0/1 interface of R15, and when I sent a normal ping at 4.4.4.4 from R17 BAM... I saw the loop. Even though only 5 icmp requests were sent out I saw what I'm sure was 255 leaving or trying to leave R15. Never got a reply from 4.4.4.4 just a bunch of requests. Must be from those two static routes inside the VRF, they just keep firing the pings back at each other and they can never get out of the VRF. Looks like I'll have to put a routing protocol inside the VRF.

[Harold Ritter]

Is 4.4.4.4 in the global routing table or in the VRF? If it is not in the VRF, R17 will not be able to reach it by default.

You should be able to ping any address in the VRF (like 123.123.123.123 and 124 for instance) from R17 though.

Regards

[Blake.Neumeister]

Yup I can ping 123.123.123.123 from R17. 4.4.4.4 like most of the routes is in the global table only. What I'm wondering about is how to inject the global routes into the vrf, so that once a packet enters the vrf, it will be able to get out and find what it needs, then get back to the vrf and to the origin point. I'd think a routing protocol running inside the vrf won't be able to point outside it. Is extending the VRF all the way to the final destination the only option?

[Harold Ritter]

Typically, extending the VRF all the way to the destination is the way to go. There are multiple different ways around that such as having a router (or FW) connecting the VRF and the global and passing the traffic between the two.

Hope this helps

[Blake.Neumeister]

Alright, I'll look into that. Thanks Harold for all your help.