SRX

 View Only

  • 1.  SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-14-2025 19:44

    Good afternoon.
    Input data: SRX1600 * 2 = cluster (HA, redundancy group, etc...)
    An reth#.# interface is attached to the untrust zone
    A public address of the inet family has been added to the reth#.# interface.
    The ping from outside is successful. 

    Then I combine the following ge- interfaces in reth11.44, attach them to the security zone, assign a public address, and eventually 2% of the pings reach this address.

    Whatever addresses I assign, I achieve an unsuccessful result.
    This only happens with interfaces: ge-0/0/11 and ge-7/0/11

    Detailed data:
    JUNOS 23.4R2.13

    # show chassis cluster
    redundancy-group 4 {
        node 0 priority 100;
        node 1 priority 99;
        interface-monitor {
            ge-0/0/11 weight 255;
            ge-7/0/11 weight 255;
        }

    # show interfaces reth11.44
    description sale_200_Mb/s;
    vlan-id 44;
    family inet {
        address 19.36.52.52/28;
    }

    # show security zones security-zone sale
    screen untrust-screen;
    interfaces {
        reth11.44 {
            host-inbound-traffic {
                system-services {
                    ping;
                }
            }
        }
    }



    ------------------------------
    Denis Rasskazov
    ------------------------------


  • 2.  RE: SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-15-2025 06:35

    set chassis cluster reth-count 12

    Perhaps that does the trick?

    Oh, and do upgrade to 23.4R2-S4!




  • 3.  RE: SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-16-2025 04:51

    # show chassis cluster reth-count
    reth-count 22;

    ---

    Both nodes have been updated, but the problem has not been resolved

    # run show version brief
    node0:
    --------------------------------------------------------------------------
    Model: srx1600
    Family: junos-es
    Junos: 24.2R2.18

    ...

    node1:
    --------------------------------------------------------------------------
    Model: srx1600
    Family: junos-es
    Junos: 24.2R2.18

    ---

    For clarity, I am attaching icmp-answers from the outside:

    root@maya:~ # ping 19.36.52.52
    PING 19.36.52.52 (19.36.52.52): 56 data bytes
    64 bytes from 19.36.52.52: icmp_seq=19 ttl=62 time=1.694 ms
    64 bytes from 19.36.52.52: icmp_seq=29 ttl=62 time=2.117 ms
    64 bytes from 19.36.52.52: icmp_seq=34 ttl=62 time=1.636 ms
    64 bytes from 19.36.52.52: icmp_seq=50 ttl=62 time=1.628 ms
    64 bytes from 19.36.52.52: icmp_seq=51 ttl=62 time=1.651 ms
    64 bytes from 19.36.52.52: icmp_seq=52 ttl=62 time=1.552 ms
    64 bytes from 19.36.52.52: icmp_seq=54 ttl=62 time=1.717 ms
    64 bytes from 19.36.52.52: icmp_seq=55 ttl=62 time=1.629 ms
    64 bytes from 19.36.52.52: icmp_seq=56 ttl=62 time=1.454 ms
    64 bytes from 19.36.52.52: icmp_seq=57 ttl=62 time=1.719 ms
    64 bytes from 19.36.52.52: icmp_seq=58 ttl=62 time=1.532 ms
    64 bytes from 19.36.52.52: icmp_seq=66 ttl=62 time=1.604 ms
    64 bytes from 19.36.52.52: icmp_seq=101 ttl=62 time=1.590 ms
    64 bytes from 19.36.52.52: icmp_seq=103 ttl=62 time=1.640 ms
    64 bytes from 19.36.52.52: icmp_seq=104 ttl=62 time=1.581 ms
    64 bytes from 19.36.52.52: icmp_seq=105 ttl=62 time=1.686 ms
    64 bytes from 19.36.52.52: icmp_seq=107 ttl=62 time=1.460 ms
    64 bytes from 19.36.52.52: icmp_seq=110 ttl=62 time=1.986 ms
    64 bytes from 19.36.52.52: icmp_seq=111 ttl=62 time=1.574 ms
    64 bytes from 19.36.52.52: icmp_seq=114 ttl=62 time=1.518 ms
    ^C
    --- 19.36.52.52 ping statistics ---
    118 packets transmitted, 20 packets received, 83.1% packet loss
    round-trip min/avg/max/stddev = 1.454/1.648/2.117/0.154 ms

    ---

    With similar settings on other reth-interfaces, the loss is 0%.



    ------------------------------
    Denis Rasskazov
    ------------------------------

    Original Message


  • 4.  RE: SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-15-2025 10:20

    because it's not apart of the provided config, i'm asking, do you have a security policy for from-zone sale to-zone untrust?  




  • 5.  RE: SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-15-2025 19:14

    What is the configuration of the switch ports attached?

    A common error is to treat RETH (redundant ethernet) as if they were an aggregated ethernet pair.  When this happens packet loss occurs because the switch is expecting to use either of the two interfaces at any time.  But redundant ethernet has only one of the pair active at any given time.



    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
    http://puluka.com/home
    ------------------------------



  • 6.  RE: SRX1600. Strange behavior of the ge- interface in the cluster

    Posted 06-16-2025 04:59

    The Switching Fabric is not involved.



    ------------------------------
    Denis Rasskazov
    ------------------------------

    Original Message