SRX

Hi,

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.

Thanks.

Hi,

Instead of setting up static routes to send the traffic between routing instances, you can use the rib groups to share the routes from custom routing instance to inet0.

Please refer the KB below for the same. 

https://kb.juniper.net/InfoCenter/index?page=content&id=KB19787

Thanks 

Brijil

Hi,

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?

Thanks.

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.

Cheers.

Hi jjelliott1821,

Using next-table in a way that will cause fowarding loop is really bad idea. It may congest the PFE, refer following KB

https://kb.juniper.net/InfoCenter/index?page=content&id=KB35314

The policy that you are using looks okay to me.

Alternatively you can use rib-groups to leak direct route from one VRF to another VRF (including main).

Here is a good example on how to achieve leak via rib-group

http://matt.dinham.net/route-leaking-with-junos/

PS: Please mark my response as solution if it answers your query, kudos are appreicated too!

Thanks

Vishal

Hi jjelliott1821

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.

Pablo

Hi Pablo,

Do you have an example of the following:

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.

Is it just two static routes within the vrf table and master table?

Thanks.

Hello,

---

@pablo88020 wrote:

• 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.

 

---

A final-final approach is to use static flow routes with redirect to VRF

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/flow-edit-routing-options.html

But I do agree that "next-table" causes packet recirculation due to double route lookup needed and thus halves the performance.

HTH

Thx

Alex