SRX

last person joined: 2 days ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.

  • 1.  Unable to ping lo0 interface on vSRX in GNS3

    Posted 06-28-2019 08:12

    Hello, 

     

    I am unable to ping the lo0 interface on my vSRX. I am labbing on the following topology.

     

    lo0.png

     

    This is a Firefly running on the GNS3 VM. Briefly, interfaces ge-0/0/0.0 and lo0.0 are in zone1 and ICMP traffic is allowed on this zone.  I cannot ping the lo0 interface on the vSRX. 

     

    I want to know if this is a GNS3/vSRX quirck, or have I actually misconfigured anything on the vSRX.  

    When I try to ping from the IOS-XR-1 towards ge-0/0/0 it works.

    RP/0/0/CPU0:ios#show ip int br
Fri Jun 28 14:42:56.341 UTC

Interface IP-Address Status Protocol
Loopback0 10.1.1.1 Up Up
MgmtEth0/0/CPU0/0 unassigned Shutdown Down
GigabitEthernet0/0/0/0 192.168.12.1 Up Up
GigabitEthernet0/0/0/1 unassigned Shutdown Down
GigabitEthernet0/0/0/2 unassigned Shutdown Down
GigabitEthernet0/0/0/3 unassigned Shutdown Down
GigabitEthernet0/0/0/4 unassigned Shutdown Down
GigabitEthernet0/0/0/5 unassigned Shutdown Down
GigabitEthernet0/0/0/6 unassigned Shutdown Down
GigabitEthernet0/0/0/7 unassigned Shutdown Down
RP/0/0/CPU0:ios#ping 192.168.12.2
Fri Jun 28 14:43:05.761 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

    When I try to ping lo0.0 it fails, even though I have route.

    RP/0/0/CPU0:ios#ping 10.2.2.2
Fri Jun 28 14:43:50.217 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
.....
RP/0/0/CPU0:ios#show route 10.2.2.2
Fri Jun 28 14:44:48.044 UTC
Routing entry for 10.2.2.2/32
Known via "ospf 1", distance 110, metric 1, type intra area
Installed Jun 28 14:19:47.906 for 00:25:00
Routing Descriptor Blocks
192.168.12.2, from 10.2.2.2, via GigabitEthernet0/0/0/0
Route metric is 1
No advertising protos.

    Oddly enough, pinging IOS-XR-1 from the vSRX with source lo0.0 works just fine. 

    root> ping 10.1.1.1 source 10.2.2.2
PING 10.1.1.1 (10.1.1.1): 56 data bytes
64 bytes from 10.1.1.1: icmp_seq=0 ttl=255 time=8.100 ms
64 bytes from 10.1.1.1: icmp_seq=1 ttl=255 time=9.008 ms
^C
--- 10.1.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.100/8.554/9.008/0.454 ms

    Please see below configuration on the SRX 

    root> show configuration | display set
set version 12.1X47-D15.4
set system root-authentication encrypted-password "$1$a4EKwDdk$r.ylgf5ZoxYcwXf2xmmRb0"
set system services ssh
set system services web-management http interface ge-0/0/0.0
set system syslog user * any emergency
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set interfaces ge-0/0/0 unit 0 family inet address 192.168.12.2/24
set interfaces ge-0/0/1 unit 0 family inet address 192.168.23.2/24
set interfaces lo0 unit 0 family inet address 10.2.2.2/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set security policies from-zone zone1 to-zone zone2 policy z1z2 match source-address any
set security policies from-zone zone1 to-zone zone2 policy z1z2 match destination-address any
set security policies from-zone zone1 to-zone zone2 policy z1z2 match application junos-icmp-all
set security policies from-zone zone1 to-zone zone2 policy z1z2 then permit
set security zones security-zone zone1 host-inbound-traffic system-services ping
set security zones security-zone zone1 host-inbound-traffic system-services all
set security zones security-zone zone1 host-inbound-traffic protocols ospf
set security zones security-zone zone1 interfaces ge-0/0/0.0
set security zones security-zone zone1 interfaces lo0.0
set security zones security-zone zone2 host-inbound-traffic protocols ospf
set security zones security-zone zone2 interfaces ge-0/0/1.0

    Any ideas or suggestions are appreciated.



  • 2.  RE: Unable to ping lo0 interface on vSRX in GNS3

     
    Posted 06-28-2019 08:32

    The configuration on Junos SRX looks fine to me. Maybe I missed something. But we can trouble shoot

     

    1. Turn on "monitor traffic interface ge-0/0/0.0" on SRX when you are pinging from Cisco. Check what source Cisco is using as source, ideally it should be 10.1.1.1. If not, try to specify a source on Cisco side 

    2. If Cisco is not using 10.1.1.1 as source address, check "show route x.x.x.x" on SRX and see if you have the route

     

     



  • 3.  RE: Unable to ping lo0 interface on vSRX in GNS3

     
    Posted 06-28-2019 08:35

    Did you try to capture the ICMP packets on the SRX interface when you initiate the ping from Cisco? It will tell you whether the packets are being received from the Cisco

     

    Here is an exmample - I am pinging lo0 address on this host from a directly connected neighbor.

    > monitor traffic interface xe-1/1/0 no-resolve matching icmp 
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on xe-1/1/0, capture size 96 bytes

08:34:17.418307  In IP 7.7.7.1 > 68.86.11.52: ICMP echo request, id 62988, seq 63, length 64
08:34:17.418335 Out IP truncated-ip - 24 bytes missing! 68.86.11.52 > 7.7.7.1: ICMP echo reply, id 62988, seq 63, length 64
08:34:18.419149  In IP 7.7.7.1 > 68.86.11.52: ICMP echo request, id 62988, seq 64, length 64
08:34:18.419170 Out IP truncated-ip - 24 bytes missing! 68.86.11.52 > 7.7.7.1: ICMP echo reply, id 62988, seq 64, length 64


  • 4.  RE: Unable to ping lo0 interface on vSRX in GNS3
    Best Answer

    Posted 06-28-2019 08:45
    Since both interfaces are part of a same security zone zone1, you have to create an intra-zone policy from zone1 to zone1 to ping the lo0 ip. Or remove lo0 from the zone config.






  • 5.  RE: Unable to ping lo0 interface on vSRX in GNS3

    Posted 06-28-2019 09:09

    For some reason which escapes me, this worked. 

     

    Added the following config on the SRX. 

    set security policies from-zone zone1 to-zone zone1 policy z1z1 match source-address any
set security policies from-zone zone1 to-zone zone1 policy z1z1 match destination-address any
set security policies from-zone zone1 to-zone zone1 policy z1z1 match application any
set security policies from-zone zone1 to-zone zone1 policy z1z1 then permit

    And now the ping works just fine. 

    RP/0/0/CPU0:ios#ping 10.2.2.2 source 192.168.12.1
Fri Jun 28 15:42:05.128 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
RP/0/0/CPU0:ios#ping 10.2.2.2 source 10.1.1.1
Fri Jun 28 15:42:11.408 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms

    But what gives ? The destination address of the echo requests is 10.2.2.2. When this traffic enters the SRX, it does through ge-0/0/0.0. For the SRX does this count as intra-zone traffic which is denied by default ? 

     



  • 6.  RE: Unable to ping lo0 interface on vSRX in GNS3

    Posted 06-28-2019 10:26

    Yes, since lo0 is configured as part of same zone (zone1) as incoming interface ge-0/0/0. 

     

    Host inbound traffic processing is given below:

    When the SRX receives traffic destined to itself, it first examines whether the destination IP of the traffic is the incoming interface IP. If so, the Junos OS checks to see if the service or protocol is allowed on that interface by referencing the configuration under the host-inbound-traffic statement for the zone or interface. If the traffic is permitted by the configuration under the host-inbound-traffic statement, then the Junos OS checks to see if there is a junos-host zone security policy.
    If there is a junos-host zone security policy that matches the traffic, the traffic is acted up on based on the action in the policy.
    If no junos-host zone security matches the traffic, then the traffic is permitted.


    If the traffic is destined for another interface IP other than the incoming interface (in this case lo0.0 ip), the device first evaluates security policies to determine if the traffic is allowed. It then the device examines the list of services and protocol s allowed on the destination interface by using the host-inbound-traffic statement within the corresponding zone.

     

     



  • 7.  RE: Unable to ping lo0 interface on vSRX in GNS3

    Posted 06-28-2019 08:58

    Hello,

    I am unable to ping the lo0.0 on the vSRX regardless of whatever source I use. Routing is fine, I have 10.2.2.2 in the IOS-XR-1 and I have the return routes in the routing table on the vSRX.

     

    RP/0/0/CPU0:ios#ping 10.2.2.2 source 10.1.1.1
Fri Jun 28 15:26:12.963 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RP/0/0/CPU0:ios#ping 10.2.2.2 source 192.168.12.1
Fri Jun 28 15:26:35.392 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RP/0/0/CPU0:ios#

    And the routes on the vSRX

    root> show route

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

10.1.1.1/32        *[OSPF/10] 01:10:09, metric 2
                    > to 192.168.12.1 via ge-0/0/0.0
10.2.2.2/32        *[Direct/0] 02:50:49
                    > via lo0.0
10.3.3.3/32        *[OSPF/10] 01:12:23, metric 2
                    > to 192.168.23.3 via ge-0/0/1.0
192.168.12.0/24    *[Direct/0] 02:48:14
                    > via ge-0/0/0.0
192.168.12.2/32    *[Local/0] 02:50:12
                      Local via ge-0/0/0.0
192.168.23.0/24    *[Direct/0] 02:48:14
                    > via ge-0/0/1.0
192.168.23.2/32    *[Local/0] 02:50:01
                      Local via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 02:50:58, metric 1
                      MultiRecv

    Regarding the packet capture, I used both monitor traffic interface on the vSRX and the embedded packet capture in GNS3.

    For some reason or another, I cannot see the packets on the vSRX monitor traffic command. However, the ICMP echo requests are visible in the GNS3 packet capture (see attached pcap).

    root> monitor traffic interface ge-0/0/0
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/0, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

15:25:49.044108 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:25:54.669154  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:25:58.704670 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:04.184808  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:06.795161 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:14.121342  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:16.345768 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:21.996176  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, LS-Update, length 76
15:26:23.006613 Out IP truncated-ip - 4 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, LS-Ack, length 44
15:26:23.537140  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:24.626016 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:32.958452  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:33.806748 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:42.224985  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:42.808639 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:50.762522 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:26:52.164226  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:00.338248 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:01.419876  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:08.015357 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, LS-Update, length 60
15:27:10.035525  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, LS-Ack, length 44
15:27:10.224349 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:11.285635  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:19.000488 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:20.835210  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:28.291342 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:30.529253  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:37.381334 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:39.771659  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:45.411498 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:49.309079  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:54.248601 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:27:58.607523  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:28:02.778013 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60

    This is rather strange. But I cannot see the packets on the monitor traffic in the vSRX even when I ping ge-0/0/0.0, which works.

    RP/0/0/CPU0:ios#ping 192.168.12.2
Fri Jun 28 15:33:30.793 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/19 ms

root> monitor traffic interface ge-0/0/0
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/0, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

15:33:11.029086 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:33:12.859759  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:33:18.580848 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:33:22.551047  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
15:33:28.206080 Out IP truncated-ip - 20 bytes missing! 192.168.12.2 > 224.0.0.5: OSPFv2, Hello, length 60
15:33:31.787104  In IP 192.168.12.1 > 224.0.0.5: OSPFv2, Hello, length 60
^C
6 packets received by filter
0 packets dropped by kernel


  • 8.  RE: Unable to ping lo0 interface on vSRX in GNS3

    Posted 06-28-2019 09:03
    Since both interfaces are part of a same security zone zone1, you have to create an intra-zone policy from zone1 to zone1 to ping the lo0 ip. Or remove lo0 from the zone config