Bidirectional Forwarding Detection (BFD) Protocol Cheat Sheet
Definition This is a protocol initially described inRFC5880and IPv4/IPv6 specifics inRFC5881. I would say this is an aggressive 'hello-like' protocol with shorter timers but very lightweight on the wire and requiring very little processing as it is designed to be implemented in forwarding plane (although RFC does not forbid it to be implemented in control plane). It also contains a feature called Echo that further leaves cpu processing cycle to roughly ZERO which literally just 'loops' BFD control packets sent from peer back to them without even 'touching' (processing) it. BFD helps routing protocol detects peers failure at sub-second level and BIG-IP supports it on all its routing protocols. On BIG-IP it is control-plane independent as TMM that takes care of BFD sending/receivingunicastprobes (yes,no multicast!) and BIG-IP's Advanced Routing Module® being responsible only for its configuration (of course!) and to receive state information from TMM that is displayed in show commands. BIG-IP's control plane daemon communicates with TMM isoamd. This daemon starts when BFD is enabled in the route domain like any other routing protocol. BFD Handshake Explained 218: BFD was configured on Cisco Router but not on BIG-IP so neighbour signals BIG-IP sessionstate is Down and no flags 219: I had just enabled BFD on BIG-IP, session state is now Init and only Control Plane Independent flag set¹ 220: Poll flag is set to validate initial bidirectional connectivity (expecting Final flag set in response) 221: BIG-IP sets Final flag and handshake is complete² ¹Control Plane Independentflag is set because BFD is not actively performed by BIG-IP's control plane. BIG-IP's BFD control plane daemon (oamd) just signals TMM what BFD sessions are required and TMM takes care of sending/receiving of all BFD control traffic and informs session state back to Advanced Routing Module's daemon. ²Packets 222-223are just to show that after handshake is finished all flags are cleared unless there is another event that triggers them. Packet 218 is how Cisco Router sees BIG-IP when BFD is not enabled. Control Plane Independent flag on BIG-IP remains though for the reasons already explained above. Protocol fields Diagnostic codes 0 (No Diagnostic): Typically seen when BFD session is UP and there are no errors. 1 (Control Detection Time Expired):BFD Detect Timer expired and session was marked down. 2 (Echo Function Failed):BFD Echo packet loop verification failed, session is marked down and this is the diagnostic code number. 3 (Neighbor Signaled Session Down):If either neighbour advertised state or our local state is down you will see this diagnostic code 4 (Forwarding Planet Reset):When forwarding-plane (TMM) is reset and peer should not rely on BFD so session is marked down. 5 (Path Down):Ondemand mode external application can signal BFD that path is down so we can set session down using this code 6 Concatenated Path Down): 7 (Administratively Down):Session is marked down by an administrator 8 (Reverse Concatenated Path Down): 9-31:Reserved for future use BFD verification 'show' commands ³Type IP address to see specific session Modes Asynchronous(default): hello-like mode where BIG-IP periodically sends (and receives) BFD control packets and if control detection timer expires, session is marked as down.It uses UDP port3784. Demand: BFD handshake is completed but no periodic BFD control packets are exchanged as this mode assumes system has its own way of verifying connectivity with peer and may trigger BFD verification on demand, i.e. when it needs to use it according to its implementation.BIG-IP currently does not support this mode. Asynchronous + Echo Function: When enabled, TMM literally loops BFDecho-specificcontrol packetson UDP port 3785sent from peers back to them without processing it as it wasn't enough that this protocol is already lightweight. In this mode, a less aggressive timer (> 1 second) should be used for regularBFD control packets over port 3784 and more aggressive timer is used by echo function.BIG-IP currently does not support this mode. Header Fields Protocol Version:BFD version used. Latest one is v1 (RFC5880) Diagnostic Code: BFD error code for diagnostics purpose. Session State: How transmitting system sees the session state which can be AdminDown, Down, Init or Up. Message Flags:Additional session configuration or functionality (e.g. flag that says authentication is enabled) Detect Time Multiplier:Informs remote peer BFD session is supposed to be marked down ifDesired Min TX Intervalmultiplied by this value is reached Message Length(bytes):Length of BFD Control packet My Discriminator:For each BFD session each peer will use a unique discriminator to differentiate multiple session. Your Discriminator:When BIG-IP receives BFD control message back from its peer we add peer's My Discriminator to Your Discriminator in our header. Desired Min TX Interval(microseconds):Fastest we can send BFD control packets to remote peer (no less than configured value here) Required Min RX Interval(microseconds):Fastest we can receive BFD control packets from remote peer (no less than configured value here) Required Min Echo Interval(microseconds):Fastest we can loop BFD echo packets back to remote system (0 means Echo function is disabled) Session State AdminDown:Administratively forced down by command Down: Either control detection time expired in an already established BFD session or it never came up.If probing time (min_tx) is set to 100ms for example, and multiplier is 3 then no response after 300ms makes system go down. Init:Signals a desire to bring session up in the beginning of BFD handshake. Up:Indicates session is Up Message Flags Poll:Pool flag is just a 'ping' that requires peer box to respond with Final flag. In BFD handshake as well as in Demand mode pool message is a request to validate bidirectional connectivity. Final:Sent in response to packet with Poll bit set Control Plane Independent:Set if BFD can continue to function if control plane is disrupted¹ Authentication Present:Only set if authentication is being used Demand:If set, it is implied that periodic BFD control packets are no longer sent and another mechanism (on demand) is used instead. Multipoint:Reserved for future use of point-to-multipoint extension. Should be 0 on both sides. ¹ This is the case for BIG-IP as BFD is implemented in forwarding plane (TMM) BFD Configuration Configure desired transmit and receive intervals as well as multiplier on BIG-IP. And Cisco Router: You will typically configure the above regardless of routing protocol used. BFD BGP Configuration And Cisco Router: BFD OSPFv2/v3 Configuration BFD ISIS Configuration BFD RIPv1/v2 Configuration BFD Static Configuration All interfaces no matter what: Specific interface only: Tie BFD configuration to static route:
Self IP in different subnet and VS and pool members are in same subnet then Self ip
Hi Team, I'm working on one of the installation where the requirement is that VS - e.g 10.10.10.X and pool members are in same subnet 10.10.10.X whereas F5 Self IPs will be in different subnet e.g 10.10.20.X and would like to understand how the routing will work for traffic hitting to VS (We need switch/router to point the route to F5 self IP e.g 10.10.20.1 for the subnet 10.10.10.X ) and from VS to pool members and return traffic from pool members to client. Can someone help?Understanding the BGP Peering details your CCNA didn't teach you
1 Quick Facts BGP usesTCP port 179 and is path vector protocol, rather than distance vector or link-state Keep-alive is 60s by default and Hold time is 180s Only hold time isnegotiatedin Open message Lowest hold time is used Routes are only installed in the routing table and advertised to peer is deemed valid (*) and best (>) For BGP to advertise a route using network command such route has to be in the routing table first BGP transport and route advertisement (known as NLRI in BGP) are independent Transport can use either IPv4 or IPv6 IPv6 NLRI can be advertised over an IPv4 BGP connection and vice-versa 2. The BGP peering for IPv4 BIG-IP establishes TCP connection on port 179 with peer and each one exchangeOPEN Message: Here's BIG-IP'sOPEN Message: Here's Cisco'sOPEN Message: Markeris always the same value and is just to signal the beginning of BGP message so don't worry about it. Lengthis just the total length of this BGP message Typecould be UPDATE (2), KEEPALIVE (4) but in this case it is an OPEN Message (1). Versionis always the same as this is BGPv4. My ASis the same because this is iBGP but if it was eBGP My AS on both sides would differ. Hold Timepicked value is the lowest one and this is negotiated. Since lowest value on BIG-IP's side is 90 seconds then both peers will send KEEPALIVE messages at 30 seconds interval. BGP Identifieris the bgp router-id that we typed in. Optional Parameters Lengthis the total length combined of all BGP extensions Optional Parametersare BGP extensions. At this point, if something goes wrong with peering, we should see BGP sending a NOTIFICATION message to terminate peering process: The above one was issued because I shutdown the neighbour relationship manually but other types of error would reveal a different message. In a running packet capture, we should see KEEPALIVE messages and corresponding TCP ACKs at agreed interval based on Hold Time: Other than that, UPDATE messages are also common and I will show them right now. 3. The UPDATE message for IPv4 It's kind of built-in. For IPv4 we will see Type 2 message (UPDATE) and the NLRI (routes). The 2 prefixes below share the same attributes and this is why they're grouped together: 4. The BGP peering for IPv6 It's the same thing as IPv4 but an additional capability is negotiated calledMultiprotocol extensions capabilitywithIPv6asAFIvalue: In case you never heard of AFI/SAFI here's what they mean: AFI (Address Family Indicator):This is the kind of route BGP is capable of handling, normally IPv4 or IPv6 but can also be VPNv4 for MP-BGP (out of scope here). SAFI (Subsequent Address Family Indicator): This is whether route is UNICAST or MULTICAST, normally UNICAST. If you ever configured BGP and typed in address-family commands then you've touched AFI/SAFI already. 5. BONUS! Carrying IPv4 prefixes over an IPv6 BGP connection (WHAT?) Yes, it's possible but next-hop of an IPv4 route is going to be IPv4 so make sure there is connectivity or create the relevant route-map. Notice that we're transporting BGP packets over IPv6 but routes advertised are IPv4 prefixes: You can also carry IPv6 prefixes over IPv4 if we do the other way round.
Source 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_INTERFACEHealth Monitor being sourced from Management interface causing async routing
I have a health monitor that is being sourced from the management interface - this was discovered by accident when i was doing a TCPDUMP on the vlan interface the traffic should have been sourced from. example vlan 10 interface on f5 10.0.0.1 destination ip address of device being monitored = 10.0.0.6 when i did a tcpdump on the vlan to troubleshoot a separate problem i didnt see the traffic - i could see other health monitor traffic using the vlan for devices on the subnet and i know the routing and connectivity is working fine. Wondering what reason there would be for the health monitor not to use the vlan associated with the subne t and use the management ip address to source the health traffic. FYI the health monitor is working and responding as expected but would just like the traffic to use the correct path - via the connected vlan instead of sending around the world and through various firewalls to reach its destination (lucky the firewalls are permitting the traffic. Thanks
inline configuration
Hi, I have configuration: NET => FW => F5 => SRV I have VS1 which forwards traffic to SRV (no SNAT used, not possible to do XFF so source address of client is seen). F5 is def gw for SRV. On F5 there is also forwarding IP VS 0/0 and def route to FW. FW also have static route for SRV subnet poiting to F5. Questions: 1. Client from net goes to VS1 (SNAT off) is redirected to SRV (source address is seen, destination nat is in place to pass traffic to SRV). I assume that return traffic from SRV is hitting VS 0/0 (am I right?) VS 0/0 have snat off. And I also assume that source address of SRV is changed to VS1 IP (am I also right?). If not, should I do some SNAT on VS 0/0? Second example. When server is originating connection to NET it hits VS 0/0, is that right? No SNAT is configured so source address of server is seen outside? The route on FW pass traffic back to SRV via F5. If point 1 is true (so when return traffic is automatically SNATed back to VS1 IP) what determines that traffic is SNATed or not? Is it previously created session/entry for DNAT when traffic originating from Net hits VS1?Dire (Load Balancing) Straits: I Want My Client IP
load balancing fu for developers to avoid losing what is vital business data I want my client IP Now read the manuals that's the way you do it Give the IP to the SLB That ain't workin' that’s the way to do it Set the gateway on the server to your SLB (many apologies to Dire Straits) My brother called me last week with a load balancing emergency. See, for most retailers the “big day” of the year is the Friday after Thanksgiving. In Wisconsin, particularly for retailers that focus on water sports, the “big day” of the year is Memorial Day because it’s the first long weekend of the summer. My brother was up late trying to help one of those retailers prepare for the weekend and the inevitable spike in traffic to the websites of people looking for boats and water-skis and other water-related sports “things”. They’d just installed a pair of load balancers and though they worked just fine they had a huge problem on their hands: the application wasn’t getting the client IP but instead was logging the IP address of the load balancers. This is a common problem that crops up the first time an application is horizontally scaled out using a Load balancer. The business (sales and marketing) analysts need the IP address of the client in order to properly slice and dice data collected. The application must log the correct IP address or the data is virtually useless to the business. There are a couple of solutions to this problem; which one you choose will depend on the human resources you have available and whether or not you can change your network architecture. The latter would be particularly challenging for applications deployed in a cloud computing environment that are taking advantage of a load balancing solution deployed as a virtual network appliance or “softADC” along with the applications, because you only have control over the configuration of your virtual images and the virtual network appliance-hosted load balancer. THE PROBLEM The problem is that often times load balancers in small-medium sized datacenters and cloud computing environments are deployed in a flat network architecture, with the load balancer essentially in a one-armed (or side-armed) configuration. This means the load balancer needs only one interface, and there’s no complex network routing necessary because the load balancer and the servers are on the same network. It’s also often used as a transparent option for a new load balancing implementation when applications are already live and in use and disrupting service is not an option. But herein lies the source of the problem: because the load balancer and the servers are on the same network the load balancer must pretend to be the client in order to force the responses back through the load balancer (This is also true of larger and more complex configurations in which the load balancer acts as a full proxy). What happens generally is the load balancer replaces the client IP address in the network layer with its own IP address to force responses to come back to it, then rewrites the Ethernet header on the way back out. When the web server logs the transaction, the client IP address is the IP address of the load balancer, and that’s what gets written into the logs. This is also the case in larger deployments when the load balancer is a full proxy; the requests appear to come from the load balancer in order to apply the appropriate optimization and security policies on the responses, e.g. content scrubbing and TCP multiplexing. The load balancer/ADC cannot provide any kind of TCP connection optimization (such as is used to increase VM density) and application acceleration capabilities in such a mode because it never sees the responses. The result is a DSR (Direct Server Return) mode of operation, meaning that while requests traverse the load balancer, the responses don’t. This is the situation my brother found himself in (on his birthday, no less, what a dedicated guy) when he called me. It was Friday afternoon of Memorial Day weekend and the site absolutely had to be up and logging client IP addresses accurately or the client – a retailer of water-related goods - was going to be very, very, very angry. THE SOLUTION(s) You might be thinking the obvious solution to this problem is to turn on the spoofing option on the load balancer. It is, but it isn’t. Or at least it isn’t without a configuration change to the servers. See, the real problem in these scenarios is that the servers are still configured with a default gateway other than the load balancer. Enabling spoofing, i.e. the ability of the load balancer to pretend to be the client IP address, in this situation would have resulted in the web server’s responses still being routed around the load balancer because the servers, having no static route to the client IP, would automatically send them to the default gateway (the router). The solution is to change the network configuration of the web servers to use a default gateway that is the load balancer’s IP address, thus insuring that responses are routed back through the load balancer regardless of the client IP. Once that’s accomplished then you can enable SNAT and/or spoofing or “preserve client IP” or whatever the vendor refers to the functionality as and the web server logs will show the actual IP address of the client instead of the load balancer. Another option is to enable the load balancer to insert the “X-Forwarded-For” custom HTTP header. Most modern load balancers offer this as a checkbox configuration feature. Every HTTP request is modified by the load balancer to include the custom HTTP header with a value that is the client’s true IP address. It is then the application’s responsibility to extract that value instead of the default for logging and per-client personalization/authorization. The extent of the modification of the application depends on how reliant on the client IP address is. If it’s only for logging then a web/app server configuration change is likely the only change necessary. If the application makes use of that IP to apply policies or make application-specific decisions, then modification to the application itself will be necessary. THIS is WHY DEVOPS is NECESSARY As more developers take to the cloud as a deployment option for applications this very basic – but very frustrating – scenario is likely to occur more often than not as developers become more familiar with load balancers and deploy them in an IaaS environment. IaaS providers offering “auto-scaling” or “load balancing” services as a capability will have taken this problem into consideration when they architected their underlying infrastructure and thus the customer is relieved of responsibility for the nitty-gritty details. Customers deploying a separate virtualized load balancing solution – to take advantage of more robust load balancing algorithms and application delivery features like network-side scripting – will need to be aware of the impact of network configuration on the application’s ability to “see” the client IP address. Even if the customer is not concerned about the ability to extract the real client IP address it is still important to understand the impact to the return data path as well as the loss of functionality (optimization, security, acceleration) from routing around the load balancing solution on the application response. This particular knowledge falls into the responsibility demesne of what folks like James Urquhart and Damon Edwards and Shlomo Swidler (among many others) calls “devops”; developers whose skill set and knowledge expands into operations in order to successfully take advantage of cloud computing. Developers must be involved with and understand the implications of what has before been primarily an operational concern because it impacts their application and potentially impacts the ability of their applications to function properly. Development and operations must collaborate on just such concerns because it impacts the business and its ability to succeed in its functions, such as understanding the demographics of its customer base by applying GeoLocation technologies to client IP addresses. Without the real client IP address such demographic data mining fails and the business cannot make the adjustments necessary to its products/services. Business, operations, and development must collaborate to understand the requirements and then implement them in the most operationally efficient manner possible. Devops promises to enable that collaboration by tearing down the wall that has long existed between developers and operations.
F5 ltm inter-vlan not working
hi all , I have two servers vlan and FW as GW for those vlan and F5 LTM with snat mode , we have issue with FW and we need to move GW from fw to F5 , when we config GW in severs to F5 self IP its work fine in same vlan but the two vlans can't communicate with each , from F5 we can reach all servers we have configure wild VS IP and L2 but still not working , what is the issue ?
