Global table to MPLS VPN problem

[plearmouth]

Hi,

I have PE-P-PE (no CE's) with various VPNs. From inside a VPN/VRF I have no issues pinging to the remote PE.

However, I have a source within the global table that can ping various interfaces within the local VRF but I cannot get it too ping any VPNV4 address learnt from the remote PE.

debug shows encapsulation error.

Source is 10.10.0.10 (global table) and tries to ping 192.1.1.1 which exists in VRF Untrusted as a learnt VPNV4 prefix.

I have a static route in the global table of

ip route 192.1.1.1 255.255.255.255 vlan200 (which is an interface in the same VRF)

The source can ping another interface within the VRF i.e a local interface but I cannot seem to get to addresses learnt from BGP.

In summary, 1. within the VRF everything is okay.

2. from global to local interface within VRF is okay.

3. from global to learnt VPNV4 route I get encapsulation error.

I presume I have the static route misdefined ?

Many thanks in advance.

Paul

[Giuseppe Larosa]

Hello Paul,

look at the following example:

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml#global

It looks like you need a pair of static routes one of them in VRF:

ip route 10.0.2.0 255.255.255.252 Serial2/0

ip route vrf vpn2 10.1.2.4 255.255.255.252 Serial1/0

Hope to help

Giuseppe

[plearmouth]

hi Giuseppe

Thanks for your reply but I do have both. It works for routes local to the PE but not for routes learnt from BGP.

Although within the VRF the routes are okay.

Debug shows arp as not getting a response from 192.1.1.1. I think this is the problem because this is not a local address.

regards

Paul

[Giuseppe Larosa]

Hello Paul,

have you got redistribute static within address-family ipv4 vrf vrf-name ?

Hope to help

Giuseppe

[plearmouth]

hi Giuseppe

yes I have - hopefully the following may help

I have the following static route in the Global table where source resides:

ip route 192.1.1.1 255.255.255.255 Vlan200

The global table shows:

C 10.10.0.0/24 is directly connected, Vlan201 (source is 10.10.0.10)

S 192.1.1.1 is directly connected, Vlan200 (destination 192.1.1.1)

In the VRF 'untrusted' I have:

ip route vrf Untrusted 10.10.0.0 255.255.255.0 10.10.0.10 global

Show ip route vrf Untrusted shows:

S 10.10.0.0 [1/0] via 10.10.0.10

B 192.1.1.1 [200/0] via 10.1.0.5, 02:46:24

sho ip cef 192.1.1.1 detail

192.1.1.1/32, epoch 15, flags attached

local label info: global/35

Interest List:

- exported attached prefix tracking

attached to Vlan200

sho mpls ip binding 192.1.1.1 32 de

192.1.1.1/32, rev 76, chkpt: none

in label: 35 (owner LDP)

Advertised to:

10.1.0.3:0

sho ip bgp vpnv4 vrf Untrusted 192.1.1.1

BGP routing table entry for 64512:200:192.1.1.1/32, version 131

Paths: (1 available, best #1, table Untrusted)

Not advertised to any peer

Local

10.1.0.5 (metric 3) from 10.1.0.5 (10.1.0.5)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Extended Community: RT:64512:200,

mpls labels in/out nolabel/18

Routing entry for 192.1.1.1/32

Known via "bgp 1", distance 200, metric 0, type internal

Last update from 10.1.0.5 02:49:47 ago

Routing Descriptor Blocks:

* 10.1.0.5 (Default-IP-Routing-Table), from 10.1.0.5, 02:49:47 ago

Route metric is 0, traffic share count is 1

AS Hops 0

MPLS label: 18

MPLS Flags: MPLS Required

ping vrf Untrusted 192.1.1.1

Type escape sequence to abort.

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

!!!!!

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

But ping 192.1.1.1 I get the following debug.

*Nov 5 18:38:55: IP: s=10.10.0.10 (Vlan201), d=192.1.1.1, len 84, input feature

*Nov 5 18:38:55: ICMP type=8, code=0, Ingress-NetFlow(14), rtype 0, forus FALSE, sendself FALSE, mtu 0

*Nov 5 18:38:55: FIBipv4-packet-proc: route packet from Vlan201 src 10.10.0.10 dst 192.1.1.1

*Nov 5 18:38:55: FIBipv4-packet-proc: packet routing succeeded

*Nov 5 18:38:55: IP: tableid=0, s=10.10.0.10 (Vlan201), d=192.1.1.1 (Vlan200), routed via FIB

*Nov 5 18:38:55: IP: s=10.10.0.10 (Vlan201), d=192.1.1.1 (Vlan200), len 84, output feature

*Nov 5 18:38:55: ICMP type=8, code=0, IP Post Routing Processing(22), rtype 1, forus FALSE, sendself FALSE, mtu 0

*Nov 5 18:38:55: IP: s=10.10.0.10 (Vlan201), d=192.1.1.1 (Vlan200), len 84, output feature

*Nov 5 18:38:55: ICMP type=8, code=0, Post-Ingress-NetFlow(49), rtype 1, forus FALSE, sendself FALSE, mtu 0

*Nov 5 18:38:55: IP: s=10.10.0.10 (Vlan201), d=192.1.1.1 (Vlan200), g=192.1.1.1, len 84, forward

*Nov 5 18:38:55: ICMP type=8, code=0

*Nov 5 18:38:55: IP ARP: sent req src 10.6.0.1 0022.bef8.8800,

dst 192.1.1.1 0000.0000.0000 Vlan200

*Nov 5 18:38:55: IP: s=10.10.0.10 (Vlan201), d=192.1.1.1 (Vlan200), len 84, encapsulation failed

*Nov 5 18:38:55: ICMP type=8, code=0

Hopefully someone can spot the problem !

Thanks again for looking.

[plearmouth]

All

Just realised I gave the cef entry for the static route in the global table rather than the learnt route in the VRF.

sho ip cef vrf Untrusted 192.1.1.1 de

192.1.1.1/32, epoch 12, flags rib defined all labels

recursive via 10.1.0.5 label 18

nexthop 10.1.0.138 Port-channel2 label 19

regards

[Giuseppe Larosa]

Hello Paul,

verify on the remote PE if the labels are correct.

do a sh ip cef vrf on the remote PE

Hope to help

Giuseppe

[plearmouth]

Hi Giuseppe

I have traced the path end to end and everything seems fine. I am wondering however if it is a valid configuration.

I presume it is valid to have say an Internet connection (global table) and have VRF's on a PE with no 'physical' interfaces but learnt VPNV4 prefixes from remote PE's.

Only the system doesn't seem to do recursive lookups. The packet hits the VRF interface and then ARP's when it should do another lookup for the remote destination.

Thanks for your help in the meantime.

Paul

[Giuseppe Larosa]

Hello Paul,

>> I presume it is valid to have say an Internet connection (global table) and have VRF's on a PE with no 'physical' interfaces but learnt VPNV4 prefixes from remote PE's.

I think you need to have at least a loopbpack interface in the VRF alive to be able to use it

Hope to help

Giuseppe

[plearmouth]

Giuseppe

I did have a loopback but it just doesn't work.

I guess its just not possible to do it this way.

Thanks for all your help

Paul

[benjaminwang74]

Paul,

I am having the same problem,

3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, rcvd 2

3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, stop process pak for forus packet

3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, sending

3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, encapsulation failed

3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, rcvd 2

3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, stop process pak for forus packet

3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, sending

3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, encapsulation failed

3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, rcvd 2

Please let me know if you find a solution.

Thanks

Ben

[plearmouth]

Ben

I think I understand where I was going wrong, to provide access to a route within a VRF you would add a static route within the global table and the next-hop being a PHYSICAL interface (probably to the CE router), and so applied at the CE/PE boundary.

I was trying to apply the route at a PE that has learnt the route as a VPNV4 prefix. When you apply the static route there are NO PHYSICAL interfaces for the next hop associated with the VPN. Adding a static route pointing to an SVI or loopback within the same VPN does not provide forwarding of the packet to the remote subnet.

Personally, I think it would be nice where incases that provide a central service (i.e. Internet connection) that I could provision statics at the Internet end.

clear as mud.

Paul