self ip
17 TopicsHow does MAC Masquerading work exactly?
Hi, I am trying to grasp how exactly MAC Masquerading works, and how it behaves differently during a failover. Situation without MAC Masquerading Every floating Self IP & virtual IP will have a gARP anouncement with the new MAC address issued on the device becoming active, making the switches now route to the new device. Issues can arise if network equipment cannot handle the amount of gARPs. Situation with MAC Masquerading Every floating Self IP in the cluster has the same MAC address. Not sure about the vIPs. During failover, the switches need not learn a new MAC address but just learn it's now available on a new switch. (in our case, L3 switches with OSPF) So how do vIPs fit in the mac masquerade story? And how do switches learn the vIPs/floating Self IPs are now on this port without gARPs? The DevCentral articles do not discuss this in great detail.3.1KViews0likes1CommentDo I need a self-ip in the same subnet as my virtual servers, or a VLAN ID?
Hi all. So my external self IP is in the 10.251.12.0/24 subnet and my virtual servers are in the 10.251.10.0/24 subnet. However, I can't ping any of my vIPs from the F5 itself or outside of that network. I noticed that if I put the vIP in the 10.251.12.0/24 subnet I can ping it from the F5 as well as outside of the network. It's like my F5 doesn't want to advertise my virtual servers. Am I missing configuration here? I do not have a VLAN defined for the virtual servers, nor do I have a self-IP in that range. Should I?1.3KViews0likes6CommentsNo response after added virtual server IP address as floating self-IP address
Hi, I have an F5 HA pair that serves several virtual servers. VS1: ip1 VS2: ip2 Now, the IP address of VS1 (ip1) was already defined as a floating self-IP, but I found out that the IP address of VS2 was not defined as a self-IP. So I added ip2 as a floating self-IP. From that moment on, no traffic was accepted on either ip1 or ip2. Moreover, when I add a floating self-IP (let's say ip3), the virtual servers stop accepting traffic. Any idea what can be causing this? Is it necessary to define the IP address of a virtual servers as a floating self-IP? Are there benefits of doing that? On other units I manage, I always first add the floating self-IP and then I add the virtual server on that IP address. I'm running version "BIG-IP 11.6.0 Build 0.0.401 Final" Thanks.Solved1.1KViews0likes12CommentsMultiple Route Domains in same partition
Hi all, So my doubt is, if there is anything wrong in creating more than one route domain in partition common? I want to create Route Domain 3 ( 0 is the default and already exists), in order to separate the routing table of a VIP/Network, that will be created for Internet traffic only. For what i know i will have to create: 1 - Vlan 2 - Route Domain 3 - Assign created Vlan to Route Domain 4 - Self IP like 1.1.1.248%3 and assign created Vlan to it. 5 - VIP like 1.1.1.1%3 6 - Nodes - 2.2.2.2%3 7 - Static Route - 1.1.1.0%3 Gateway 1.1.1.254%3 Is this correct or do we got to have anything more in attention? Is it better to create a partition for it, os its fine to just have the 2 route domains in same partition?899Views0likes3CommentsWhat is the impact of adding a floating IP to an active HA LTM pair?
Hello. I have recently started a new position and while going through the environment I've found a couple pairs of LTMs in HA config with floating IPs for some networks and not for others. I generally follow the best practice of creating a floating IP for any network on any pair of devices. To my knowledge we are not using the LTMs as the default gateway on any of the servers that are load balanced by the F5s. In this case I would think there would be no impact to adding a floating IP and then synching each pair, but since they are production devices I'd like to get some confirmation from the community. Please let me know if you need some more details. Thanks.600Views0likes9CommentsGTM Listener IP - Best Practice
I'm looking for some clarification on this topic. I've seen it mentioned in various places (ex. http://support.f5.com/kb/en-us/solutions/public/5000/400/sol5427.html) that the best practice is to use one of the BIP-IPs self-IPs as the destination listener. "F5 recommends to always use a self IP address when defining a listener object for local name resolution. A listener object that is not defined as a self IP address cannot direct name resolution requests to BIND." I'm using v11.6 and have my listener assigned an IP on the same subnet as my external self-IP, but it's a different IP. Upon defining my listener in this manner, it automatically created an associated Virtual Server with the defined IP and everything works fine. What is the disadvantage in deploying a listener that doesn't use the same IP as one of the self-IPs on the system? I'm trying to understand why this is a best practice. I'd imagine an anycast deployment would also be deployed not using a self-IP of the system, but rather the listener would be assigned a /32 and then advertised by a routing protocol. Similar to using a loopback interface's address for deploying anycast on a router. Thanks, Dave599Views0likes2CommentsExternal interface selfIP without elastic IP on AWS - no internet access for management port
We have multi-NIC f5 deployed in AWS - external, internal and management interface. Only External interface can have elastic IP associated with it. Internal and management subnets are internal only. We access the management port through VPN (so no elastic IP required on the port). On the external interface, we have a selfIP and VIP (virtual server) - the only VIP has associated ElasticIP so our virtual server is accessible from the internet. PROBLEM: When I connect to the management server and try to do any operation that requires internet access it fails (for example ping, check for updates). I spend some time trying to get this solved and at the moment the only way... SOLUTION: ... is to associate elasticIP with the selfIP on the external interface. This way I need to "waste" one elasticIP address on the external selfIP just so I can do periodic maintenance tasks like checking for updates/hotfixes and if using let's encrypt to refresh certificates every 2-3 months. I know that elasticIPs are only like $0.005 per hour, but this still feels like an overkill. F5 DOCUMENTATION ERROR - official f5 documentation for 12.1.0 multi-NIC deployment in AWS does not mention assigning elasticIP. Documentation suggests assigning elasticIP to the management port which solves this problem I guess but is insecure (to be fair they say that this is an insecure solution). This is fair enough for a "quick start", but can you please update documentation, to let people know that if you do not assign elasticIP to external selfIP and your management port is internal only you will not have internet access for your management tasks and that you need to assign EIP to external selfIP. QUESTION: for more experience f5 gurus... Does anyone know if there is a way of "sending" management traffic through one of the VIPs which needs EIP to make the resource available to the world (instead of assigning EIP to selfIP)? Or is there any other way of not wasting elasticIPs just for maintenance? Long post, I hope it's not too confusing and will help at least one person...461Views0likes2CommentsvIP gARP without Self IP in vIP range
Hello, Currently we are running version 11.5.1 with no Self IPs defined in the vIP VLANs/subnets. Traffic is flowing through the vIPs without any problems. During a failover, some vIPs are not available. While reading , the article mentions as if there are no gARPs possible when we do not have any Self IPs defined in the vIP range and not have MAC Masquerading. How is it possble that the failover (mostly) works?428Views0likes2CommentsSetting up Self IPs, VLANs and interfaces properly
I am with a division of a much larger organization. The larger organization has a layer 3 firewall that all the divisions sit behind. We have some public-facing web servers that we are going to be standing up in a virtualized environment in our division and I've been tasked with standing up the BIG-IP F5 in front of our network to protect these sites. I have experience with Cisco and Palo Alto firewalls, but am getting confused on the way the F5 is set up and works. I imagine some of that confusion is that we are using the Virtual Edition of the BIG-IP rather than a physical appliance like I'm accustomed to. So I was wondering if someone could help me understand how to work with the self IPs, interfaces and VLANs to get traffic flowing. As I mentioned, the organization's layer 3 firewall is the border security appliance. It will take the public IP of our web server that a client is trying to reach and NAT that to an IP that is in the IP range of our external VLAN on the F5. Then the traffic will hit the F5 where a virtual server "listens" for traffic going to that IP range and sends that traffic to the web server which sits on an internal VLAN in a different IP range. I'm just trying to understand in a simple, step by step fashion, how I would walk through that process of creating the proper self IPs, interfaces and VLANs. What do I set up first, then next and so on? Let's say that the IP range of my external VLAN is 10.10.10.0/24 I have two internal VLANs. One has an IP range of 10.0.0.0/28 and the other is 10.0.1.0/28 Any help would be greatly appreciated and feel free to ask questions if I've left anything out.406Views0likes4CommentsSSL VIP accessible from browser but not from CLI
Hi A VIP with an SSL profile works fine when client connects through a browser. But connection is refused (TCP reset) when client connects from CLI to VIP. A TCPdump of the CLI attempts shows show the connection getting "h2.http/1.1". All port access is 443 and firewall access is in place TCP dump of initial SYN shows (VIP name is testvip.txt.com) ============================================================== ............y.<".=5....n.}.xL6 .V ._..T.?... ./.0.+.,.......... ...../.5... ...k3t...........testvip.txt.com.......... . ................. ................................h2.http/1.1.... Does this rule out the VIP? I read somewhere I needed to allow access between the Self IP and the NODES?347Views0likes5Comments