pbr
3 TopicsF5 and Cisco ACI Essentials - Design guide for a Single Pod APIC cluster
Deployment considerations It is usually an easy decision to have BIG-IP as part of your ACI deployment as BIG-IP is a mature feature rich ADC solution. Where time is spent is nailing down the design and the deployment options for the BIG-IP in the environment. Below we will discuss a few of the most commonly asked questions: SNAT or no SNAT There are various options you can use to insert the BIG-IP into the ACI environment. One way is to use the BIG-IP as a gateway for servers or as a routing next hop for routing instances. Another option is to use Source Network Address Translation (SNAT) on the BIG-IP, however with enabling SNAT the visibility into the real source IP address is lost. If preserving the source IP is a requirement then ACI's Policy-Based Redirect (PBR) can be used to make sure the return traffic goes back to the BIG-IP. BIG-IP redundancy F5 BIG-IP can be deployed in different high-availability modes. The two common BIG-IP deployment modes: active-active and active-standby. Various design considerations, such as endpoint movement during fail-overs, MAC masquerade, source MAC-based forwarding, Link Layer Discovery Protocol (LLDP), and IP aging should also be taken into account for each of the deployment modes. Multi-tenancy Multi-tenancy is supported by both Cisco ACI and F5 BIG-IP in different ways. There are a few ways that multi-tenancy constructs on ACI can be mapped to multi-tenancy on BIG-IP. The constructs revolve around tenants, virtual routing and forwarding (VRF), route domains, and partitions. Multi-tenancy can also be based on the BIG-IP form factor (appliance, virtual edition and/or virtual clustered multiprocessor (vCMP)). Tighter integration Once a design option is selected there are questions around what more can be done from an operational or automation perspective now that we have a BIG-IP and ACI deployment? The F5 ACI ServiceCenter is an application developed on the Cisco ACI App Center platform built for exactly that purpose. It is an integration point between the F5 BIG-IP and Cisco ACI. The application provides an APIC administrator a unified way to manage both L2-L3 and L4-L7 infrastructure. Once day-0 activities are performed and BIG-IP is deployed within the ACI fabric using any of the design options selected for your environment, then the F5 ACI ServiceCenter can be used to handle day-1 and day-2 operations. The day-1 and day-2 operations provided by the application are well suited for both new/greenfield and existing/brownfield deployments of BIG-IP and ACI deployments. The integration is loosely coupled, which allows the F5 ACI ServiceCenter to be installed or uninstalled with no disruption to traffic flow, as well as no effect on the F5 BIG-IP and Cisco ACI configuration. Check here to find out more. All of the above topics and more are discussed in detail here in the single pod white paper.1.7KViews3likes0CommentsWildcard in SNAT
I want configure an snat translation to change the source IP ltm tries to connect *.f5.com(say). Can I use wildcard in snat? If not, is there any other solution to this? Current Scenerio: LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> FW1 [Takes 0.0.0.0/0] --> Internet Issue: FW1 does't support *, can't allow access only to *.f5.com. Proposed: LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> SNAT(1.1.1.1->2.2.2.2) -To- *.f5.com [Takes 0.0.0.0/0] -->FW1[Allow all https for source 2.2.2.2] [Takes 0.0.0.0/0] --> Internet OR LTM(src-1.1.1.1) -To- *.f5.com [Takes 0.0.0.0/0] --> SNAT(1.1.1.1->2.2.2.2) -To- *.f5.com [Takes 0.0.0.0/0] -->FW1[PBR to FW2 that supports * for source 2.2.2.2] [Takes 0.0.0.0/0] --> Internet OR413Views0likes3CommentsSource based routing (Policy based routing) on BIG-IP F5
I've multiple DHCP pools for different VPN profiles (Different subnets) on BIG-IP APM, and I want to route internet traffic for the users through VPN (Force all traffic through VPN), I have multiple self IPs through which I have connectivity to different sub-interfaces on perimeter firewall and core firewall. My current routing table is as below Internal subnet > Core Firewall Default Route> Perimeter Firewall (DMZ Interface) My default route on the BIG-IP F5 is the sub-interface of perimeter firewall which is in DMZ to entertain the requests from internet coming to the DMZ. By default, all the internet traffic coming from VPN users take default route and hit's DMZ interface on the perimeter, but I want to forward all VPN users traffic to another sub-interface of the perimeter firewall (using another self IP), how I can achieve this? I want to do routing as below Source = VPN_SUBNET > NEXT_HOP (DEFAULT ROUTE) = PERIMETER LAN_INTERFACE1.2KViews0likes1Comment