vSRX

Expand all | Collapse all

Unable to ping lo0 interface on vSRX in GNS3

Jump to Best Answer
  • 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