can't access on prem dns when using F5LTM as a gateway
The title is the tl/dr. I have a server on an internal network that is set up to use our F5 as a gateway. I have all of the forwarding vip's set up and routed through snat pools. and if i set the server to use an external dns like google or opendns everything seems to work perfectly. however the server is being set up as an smtp server and needs to rely on our on prem dns for some mail destinations. side note, if forwarding vip's are set for snat automap, on prem dns works fine. i did watch traffic with tcpdump from the F5, on the internal network when using nslookup with both on prem and off prem dns servers, i could see traffic hit the outbound forwarding vip. however watching traffic on the external network, traffic appeared on the outbound forwarding vip's when using external dns servers. on prem seem to have died somewhere in the F5. can i fix this by just adding another outbound vip set to snat outmap to manage dns traffic? is that an appropriate fix?
Multiple Default Gateways
Hi, I have a question regarding default gateway configuration. Please refer to the following setup: We currently have an L4 HA device setup (R2600) in Active-Standby mode, and both units are in the same subnet. The default gateway is set to 192.168.1.1, which is a VRRP address on the L3 side. Since F5 devices synchronize route configurations across devices during config sync, any change to the routing table is applied to both units. Given this, is it possible to configure different default gateways per device in an F5 HA pair? Specifically, I would like to set each unit's default gateway to the real IP of a different L3 device: Default GW for L4 #1: 192.168.1.2 Default GW for L4 #2: 192.168.1.3 I'd like to hear the opinion of experts on whether this is possible and if there is a supported way to achieve this. Thank you.
Questions about F5 BIG-IP Multi-Datacenter Configuration
We have an infrastructure with two datacenters (DC1 and DC2), each equipped with an F5 BIG-IP using the LTM module for DNS traffic load balancing to resolvers, and the Routing module to inject BGP routes to the Internet Gateways (IGW) for redundancy. Here’s our current setup (based on the attached diagram): Each DC has a BIG-IP connected to resolvers via virtual interfaces (VPI1 and VPI2). Routing tables indicate VPI1->DC1 and VPI2->DC2. Each DC has its own IGW for Internet connectivity. Question 1: Handling BIG-IP Failures If the BIG-IP in one datacenter (e.g., DC1) fails, will the DNS traffic destined for its resolvers be automatically redirected to DC2 via BGP? How can BGP be configured to ensure this? Is it feasible and recommended to create a HA Group including the BIG-IPs from both datacenters for automatic failover? What are the limitations or best practices for such a setup across remote sites? Question 2: IGW Redundancy Currently, each datacenter has its own IGW. We’d like to implement redundancy between the IGWs of the two DCs. Can a protocol like HSRP or VRRP be used to share a virtual IP address between the IGWs of the two datacenters? If so, how can the geographical distance be managed? If not, what are the alternatives to ensure effective IGW redundancy in a multi-datacenter environment? Question 3: BGP Optimization and Latency We use BGP to redirect traffic to the available datacenter in case of resolver failures. How can BGP be configured to minimize latency during this redirection? Are there specific techniques or configurations recommended by F5 to optimize this? Question 4: Alternatives to the DNS Module for Redundancy We are considering a solution like the DNS module (GSLB) to intelligently manage DNS traffic redirection between datacenters in case of failures. However, this could increase costs. Are there alternatives to the DNS module that would achieve this goal (intelligent redirection and inter-datacenter redundancy) while leveraging the existing LTM and Routing modules? For example, advanced BGP configurations or other built-in features of these modules? Thank you in advance for your advice and feedback!self ip issue
Hi all, I have a problem, I created a self ip (10.10.10.250/24) on my F5 device to act as a gateway, When I ping this gateway, it says the address is unreachable,Devices pointing to this gateway are working, only the address of this gateway is not pingable. Is there any difference between setting a gateway on the F5 for a segment and setting a gateway on a switch?
Cluster Cross subnet
Hi, We currently have two independent clusters of F5 in separate subnets (sites) and require a method for synchronizing the configuration between them. There is a restriction on the deployment where they must be in separate subnets. The two sites run active-active. The obvious issue for this is that the gateways are separate and when we attempt to synchronize the configuration, the gateway address is clobbered, resulting in the routing breaking. We've tried a few things including: sync only; doesn't synchronize everything ip gw pool w/ sync fail-over; server split routing looking at the files manually and syncing them with external script Does anybody have advice on how they would handle this situation? Thanks.
F5 Friday on Tuesday: Getting You One Step Closer to a SDDC
#SDN #vmworld F5 Solutions Combine with VMware VXLAN to Support Software Defined Networking As efforts around SDN (Software-Defined Networking) continue to explode faster than the price of gas it has begun to diverge into several different focal points. Each area of focus tends to zero in on a narrowly defined set of problems that are in need of being solved. One of those focal points is on the layer 2 domain, where limitations both physical and logical constrain mobility of virtual machines across the network. In an increasingly network-agnostic approach to resource provisioning the limitations imposed by traditional logical networking standards can be a serious impediment to realizing the benefits of a truly elastic, cloud-computing based architectural model. To address the specific issues related to VLAN limitations and topological constraints on rapid provisioning processes, several competing standards have been proposed. The two most recognizable are certainly VXLAN (primarily driven by VMware) and NVGRE (primarily driven by Microsoft). Organizations are pursuing increasingly dynamic IT deployment models with software defined data centers (SDDC) becoming top of mind as the end-goal. As a strategic point of control in the data center, F5's approach is to seamlessly interoperate with a wide variety of network topologies including traditional VLANs and emerging SDN-related frameworks such as VXLAN and NVGRE. Such standards-efforts are focused on decoupling virtual machines from the underlying network as a way to enable more flexible, scalable and manageable pools of resources across the entire data center. The applications residing in those resource pools, however, must still be delivered. End-users and IT alike expect the same performance, reliability, and security for those applications regardless of where they might be deployed across the data center. That means ADN must be able to seamlessly transition between both traditional and emerging virtual networking technology so as to consistently deliver applications without compromising on performance or security. By supporting emerging standards in the ADC, customers can create isolated broadcast domains across the data center, enabling dynamic logical networks to span physical boundaries. F5 recently announced its support for NVGRE with our Microsoft Network Virtualization Gateway and today we're announcing that we will also support VXLAN by adding VXLAN virtual tunneling endpoint (vTEP) capabilities to BIG-IP. BIG-IP natively supports VXLAN today, but the addition of vTEP capabilities mean BIG-IP can act as a gateway, bridging VXLAN and non-VXLAN networks with equal alacrity. That means the ability to use either physical or virtual BIG-IP form factor to leverage all F5's ADN services such as security, acceleration, and optimization across both VXLAN and traditional networks. New support means organizations can: Simplify the Expansion of Virtual Networks With BIG-IP solutions as the bridge, organizations will be able to extend their existing networks from using VLAN to using VXLAN-based topologies. This enables a transitory approach to migration of resources and systems that avoids the disruption otherwise required by technical requirements of VXLAN. Apply Services across Heterogeneous Networks for Optimized Performance F5’s BIG-IP platform can serve as a networking gateway for all ADN services, making them available to application workloads irrespective of the underlying network topology. Networks comprised of multiple network technologies will find a unified gateway approach to providing services results in more predictable results for application delivery. Improve Application Mobility and Business Continuity Because VXLAN-based networks can provide functional isolation from one another, virtual machines do not need to change IP addresses while migrating between different data centers or clouds. Eliminating this requirement is a boon for enterprise-class IP-dependent applications that were previously restricted in mobility between environments. You can learn more about BIG-IP's support for VXLAN at #VMworld Europe this week at booth G100. Hybrid Architectures Do Not Require Private Cloud F5 Friday: Automating Operations with F5 and VMware F5 ... Wednesday: VMware Business Process Desktop and F5 BIG-IP The Full-Proxy Data Center Architecture F5 Friday: A Single Namespace to Rule Them All F5 Friday: Cookie Cutter vApps Realized F5 SOLUTIONS COMBINE WITH VXLAN TO SUPPORT SDNWILS: Controllers and Gateways
Why these two are very different but complementary technologies Have you ever wondered why one network product is called a “controller” while another seemingly similar in function solution is called a “gateway”? There’s actually a very good reason for the naming and despite appearing to act similarly they do fill different roles in an architecture and are often called upon to work together. GATEWAYS If you loosely defined a gateway as a “converter” or “translator” you’d be very close to nailing down a simple definition. Gateways act as mediators between disparate networks. In networking terms this is most commonly associated with routers (your “default gateway”) as it is designed as a transition point between two similar resources (networks) that generally utilize different protocols or in some way require a translation of messages/packets in order to traverse the network on the “other side” of the gateway. SOA (or XML) gateways, for example, provide a transition point between XML/Web Service endpoints and clients that can translate application messages from one format to another, either between different XML subsets or even between transport protocols: HTTP –> JMS, for example. Cloud gateways, and in particular cloud storage gateways of late, are products that mediate between enterprise users and applications (in some cases) and cloud-based storage services. These devices provide translation from an internal protocol such as SAMBA or CIFS to the specific cloud-based service “language” (API) required to access data stored in cloud-based locations. CONTROLLER A “controller” has traditionally referred to devices that control (hence the name) the transfer of data between a computer and its peripheral devices, and vice versa. The use of controller in the data center/architectural context means much the same, with the caveat that the “peripherals” involved are the endpoints, i.e. the client and the server(s). This is why some folks fly into a rage when hearing an “application delivery controller” referred to as a “load balancer”. An application delivery controller of course provides load balancing services but it also controls the transfer of data between the client and the servers (in myriad ways) as a means to provide other services as well, e.g. application and protocol security, acceleration, and optimization. Network-deployed controllers generally have more intelligence and flexibility built into them in terms of directing the flow of data. For example, a file virtualization controller governs the storage of files (data) across a variety of storage tiers based on rules specified by the business or operations staff. An application delivery controller can make a wealth of decisions regarding where to direct an HTTP request again based on rules specified by the business or operations staff. DIFFERENT but COMPLEMENTARY Often times an architecture will be comprised of both gateways and controllers, because the controllers often lack the translation capabilities of a gateway and the gateway lacks the intelligence and flexibility of the controller. Consider SOA gateways and application delivery controllers. It is often the case that a “farm” of gateways is front-ended (load balanced) by an application delivery controller. This is true of many types of “gateways” because if you think about, the process of transforming data and protocols is intense and these devices were not necessarily designed with scale and volume in mind, but rather functionality or, in the case of XML gateways with the scale and performance of a single type of process: parsing XML. They are not necessarily designed with network stack security or intelligent routing other than a specific, niche application. Similarly, the beginnings of a dual architecture comprising storage virtualization solutions and cloud storage gateways is beginning to emerge. This is because the storage virtualization solution (the controller) has the intelligence to make decisions regarding whether files/data should be stored locally or remotely, in a cloud-based storage environment. WILS: Write It Like Seth. Seth Godin always gets his point across with brevity and wit. WILS is an ATTEMPT TO BE concise about application delivery TOPICS AND just get straight to the point. NO DILLY DALLYING AROUND. Related blogs & articles: I CAN HAS DEFINISHUN of SoftADC and vADC? Intercloud: The Evolution of Global Application Delivery The Application Delivery Deus Ex Machina Dynamic Intelligent Application Delivery in a Distributed ... Optimize Prime: The Self-Optimizing Application Delivery Network Can the future of application delivery networks be found in neural ... ROI Justification(s) for Application Delivery Controllers WILS: Load Balancing and Ephemeral Port Exhaustion All WILS Entries on DevCentral WILS: The Concise Guide to *-Load Balancing WILS: What Does It Mean to Align IT with the BusinessApple iPad Pushing Us Closer to Internet Armageddon
Apple’s latest “i” hit over a million sales in the first 28 days it was available. Combine that with sales of other Internet-abled devices like the iPhone, Android, Blackberry, and other “smart” phones as well as the continued growth of Internet users in general (via cable and other broadband access technologies) and we are heading toward the impending cataclysm that is IPv4 address depletion. Sound like hyperbole? It shouldn’t. The depletion of IPv4 addresses is imminent, and growing closer every day, and it is that depletion that will cause a breakdown in the ability of consumers to access the myriad services offered via the Internet, many of which they have come to rely upon. The more consumers, the more devices, the more endpoints just exacerbates the slide toward what will be, if we aren’t careful, a falling out between IPv6-only consumers and IPv4-only producers and vice-versa that will cause a breakdown in communication that essentially can only be called “Internet Armageddon.”
