Multiple 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?Change DNS GTM Self IP
Greetings, My approach is to take the DNS I will not change out of the sync group. Then, change the LTM gateway pool, and Link, listener, self address on the DNS, then change LTM VS addresses. After that join the other DNS to the sync group running gtm_add <dns_on_syn_group>. Let me know if there is a KB for this change, I didn't find it or if any of you have done that. Edouard
Do 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?
SSL 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?GTM 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, Dave
External 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...
vIP 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?How 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.ARP & Failover hassle: Self-IP in the vIP range or MAC Masquerading?
Hello, We recently had some issues regarding a failover where a part of the vips weren't ARP'd right. (These worked fine before) F5 Support mentioned having a self-ip in the vIP range or using MAC Masquerading on the traffic group would solve our problems. Now there are a few things I do not get; if a self-ip in the vIP range is required, how are we accessing our listeners right now? How is the bigip broadcasting the vIPs without a self-ip in the vIP range? Why would MAC masquerading work better? Our bigips are connected to L3 switches, if that may help. Thanks!
