I'm not expecting any side effect with this command but think this configuration as a Hack as it's not really the purpose of vrf select:
The idea of VRF is to separate traffics. If you end with a lot of traffic leaking between VRFs and GRT maybe the design should be change to integrate this requirement otherwise you have a complex configuration difficult to troubleshoot.
Thanks for the response.
Why i want to do this is i have a fwsm which sits in between my lan and serverfarm and other entity A. This means that to access anything behind fwsm one had to come to fwsm and checked and than forwarded.
We have entity XYZ whose network is hosted on 4507 which is protected and sits behing fwsm.
the devices which belongs this entity XYZ is in my LAN to be connected via diff VLAN other than my LAN.
layer 3 interface of this vlan will be in diff VRF than LAN.
separete link to 4507 behind fwsm is connected to the switch hosting vrf l3 interface. no fwsm in between vrf and 4507.
this means i have whole of the entity in my campus connected directly to the 4507 behind fwsm.
on 4507 route leaking will be done for the connected interfaces and vrf to all subnets on 4507 and vrf and talk to each other.
anything which wants to communicate with from entity XYZ from 4507 to LAN will come through fwsm checked with ACL.
default route will be injected in OSPF of vrf with next hop as inside interface of fwsm connected with 4507.
So i think only default route + connected routes on 4507 will leaked from GRT to VRF. and when someone wants to communicate to LAN side they have to come through fwsm with default route injected in ospf.
Do you think it is going to be an issue with design basis and troubleshooting point of view. Do tell me if you want further inputs on design
Thanks in advance
a L3 level drawing would be helpful here. From this drawing, tell me who needs to talk to who and which path communication should follow.
Looks good to me. Another solution could be to terminate the VRF directly on the Cat 6 with the FWSM and use the FWSM to provide routing between the GRT and the VRF. I have to say I never tested such implementation ;-)
The things we tested were extended ping in vrf. But the problem i faced today is that i have connected a host in the vlan where we have configured vrf select source and vrf receive vrf-name. this host is not able to reach the subnets in the vrf table. It can only ping the default gateway nothing else. All routes are showing up in GRT and VRF as well.
As per previous posts, we successfully received the connected interfaces in GRT and VRF table as well. but the hosts in connected vlan are not able to reach the subnets in vrf table.
I didnot see "vrf selection source " configuration in the config you provided????
vrf selection source
I think when you use "vrf receive" command by default all traffic generated beside the interface is assigned to vrf. no need to define the source or ip addresses.
By the way i had resolved the issue...
the problem was when you use vrf select source and vrf receive command it makes the interface to be shown up in GRT and VRF table. but when any hosts whose traffic originated within the connected vlan or interface by default belong to GRT, so we have to leak the routes from Vrf to GRT to make the communication happen..