SRX

Hello,

I have a two ISP scenario, I created two routing instances (type=forwarding). When I publish anything on the secondary ISP the reply packets are sent out on the primary ISP's interface. I configured a firewall filter for this, but does not help.

I attached the config part and the trace flow. In the trace file line 54 & 56 you can see that it chooses ge-0/0/15 instead of ge-0/0/14

I was advised to change the instance type to virtual router, but that case I have to create two separate untrust zone what makes the configuration much more complex, and to be honest I tried VR annd it worked but ip monitoring feature was not working with that.

I'm using 12.1X46 version.

Any help would be appreciated.

Balázs

Attachment(s)

config.txt   4 KB 1 version

trace-test_env.txt   6 KB 1 version

Hi BB,

This is expected behavior with forwarding-type instance because the reverse route lookup (route towards source for return traffic) happens on the original routing instnace where the packet arrived initially.

In this case the packet arrives on Inet.0 (ge-0/0/15 and ge-0/0/14 are part of inet.0) and reverse route lookup will happen on inet.0.

With forwarding type instance we can only influence the forwarding-route (towards destination) .

Unfortunately you have to go with virtual routing and seperate zones if you want to send return traffic via ge-0/0/14.

Hello Suraj,

first thanks for the very fast answer. This is exactly what support advised to me. I have some doubt about this, for two reasons:

My configuration used to work properly, I don't know when it got wrong with some config modification or FW upg, but now I have this issue what I was able to reproduce in my test lab.

The second reason is that I have access to another environment where this configuration is working. There there is no FBF filter atached to that config, I attach the routing table of both environment.

In the working config fe-0/0/7.0 is the primary route and pp0.1 is the secondary and I can access the same DNAT published resource on both interfaces same time. I did a flow trace and saw that when cerating session from pp0.1 it assigns the same if as outgiong if for the revese route.

Thanks,

Balázs

Attachment(s)

routing-table-working-config.txt   2 KB 1 version

routing-table-test-config.txt   2 KB 1 version

Hi BB,

Can you share the configuration from working setup?

Hello,

the other issue is that I attached this firewall filter to the ge-0/0/14 interface:

set firewall filter filter-ISP-B term ISP-B-incoming from interface ge-0/0/14.0
set firewall filter filter-ISP-B term ISP-B-incoming then routing-instance ISP-B
set firewall filter filter-ISP-B term default then accept

This sould install the incoming packet to the ISP-B routing instance and so in that routing instance the deafult route is on ge-0/0/14

Thanks,

Balázs

Hi BB,

WIth the help of firewall filter you can influence the forwarding route lookup only not reverse route.

Reverse route lookup will happen on the instance on which the packet arrived initially.

In this case packet arrived on inet.0/ge-0/0/14 and then moved to forwarding instnace using your filter configuration.

So, forwarding route lookup will happen on forwarding instance and reverse route lookup on inet.0.

If you put ge-0/0/14 on a virtual router, both revrese and forwarding route lookup will take place in the virtual routing instance table.

Hello Suraj,

I changed my comfig to type VR according to this article:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB15545&smlogin=true

Now the backup line works, but the primary not,      ## I have to correct myself, the line works just the mgmt acces don't ! That is a problem because of VPN so the primary interface won't accept VPN or any traffic directed to itself.

The article example has a firewall filter that directs traffic to TRUST-VRF.

I think I implemented the article in my lab without errors, but in my TRUST-VRF there is no default route so this is why it is not working.

Here is my route, I attach my new configuration:

trust-vrf.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.6.0/24     *[Direct/0] 00:06:39
                    > via vlan.0
192.168.6.1/32     *[Direct/0] 00:06:41
                    > via lo0.0
192.168.6.254/32   *[Local/0] 00:06:39
                      Local via vlan.0
192.168.12.0/24    *[Direct/0] 00:06:39
                    > via ge-0/0/14.0
192.168.12.199/32  *[Local/0] 00:06:39
                      Local via ge-0/0/14.0
217.150.139.160/28 *[Direct/0] 00:06:41
                    > via ge-0/0/15.0
217.150.139.164/32 *[Local/0] 00:06:41
                      Local via ge-0/0/15.0

Attachment(s)

config_virtual-router_type_.config.txt   12 KB 1 version

Can you tell me to whats the source and destination IP address used for management connection thats not working?

Hello,

Yes, the interface IP  217.150.139.161 is not answering for me after changing config to VR type.

I tried with ping and ssh both, as it was accessible before changing the config to VR.

Now I think that really you're right but this behavior is really bad.

Thanks for your help,

Balázs

Hi BB,

You dont need ISP-A filter on ge-0/0/15, please remove the same and then check the connection.

delete interfaces ge-0/0/15 unit 0 family inet filter

commit

Regarding the Junos design, this is to support scenarios like asymmetric routing outside the box or its just one way communication.

Sorry I already cleared the config. Yes I think I don't need that.

Balázs