Hi,

I can't do it right now (It was a live network) but I'll post it tonight.

Thanks for your response.

Samir

***originally looks like this

show ip bgp vpnv4 all 172.31.9.0

BGP routing table entry for 65535:4:172.31.9.0/24, version 4

Paths: (1 available, best #1, table internal-servers)

Flag: 0x820

Not advertised to any peer

Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)

Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:65535:4

mpls labels in/out 17/aggregate(internal-servers)

****when I import it to another vrf it looks like

sh ip bgp vpnv4 all 172.31.9.0

BGP routing table entry for 65535:4:172.31.9.0/24, version 4

Paths: (1 available, best #1, table internal-servers)

Not advertised to any peer

Local

0.0.0.0 from 0.0.0.0 (1.1.1.1)

Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:65535:4

mpls labels in/out 17/aggregate(internal-servers)

BGP routing table entry for 65535:6:172.31.9.0/24, version 591

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

Not advertised to any peer

Local, imported path from 65535:4:172.31.9.0/24

0.0.0.0 from 0.0.0.0 (1.1.1.1)

Origin incomplete, metric 0, localpref 100, weight 32768, valid, external, best

Extended Community: RT:65535:4

mpls labels in/out nolabel/aggregate(internal-servers)

Samir,

This route looks fine. Is it installed in the right VRF? If so can you let us know what you mean by "they are not accessible".

Regards

This is my core router output :

7200-1#sh ip route vrf VPN-Client-1 | i 172.31.9

B 172.31.9.0/24 is directly connected, 00:57:03, Port-channel1.600

R 172.31.90.0/29 [120/1] via 172.31.17.2, 00:00:23, Port-channel1.313

172.31.9 comes from vrf internal-servers as bgp which redistributes connected interfaces.

but when I go to CPE this is what I see :

HO-2#sh ip route | i 172.31.9

R 172.31.90.0/29 [120/1] via 172.31.190.2, 00:00:16, FastEthernet0/0

HO-2#

I checked another post which you described how to route vrfs inside a L3 switch with connected interfaces also.

When I put this on core router

ip route vrf vpn-clinet-1 172.31.9.26 255.255.255.255 port-ch 1.600 172.31.9.1

this is what I see on CPE :

HO-2#sh ip route | i 172.31.9

R 172.31.9.26/32 [120/2] via 172.31.190.2, 00:00:07, FastEthernet0/0

R 172.31.90.0/29 [120/1] via 172.31.190.2, 00:00:17, FastEthernet0/0

HO-2#

but the problem is still can't pint 172.31.9.26 from CPE although I've the route in CPE.

Thx

When you redistribute into rip you also need to apply metric:

router rip

address-family ipv4 vrf VPN-Client-1

redistribute bgp 65535 metric 5 (any less than 15)

Jon

When I redistribute bgp into that rip add family it just like adding the static route ,

address-family ipv4 vpn-client-1

redistribute connected

redistribute static

redistribute bgp 65535 metric 2

network 172.31.0.0

no auto-summary

version 2

exit-address-family

this is the output on the CPE:

HO-2#sh ip route | i 172.31.9

R 172.31.9.0/24 [120/3] via 172.31.190.2, 00:00:09, FastEthernet0/0

R 172.31.90.0/29 [120/1] via 172.31.190.2, 00:00:09, FastEthernet0/0

HO-2#ping 172.31.9.1

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

HO-2#

When I traceroute from the CPE , I hit the core router but I don't know why I can't see the destination vrf addresses, this the traceroute from CPE :

HO-2#traceroute 172.31.9.1

Type escape sequence to abort.

Tracing the route to 172.31.9.1

1 172.31.190.2 8 msec 8 msec 8 msec

2 172.31.17.1 8 msec 8 msec 8 msec

3 * * *

4 * * *

HO-2#

172.31.17.1 is the another core router local interface which vpn-client-1 traffic exits this interface.

It's forwarding vpn-client-1 vrf.

Thx

Hi,

As a general approach for trouble shooting:

1) check the existence of the required routes in both CPE. you show one CPE, but will the source IP address of the ping be known to the receiving router?

2) check for data plane problems. In MPLS L3 VPNs you need to have a label switched path between two PE routers and CEF needs to be operational.

From your configs I can see the internet VRF is not importing the other routes. So I would assume the return path is simply not known.

To fix this you might have to configure something like:

ip vrf internal-servers

rd 65535:4

route-target export 65535:4

route-target import 65535:4

route-target import 65535:5

route-target import 65535:1

!

ip vrf internet

rd 65535:5

route-target export 65535:5

route-target import 65535:5

route-target import 65535:4

Please be advised, however, that security issues might arise, if RTs are not used properly. Any change in RT import or export policy should only be implemented, if it complies with the local security regulations and gives the desired connectivity.

Hope this helps! Please use the rating system.

Regards,

Martin

Thx for your response , nearly fixed it.

One more thing , is there any reason two connected interfaces belonging to separate VRF's on the same box can't access each others networks.

They can only ping routers int ip, like this :

7200-1#sh ip route vrf internal-servers

Routing Table: internal-servers

Gateway of last resort is X.X.60.130 to network 0.0.0.0

X.X.60.0/30 is subnetted, 1 subnets

B X.X.60.128 is directly connected, 00:35:54, Port-channel1.448

172.31.0.0/24 is subnetted, 1 subnets

C 172.31.9.0 is directly connected, Port-channel1.600

S* 0.0.0.0/0 [1/0] via X.X.60.130

7200-1#

7200-1#sh ip route vrf internet | i 172.31.9.0

B 172.31.9.0/24 is directly connected, 00:37:10, Port-channel1.600

S* 0.0.0.0/0 [1/0] via X.X.60.130

Apart from NAT , Internal servers should be able to see outside , hence they've got the route as directly connected , in addition there are two static routes as you can see both pointing to internet interface.

Anyway thx again for your help