Forum Discussion

EAX_25745's avatar
EAX_25745
Icon for Nimbostratus rankNimbostratus
Mar 27, 2013

F5 and Cisco ASR SLA

Hi,

 

I have a scenerio where we have two F5s (Active / Standby) mesh connected to Cisco ASR 9000 routers with /31 subnets for the mesh connecitivty.

 

How can we implement SLA on the Cisco ASR to detect which F5 is active and change the routing accordingly?

 

We used ICMP but that is not working because when failover occurs the Active unit that went into Standby still responds to ICMP requests.

 

Any idea how i can do this with a VS or some clever iRules or something?

 

Anyone with experience connecting F5 in this way and how it was done to automatically detect wich F5 is active and change the routing accordingly?

 

config
design

9 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Mar 27, 2013
    I'm not sure quite what you mean by 'mesh' but I'd suggest you expand your subnet a bit and use a floating IP on the F5s and point your routes to it. This removes the need for IPSLA entirely and simplifies things quite a bit.
  • EAX_25745's avatar
    EAX_25745
    Icon for Nimbostratus rankNimbostratus
    Mar 27, 2013

    By mesh i mean that both F5s are connected to both ASRs in a mesh. i.e. each F5 have a connection to each one of the two ASRs.

     

    Currently we have 4 x /31 subnet that directly connects the F5s to the ASRs and then another /29 subnet that we use for the floating IP. The problem is that we are having trouble with the routing to the floating IP subnet as we can't route that subnet to the floating IP which is in the same subnet? Hope this makes sense. So lets say we have a 1.1.1.1/29 subnet in which the floating resides, on the ASR we want to route all traffic destined for 1.1.1.1/29 to F5s but can't route that subnet to an IP in the same subnet.

     

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Mar 27, 2013
    Why not use a single subnet for your mesh which the floating IP is part of? Especially if you use MAC Masquerade the failover will be seemless and again, there will be no need for IPSLA (but you will need HSRP). Then use the 1.1.1.1/29 just for your Virtual Servers (assuming that's its primary purpose)?

     

     

    Without a common network between the four devices (as you've found) you are making life very difficult for yourself.

     

     

    I wonder how the return traffic routing works at present too, if an ASR fails?
  • emptysky_137885's avatar
    emptysky_137885
    Icon for Nimbostratus rankNimbostratus
    Nov 28, 2013
    Hi EAX, Have your problem been solved? Seem currently we are facing the same issue as you, wanna some advice from u. Thanks
  • aj1's avatar
    aj1
    Icon for Nimbostratus rankNimbostratus
    Oct 30, 2014

    Hi EAX,

     

    Have you found a way to do this. I have the same topology - an active/standby viprion pair directly connected (full mesh) to two upstream routers (Juniper MXs) via BGP (both viprions are in the same AS), and its not working right. Basically a link failure results into the routers pointing to the standby unit as the next-hop.

     

    I am not using any floating-IPs (like its recommended internally) on the external VLANs. I would like to keep it that way and instead use some PBR (or IP SLA or BGP attributes or iRules) so that the upstream routers can detect the active and the standby unit and change the next-hop accordingly in the event of a failover. The zebos implementation for BGP4 does not seem to have IP SLA, so thats out of question, I guess.

     

    Is there a way I can have active/standby viprion pair connected to two upstream routers using /30 links, to point to the right next-hop address when the active unit goes down. And all of this w/o using floating-IPs.

     

    Any help appreciated.

     

  • EAX_25745's avatar
    EAX_25745
    Icon for Nimbostratus rankNimbostratus
    Oct 31, 2014

    Hi,

     

    We currently use OSPF with the 4 x /30 links with an active/standby configuration connecting to two ASR9006 routers.

     

    When using OSPF the F5 devices now change the cost of the routes depending on which unit is active. So when failover occurs it will immediately change the cost of the OSPF routes for the standby unit to be the highest and the active units routes to the lowest value.

     

    This now happens automatically but i recall somehow that in the past i had to change config or add an irule to get this to work.

     

    • aj1's avatar
      aj1
      Icon for Nimbostratus rankNimbostratus
      May 06, 2015
      Hi EAX, apologize for bothering you again. Just wondering if you use floating self-ips on the external vlans, since active/standy ospf works with static self-ips (p2p mesh between two routers and the two LTMs). Thanks.
  • aj1's avatar
    aj1
    Icon for Nimbostratus rankNimbostratus
    Oct 31, 2014

    Thank you so much for the reply EAX. I am on v11.4.1 on the F5 devices. The documentation does point to OSPF behaving the way you just described. Can you please elaborate on the iRule, was it applied to an wildcard ip-forward virtual server.

     

    Would this still work with BGP to OSPF redistribution? Or can you suggest a way this could be achieved using only BGP or some combination of BGP and irules.

     

    Thank you.

     

  • aj1's avatar
    aj1
    Icon for Nimbostratus rankNimbostratus
    Nov 11, 2014

    Hi EAX. I have configured OSPF between F5s and the Junipers. And configured ip forwarding virtuals. Active/Standby work just fine. I am now trying to reach a host configured in the load balancer vlan. Pings work fine but the traceroutes are a bit icky. In the traceroute o/p, the load balancer hop is constantly flapping between the two interfaces of the active unit, and at times there is a loop between the interfaces of the active unit. It finally does reach the destination, but curious as to what is causing this behavior. Did you encounter this behavior when your HA pair was setup with the ASRs? Thanks.