SRX

Hello,

I'm currently studying for JNCIP-SEC, and I came across a paragraph, as below:

"One more method exists to route between routing instances, using the next-table option of a static route. This option has specific unidirectional applications and is not a generally preferred method dude to the possibility of looping traffic between routing instances on Junos stateless devices. However, this method becomes more useful with Junos security devices because bidirectional flow is enabled once the session is established. Recall that routing (and its reverse path) is set up in the first packet flow"

I understand how you can get a next-table routing loop, but I don't see how the bidirectional flow is meant to alleviate that. My understanding is that if I had a next-table loop in an SRX, then route-lookup process would never complete due to infinite recursion and the session wouldn't establish in the first place.

Is my understanding correct, or am I missing something from that paragraph?

Thanks in advance.

Hello,

To create recursion between 2 tables, You need something like this:

set routing-instances A routing-options static route X.Y.Z.W next-table B.inet.0
set routing-instances B routing-options static route X.Y.Z.W next-table A.inet.0

 JUNOS won't allow You to commit that.

However, You might have a legit bidir packet stream with src.IP W.Z.Y.X and dst.ip X.Y.Z.W, going between interfaces in RI A & B. Then You would need this config to let it pass:

set routing-instances A routing-options static route X.Y.Z.W next-table B.inet.0
set routing-instances B routing-options static route W.Z.Y.X next-table A.inet.0

 JUNOS won't let You to commit it either.

You will need to use static in 1 direction and FBF in another, to let this legit bidir stream to pass.

BUT - on SRX., You can let this legit bidir packet stream to pass by configuring only 1 line:

set routing-instances A routing-options static route X.Y.Z.W next-table B.inet.0

On SRX, the reverse flow is taken care of automatically during 1st session establishment, and You can't influence asymmetric reverse flow routing on SRX in flow-mode. By saying "asymmetric" I mean that:

- forward flow passes RI A->RI B

- reverse flow is meant to pass RI B-> RI C

HTH

Thanks
Alex

Hi aarseniev,

I guess the key is that you can't commit config with tables pointing to each other, but on an SRX you don't need to.

I appreciate your help.

Hi,

Config with tables pointing to each other is not allowed in Junos, Because it can create the routing loops.

Regards

Satinder Singh

>On SRX, the reverse flow is taken care of automatically during 1st session establishment, and You can't influence

>asymmetric reverse flow routing on SRX in flow-mode.

Actually you can.

If a packet A->B enters an IFL in VR XXX with an ingress FBF filter configured like "than routintg-instance YYY" than the reverse lookup ignores ingress FBF and is performed in XXX, not YYY.

So you forward wing will go from XXX to YYY and the reverse will stay in YYY.

Not 100% sure what will happen if you configure a static in XXX like "route A/32 next-table ZZZ.inet.0" but I suspect that JUNOS should allow you to redirect the reverse wing from XXX to ZZZ.

Hello there,

---

@onemorepash wrote:

>On SRX, the reverse flow is taken care of automatically during 1st session establishment, and You can't influence

>asymmetric reverse flow routing on SRX in flow-mode.

 

Actually you can.

 

If a packet A->B enters an IFL in VR XXX with an ingress FBF filter configured like "than routintg-instance YYY" than the reverse lookup ignores ingress FBF and is performed in XXX, not YYY.

 

So you forward wing will go from XXX to YYY and the reverse will stay in YYY.

 

Not 100% sure what will happen if you configure a static in XXX like "route A/32 next-table ZZZ.inet.0" but I suspect that JUNOS should allow you to redirect the reverse wing from XXX to ZZZ.

---

Yes in that case one can create asymmetric flows in SRX using FBF+routing.

I have to qualify my previos statement then:

On SRX, the reverse flow is taken care of automatically during 1st session establishment, and You can't influence asymmetric reverse flow routing on SRX in flow-mode, by means of routing (i.e. using static|IGP|BGP routes) only. By saying "asymmetric" I mean that:

- forward flow passes RI A->RI B

- reverse flow is meant to pass RI B-> RI C

Thanks for spotting that.

Regards

Alex

Hello,

Does this mean that using FBF to place packets (a->b) from RI XXX to YYY, in the reverse flow it will be routing table YYY that determines the reverse path?

This can only be done with a combination of a static route of a/32 in RI XXX pointing to next table YYY, correct?

My understanding is that the process would look like this:

A packet (a->b) comes into RI XXX, the SRX determines, due to FBF, the packet goes to routing-instance YYY, but it also does a reverse lookup for a/32 in XXX, and determines that the next-hop to a/32 is YYY. This will then mean that on the reverse flow, that RI YYY will determine the path back to a/32 ?

Did I understand correctly, or am I completely off?

Regards,

Alshan

Hello,

For a given packet, the reverse route lookup (or src.IP lookup in route table if You prefer) takes place AFTER dst.IP lookup and in the same table.

For Your example, this means that RI YYY must have a valid route to dts.IP and a valid route to a src.IP.

A valid route to a src.IP could be a "next-table" static route or a route leaked from XXX to YYY. 

One more condition is enfoced during these lookups: 

- if dst.IP+policy lookup produces different zone results from src.IP route lookup (i.e. dst.IP+policy lookup produces "from zone id X to zone id Y" and src.IP route lookup produces "from zone id Y to zone id W") then such pkt is dropped and flow is not installed. 

HTH

Thanks
Alex