SRX

Hi J-NET Community,

 

i'm currently testing a SRX 240 Gateway, kindly provided by TLK (German Juniper distributor).

 

Nearly everything works as expected, but FBFcauses some trouble with 2 ISPs (connected by PPPoEoA). The primary subnet (10.0.0.0/16) is separated in /24 subnets (using L3 Switch). Layer 3 Switch has IP 10.0.255.2/24, SRX 10.0.255.4/24. 3 subnets (10.0.128.0/24, 10.0.129.0/24, 10.0.130.0/24) should be source natted outside, using pp0.1, all other connections should be natted outside (by pp0.0). DMZ is routed, using pp0.0

 

Everything works fine, but i can't reach the SRX directly (e.g. SSH connections) from the 3 Subnets, routed by the other routing instance.

 

Examples:

(from 10.0.128.1) ping -c 5 10.0.255.4
PING 10.0.255.4 (10.0.255.4) 56(84) bytes of data.
^C
--- 10.0.255.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4009ms

 

(from SRX, 10.0.255.4) ping 10.0.128.1 count 5
PING 10.0.128.1 (10.0.128.1): 56 data bytes
64 bytes from 10.0.128.1: icmp_seq=0 ttl=63 time=1.522 ms
64 bytes from 10.0.128.1: icmp_seq=1 ttl=63 time=1.119 ms
64 bytes from 10.0.128.1: icmp_seq=2 ttl=63 time=1.229 ms
64 bytes from 10.0.128.1: icmp_seq=3 ttl=63 time=1.116 ms
64 bytes from 10.0.128.1: icmp_seq=4 ttl=63 time=1.115 ms

--- 10.0.128.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.115/1.220/1.522/0.157 ms

 

(from 10.0.2.1) ping 10.0.255.4
PING 10.0.255.4 (10.0.255.4) 56(84) bytes of data.
64 bytes from 10.0.255.4: icmp_seq=1 ttl=63 time=0.436 ms
64 bytes from 10.0.255.4: icmp_seq=2 ttl=63 time=0.471 ms
64 bytes from 10.0.255.4: icmp_seq=3 ttl=63 time=0.489 ms
64 bytes from 10.0.255.4: icmp_seq=4 ttl=63 time=0.475 ms
64 bytes from 10.0.255.4: icmp_seq=5 ttl=63 time=0.481 ms
^C
--- 10.0.255.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4012ms
rtt min/avg/max/mdev = 0.436/0.470/0.489/0.026 ms

 

 

Routing-Table etc. looks fine!

 

Flow debug messages and config (blanked) is attached. The SRX runs on JUNOS Software Release [9.6R1.13]

 

Please take especially a look at "install nsp2 failed".

 

Any help is appreciated 😉

Do you see arp entries from the host you're pinging from? I

Hi Screenie,

 

the requests go through the L3 Switch (currently ProCurve 3400CL ).

 

root@gate-rok> show arp
MAC Address       Address         Name                      Interface     Flags
00:15:60:7a:3b:40 10.0.255.2      10.0.255.2                ge-0/0/0.0    none

 

Accessing my connection through pp0.1 works flawless:

(from 10.0.128.1) traceroute to www.google.de (74.125.87.147), 30 hops max, 40 byte packets
 1  10.0.128.254 (10.0.128.254)  1.477 ms  1.754 ms  2.042 ms
 2  10.0.255.4 (10.0.255.4)  0.453 ms  0.428 ms  0.572 ms
 3  217.0.116.51 (217.0.116.51)  8.601 ms  9.533 ms  38.938 ms
 4  217.0.67.130 (217.0.67.130)  11.561 ms  12.445 ms  13.485 ms
 5   (194.25.6.30)  20.216 ms  21.855 ms  22.993 ms
 6  72.14.198.5 (72.14.198.5)  21.346 ms  22.105 ms  23.592 ms

...

 

 I don't think there are any ARP related problems.

I think you have Echo Reply pkt looping somehow:

Sep 20 17:42:07 17:42:06.1080422:CID-0:RT:flow_ipv4_rt_lkup success 10.0.255.4, iifl 0x0, oifl 0x0

Sep 20 17:42:07 17:42:06.1080422:CID-0:RT:  route lookup: dest-ip 10.0.255.4 orig ifp .local..0 output_ifp .local..0 orig-zone 2 out-zone 2 vsd 0
Sep 20 17:42:07 17:42:06.1080422:CID-0:RT:  route to 10.0.255.4


Same input and output interface.

 

I would suggest, as a start, except own IP 10.0.255.4 in your input FW filter from being FBF-ed:

 

set firewall family inet filter pbr-dtag-manitu term to-own from address 10.0.255.4/32

set firewall family inet filter pbr-dtag-manitu term to-own then accept

insert firewall family inet filter pbr-dtag-manitu term to-own before term to-dtag

 

Hi aarseniev,

 

that looks pretty good !

 

The SRX is now also reachable by the FBFed subnets. But, do you think, the old behavior is correct?

 

Greetings

 

Ulf

I don't think it is correct as your debug indicates that route lookup for return Echo Reply packet is fine but then it appears that the packet got looped. But I might be missing a part of the picture. In any case I encourage you to open a JTAC case to get this behaviour properly explained.

All IP Packets are affected by this issue.

 

The SRX is registered to my distributor. I'll forward this thread and they can open a JTAC case for some more explanation.

 

Thanks again

 

Ulf