asymmetric routing
2 TopicsBigIP ESXi 14.1.0.6 version routing problem. Probably asymmetric routing ?
Happy new year everybody, Got a problem with BigIP ESXi 14.1.0.6. So far all I did was download the .ova file ,install it via Vmware player ,the free edition, and run 'config' command to set the management ip. As you can see in the images below its on bridge connection using my on board nic. My problem is that although I can ping from the bigip vm to both my host windows,and other vms using same connective in same network, machine and to the outside world, tried google.com for example, while obviously being able to ping back from my host machine I seem unable to connect to the web interface in order to activate product and configure it further. The error I get on browser is 'connection refused'. Tried telnet with putty and still cant connect. Both vm and host are on same subnet /24. Host machine ip is 192.168.1.139,bigip management ip is 192.168.1.177 and default getaway is 192.168.1.254. Tried setting a static arp route following this https://support.f5.com/csp/article/K16221, so my command was create net arp myarp ip-address 192.168.1.139 mac-adress '',which mac adress I found from running ipconfig/all on my windows host. Error was that 'neighbor entry 192.168.1.139 cant be resolved'. Last thing I did was restarting Vm after I closed down skype because I recall it causing issues with port 80 and apache when both were running so I thought maybe it interferes with Vms as well. But it didn't fix the problem. Is there something else I can do ? Am I wrong about asymmetric routing ? My end goal is to build a lab with the bigip and a another ubuntu server vm I already built with some docker images inside and test it. Thanks in advance for your help699Views0likes12CommentsAsymmetric routing after software-update not working anymore
We have performed a software update from 13.1.1.5 to 13.1.3.2 on a BIG-IP 4000S. After this we noticed that access to a server is not working anymore (it was working with the old version). Following some details about the configuration: The server, FW and the BIG-IP have IPs in the same VLAN. The FW is normally the main Layer3-hop in this VLAN. As the application on the server can not work with SNAT, this server has its default gateway pointing to the BIG-IP. The BIG-IP itself has its default gateway pointing to the FW. We have a forwarding VS configured with a fastL4 profile and both "Loose Initiation" and "Loose Close" options enabled. This configuration on the BIG-IP is part of a Route-Domain and separated via a partition (this partition is assigned to the Route-Domain). Now we have for example the following use-case: We want to start a RDP-session to this server from a hopping station. The "request"-traffic is going via the FW and from there directly to the server. But due to the default gateway pointing to the BIG-IP, the "response"-traffic is going via the BIG-IP. When starting a tcpdump we see two entries: INs1/tmm2 : 3389 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1 OUT s1/tmm2 : 31463 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1 When checking the MAC-addresses of the outgoing paket, this is the one from the FW. Please correct me if I'm wrong, but this looks for me that the paket reaches the BIG-IP and will be routed/forwarded correctly. How can we further analyze this? Any idea if this really belongs to the software-update? The FW-team mentioned that they have not performed any changes in that time, but it's not 100% proven 😉 Do you need any further information/details? Thank you for your help! Ciao Stefan 🙂Solved550Views1like3Comments