Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Juniper CGNAT not releasing sessions on port-block "Zombie sessions"

    Posted 05-24-2023 05:44

    We are using Juniper MX480s with SPC3 cards for CGNAT.  Currently we have TCP and UDP ports with specific  inactivity-timeouts, all working well as attended. A port block would be allocated and when the active-block-timeout expires would allocate a new port block and new sessions would use the new block and the sessions that are still open would remain on the old port block. All good and well, but we require the session to eventually also be moved over to the new port block or closed, as the session would keep this port block open and never be released. F5 CGNAT routers call this zombie sessions .
    "A zombie port block, which is a port block that has reached the Block Lifetime limit but cannot be released due to active connections, is released when all active connections become inactive, or when the Zombie Timeout value is reached."

    Would Juniper have a way in which these "Zombie" sessions be released/closed or moved to new allocated port block. Similar to the F5  to timeout a "Zombie" session, or alternatively running  a specific command or script?

    Example of a user which have many "Zombie" sessions.

    Interface: mams-1/0/0

    Pool name: NAT-POOL-1

    Port-overloading-factor:     1     Port block size:  128

    Max port blocks per host:   12     Port block active timeout: 930

    Used/total port blocks per host: 7/12

    Host_IP                       External_IP                    Port_Block          Ports_Used/        Block_State/

                                                                   Range             Ports_Total        Left_Time(s)

    1.2.3.4                 5.6.7.8                   4224-4351              3/128*1        Inactive/-   

    1.2.34                 5.6.7.8                    4992-5119              2/128*1        Inactive/-   

    1.2.3.4                 5.6.7.8                   18816-18943            22/128*1          Active/495 

    1.2.3.4                  5.6.7.8                    31232-31359             1/128*1        Inactive/-   

    1.2.3.4                  5.6.7.8                   39424-39551             3/128*1        Inactive/-   

    1.2.3.4                  5.6.7.8                  48640-48767             1/128*1        Inactive/-   

    1.2.3.4               5.6.7.8                   59776-59903             1/128*1        Inactive/-

    Would appreciate your assistance.



    ------------------------------
    Christiaan
    ------------------------------


  • 2.  RE: Juniper CGNAT not releasing sessions on port-block "Zombie sessions"

    Posted 12-01-2025 19:18

    I'm currently investigating the same issue, and found your post.  Quite some time ago, JTAC had us change our PBA active-block-timeout to 0, but I still see many customer IPs sparsely using most or all of their possible port-blocks, much like the above.  This makes me worry that oversubscription of the CGNAT external pools may run into issues with there being plenty of unused ports per IP, but few, if any, available port-blocks.  Did you find a solution to this issue?



    ------------------------------
    JONATHAN LEWIS
    ------------------------------



  • 3.  RE: Juniper CGNAT not releasing sessions on port-block "Zombie sessions"

    Posted 13 days ago

    As a further update on this, after some more research, I've discovered the Juniper PBA algorithm "is stupid" in that when the active port block runs out of ports, rather than look at the other port blocks assigned to a subscriber IP, it simply allocates a new block (if it can).  The end result is if customers use more ports with any frequency than your block size, you will end up with many customers having their max port blocks number of blocks, all but the active being very sparsely utilized. i.e.

    Used/total port blocks per host: 9/9
    Host_IP                       External_IP                    Port_Block          Ports_Used/        Block_State/
                                                                   Range             Ports_Total        Left_Time(s)
    100.64.82.20                  xxx.yyy.8.0                     2048-2303              4/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                     9472-9727              4/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    11264-11519             3/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    14848-15103             2/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    16128-16383           127/256*1          Active/-
    100.64.82.20                  xxx.yyy.8.0                    19968-20223             4/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    30208-30463             2/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    46848-47103             2/256*1        Inactive/-
    100.64.82.20                  xxx.yyy.8.0                    48384-48639             3/256*1        Inactive/-

    This customer has used all their permitted port blocks...but they're not exactly "using" most of them.  They're essentially hogging port-blocks that should never have been allocated, keeping those resources from being usable by other customers.  There doesn't seem to be a knob to tune this behavior other than perhaps designing your PBA config in such a way that most customers never need to allocate a second port block...but that would also be inefficient due to having to size the port-block such that most customers never get near a single port block's capacity.  This effectively makes oversubscription of your CGNAT external pools "dangerous".



    ------------------------------
    JLewis
    ------------------------------