GRE aware VRF

[nivic]

Hello, team!

I have cat6500 (sup-720) and I want configure gre tunnel within VRF. I used next configuration:

ip vrf test

rd 100:100

interface Tunnel0

ip vrf forwarding test

ip address 172.31.254.253255.255.255.252

keepalive 5 3

tunnel source 10.112.86.6

tunnel destination 10.112.86.20

tunnel vrf test

interface Vlan10

ip vrf forwarding test

ip address 10.112.86.6 255.255.255.192

interface GigabitEthernet4/28

no ip address

switchport

switchport access vlan 10

switchport mode access

spanning-tree portfast

I can ping tunnel destination from cat 6500 but tunnel didn't work.

sw-core#sh int tunnel 0

Tunnel0 is up, line protocol is down

Hardware is Tunnel

Internet address is 172.31.255.253/30

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec), retries 3

Tunnel source 10.112.86.6 (Vlan10), destination 10.112.86.20, fastswitch

TTL 113

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Tunnel TTL 255

Checksumming of packets disabled, fast tunneling enabled

Last input 01:27:32, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 8053

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

7847 packets input, 419400 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

Where am I mistake in the configuration file?

[spremkumar]

hi

Can you revert about the remote end where this GRE is getting terminated ??

Also the configs from the remote device related to GRE and also the show interface GRE..

regds

[nivic]

I am sorry! I forgot config for another end.

------------------------------------------------

cat 3750

interface Tunnel10

ip address 172.31.255.253 255.255.255.252

keepalive 10 3

tunnel source Vlan10

tunnel destination 10.112.86.6

interface GigabitEthernet1/0/1

switchport access vlan 10

interface Vlan10

ip address 10.112.86.20 255.255.255.192

3750#sh int tunnel 10

Tunnel10 is up, line protocol is up

Hardware is Tunnel

Internet address is 172.31.255.253/30

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec), retries 3

Tunnel source 10.112.86.20 (Vlan10), destination 10.112.86.6, fastswitch TTL 255

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Tunnel TTL 255

Checksumming of packets disabled

Last input 01:40:56, output 00:00:02, output hang never

Last clearing of "show interface" counters 01:17:49

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

467 packets output, 22416 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

38 packets input, 2964 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

508 packets output, 27780 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

[spremkumar]

hi

I dont think the tunnel will come up coz @ one side you have applied VRF under that and on the other side u dont tht.

By applying VRF under that ur bringing that interface as a member of a particular MPLS VPN.

Since you have keepalives in place it will try to check the connectivity and it wont be able to get that established coz of the other side which is not the participating in the same vpn.

AFAIK If u want to bring the tunnel up then u shuld have the vrf forwarding configured on the other side too as well the necessary RT,RD values to enable the communication between them.

once ur thru with that u need to have normal (VPNV4)MP-BGP sessions to be configured between these devices to exchange the routing info.

Also clarify the purpose and the requirment to have this kinda topo over there..

you will be able to ping the ip address of the destination coz the ip will be reachable to u.

using an extended ping u cant ping the remote tunnel interface ip address with souce as ur local tunnel interface ip address from both the sides.

regds

[spremkumar]

hi

I dont think the tunnel will come up coz @ one side you have applied VRF under that and on the other side u dont have tht.

By applying VRF under the tunnel interface ur bringing that interface as a member of particular MPLS VPN.

Since you have keepalives in place under the tunnels it will try to check the connectivity and it wont be able to get that established coz of the other side which is not the participating in the same vpn.

AFAIK If u want to bring the tunnel up then u shuld have the vrf forwarding configured on the other side too as well with the necessary RT,RD values to enable the communication between them.

once ur thru with that u need to have normal (VPNV4)MP-BGP sessions to be configured between these devices to exchange the routing info.

Also clarify the purpose and the requirment to have this kinda topo over there..

regds

[Harold Ritter]

Is the tunnel destination resolvable via the VRF or the global RIB? The command "tunnel vrf test" instruct the tunnel to resolv the tunnel destination via the VRF. So unless you can resolv the tunnel destination via the VRF the tunnel won't come up.

If your goal is to establish the tunnel via the global RIB then just remove "tunnel vrf test".

Hope this helps,

[nivic]

Tunnel destination resolve via VRF. I can ping tunel destination from vrf (ping vrf test 10.112.86.20).

sh ip ro vrf test

Routing Table: test

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static

route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/26 is subnetted, 1 subnets

C 10.112.86.0 is directly connected, Vlan10

30.0.0.0/24 is subnetted, 1 subnets

C 30.30.30.0 is directly connected, Loopback

#ping vrf test 10.112.86.20

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

but tunnel is down.

[Harold Ritter]

What level of code are you running on the Sup720. It should definitely work. Can you just remove the keepalive on the Sup720 side to see if the tunnel comes up?

Thanks,

[nivic]

I use IOS 12.2(18)SXD6

Cisco Internetwork Operating System Software

IOS (tm) s72033_rp Software (s72033_rp-PK9SV-M), Version 12.2(18)SXD6, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2005 by cisco Systems, Inc.

Compiled Wed 17-Aug-05 18:13 by evmiller

Image text-base: 0x4002100C, data-base: 0x42320000

[Harold Ritter]

I did a bit more research and it looks like creating a tunnel through a VRF is not yet supported in the 12.2SX code train.

BTW: the fact that the "tunnel vrf" command was available in 12.2(18)SXD was probably an oversight. This command has been removed in 12.2SXE and SXF.

I tried and it works in 12.0S and 12.4, which doesn't help in your case.

Hope this helps,

[nivic]

I opened case to cisco TAC and I received similar answer.

it's a feature which at this point has not yet been added to the cat6k list of features.

I cry :-(

Thanks hritter and all