I am having an issue with traffic being forwarded correctly. I have a VRF with a static route pointing to the inet.0 table, as shown below.
set interfaces xe-1/1/2 unit 0 family inet address 192.168.2.1 set routing-instances vrf-2 instance-type virtual-router
set routing-instances vrf-2 interface xe-1/1/2.0
set routing-instances vrf-2 routing-options static route 192.168.3.0/24 next-table inet.0
The traffic then gets sent down a ipsec tunnel in inet.0 to the destination.
The problem I am having is inet.0 has no knowledge of the source network 192.168.2.0/24 so when traffic is returned to 192.168.2.1 its being dropped, for example when i do "show route 192.168.2.1" an entry is only shown under vrf-2.inet.0
Is there some configuration I can add to inet.0 so traffic can get back into vrf-2 (192.168.2.0/24), I want this to be as simple as possible and scalable as I add more VRF's.
If possible I wanted to avoid using rib groups or imports using policy statement, I want to push routes between routing tables using static routes. Is there a way with static routes to make inet.0 aware of the local/direct vrf network, or must I use another method?
I have got round this so far by doing the following:
set policy-options policy-statement Get-VRF2 term 1 from instance vrf-2
set policy-options policy-statement Get-VRF2 term 1 from interface xe-1/1/2.0
set policy-options policy-statement Get-VRF2 term 1 from route-filter 192.168.2.0/24 exact
set policy-options policy-statement Get-VRF2 term 1 then accept
set policy-options policy-statement Get-VRF2 term last then reject set routing-options instance-import Get-VRF2
Just wanted a simpler way if there is one, as pointing a static route from inet.0 to the vrf.inet.0 table creates a loop warning and i cant commit it.
Basically, the methods for communicating between routing instances are as follows:
• static route with a next-hop next-table pointing to the appropriate routing table which contains more accurate information • rib-groups to mirror routing information from one route-table to another. However, in many cases, in order to make this work, interface-routes also need to be mirrored. RIB Group policy can be used to constrain the routing information • instance-import and instance-export statements configured within the individual routing-instances to leak routes from one table to another. Again, policy can be used here to constrain the routing information. This method is more straightforward than the rib-group method • A final approach is to use physical interfaces or logical-tunnels to stitch routing-instances and use a routing protocol or static routes across this connection between the two routing-instances.