Forum Discussion

Shiva_69966's avatar
Shiva_69966
Icon for Nimbostratus rankNimbostratus
Jul 15, 2015

Upgrading from V10.2.4 to V11.5.1 issues

Hi All ,

 

Recently we upgraded our F5s from 10.2.4 to 11.5.1 everything was fine except with connectivity profile in APMs. And we fixed by removing the connectivity profile as it was not in use and the configs load was successful .

 

But after the upgrade we had intermittent issues accessing vip. Though all the config looks good , the packet capture shows something interesting requesting coming from upstream device to F5.

 

In Intermittent connection failures . in tcp handshake if either syn , syn ack , ack comes with different vlan vs ack . Where as ack has wrong vland id

 

after establish connection and f5 sending application data to client responds ack to app data twice with two different vlan ids vs the 1st ack .

 

im not sure why the client packet has different vlan id . And F5 interfaces are configured as access port . below tcpdump shows 204.ip (internt client ) This bheavior is not just for single ip but the same across other vips on the box ! Did any one had the same issues with packet processing after upgarde .Please let me know for any inputs . Thanks ,

 

 

APM
application delivery
availability
deployment
LTM
security
TMOS

1 Reply

Sort By
  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Jul 15, 2015

    I will start off by saying that you should consider an upgrade to 11.5.3HF1. The 11.5 release follows the new model described here:

     

    (11.5 is the Long-Term Stability Release for 11.x).

     

    I don't have any particular reason to believe that updating to 11.5.3HF1 will change the behavior; I simply wanted to note this current best-practice.

     

    Having said that, the basic unit for networking configuration on a BIG-IP is a VLAN object. Interfaces, trunks and tunnels must be associated with a VLAN, and listeners are also associated with VLANs. Any traffic arriving (or leaving) a BIG-IP network interface must be matched to a VLAN for it to be accepted. If the traffic has no VLAN header, it will be associated to the "untagged" VLAN for the interface, if one is defined (if one is not defined, the frame is dropped). This is very similar to Cisco's notion of a "native" VLAN definition (though Cisco accepts frames tagged for the native VLAN and BIG-IP does not).

     

    When untagged frames are copied to the forwarding plane, the appropriate VLAN tag is inserted. As a consequence, all traffic you see in your tcpdump (assuming you dumped on 0.0) will have an associated VLAN id.

     

    I'm afraid I don't completely follow the rest of the information you provided. Perhaps you can restate what you are seeing? In the meantime: generally speaking, a "connection" (tcp connection or udp flow) through a BIG-IP is matched by VLAN, src-ip, src-port, dst-ip and dst-port. Any traffic received on a listener that is not the start of a new connection (a SYN-only segment for tcp) will be rejected by the BIG-IP unless it matches an existing connection table entry. That means, among other things, that tcp segments for an existing flow must all arrive on the same VLAN, and if the BIG-IP initiated the connection (as happens on the server-side of the full proxy), all traffic for that flow must arrive on whatever VLAN the BIG-IP used when initiating the flow. This solution article contains more information: