10-29-2008 04:26 PM
Hi,
is there any reason two connected interfaces belonging to separate VRF's on the same box can't access each others networks.
This is the VRF config :
ip vrf internet
rd 65535:5
route-target export 65535:5
route-target import 65535:5
route-target import 65535:4
!
ip vrf internal-servers
rd 65535:4
route-target export 65535:4
route-target import 65535:4
route-target import 65535:5
!
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.
Thx
10-29-2008 06:09 PM
Samir,
You should definitely be able to ping from devices on subnet 172.31.9.0 and subnet X.X.60.128 and vice versa as long as devices in these subnets have a default gateway pointing at the respective router interface IP address.
Have you tried without NAT?
Regards
10-29-2008 06:22 PM
Hi,
I've a VRF/interface excatly like internal server named as public servers with public addresses as below :
ip vrf public-servers
rd 65535:3
route-target export 65535:3
route-target import 65535:3
route-target import 65535:5
interface Port-channel1.604
description Public IPs
encapsulation dot1Q 604
ip vrf forwarding public-servers
ip address X.X.60.1 255.255.255.240
The internet interface follows as :
interface Port-channel1.448
description Internet
encapsulation dot1Q 448
ip vrf forwarding internet
ip address X.X.60.129 255.255.255.252
ip nat outside
ip virtual-reassembly max-reassemblies 32
There is also a static routes :
ip route vrf internet 0.0.0.0 0.0.0.0 X.X.60.130
ip route vrf public-servers 0.0.0.0 0.0.0.0 X.X.60.130
*** I didn't put the route-target import for public server in previous post just to make it short but this one is also there (meaning the route back exists).
Even from this public servers interface (if you put nat aside as a probable issue) , I'm only able to ping X.X.60.129(local router) sourced by public server interface not the .30 which is the service provider.
Route table for public servers VRF is exactly like the internal servers.
Thx
10-29-2008 06:33 PM
Samir,
It sounds like the service provider device might be missing a route back to the device sourcing the ping.
Regards
10-29-2008 07:02 PM
Hi,
There is route back to our public IPs, hence I can go on a non VRF based (traditional one)solution and I can easily ping out sourced by public-serv interface.
just by pointing everything to internet interface.
Thx.
10-30-2008 06:20 AM
Samir,
I do not think the VRF configuration is to blame. You need to perform basic troubleshooting. I am not sure inter VRF will work. Can you try without. What is the source address you use when pinging the SP device (.130). Is there a route back to that source address on the ISP device.
10-30-2008 03:10 PM
Hi,
Without VRFs works perfectly, Source address can be any of the interfaces which right now doesn't work (i.e internal or public servers).
There are a couple of statics pointing to us from SP which works right now fine as I said.
Right now it's working in a shared Edge traditional VPN with no problem.But I don't understand why when I move to a VRF based solution inter VRF on the same device which is the simplest scenario doesn't work?!?!
Thx
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: