Load Balance Cisco ISE servers

Lot's of great information in this thread! To try and sum it up here is how I got this to work:

NO NAT - so put the PSN servers on their own subnet and set their default route to the BIG-IP. Create two forwarding VS for inbound to the PSN traffic and outbound--make sure to use "enabled on vlan's" to tie these to the appropriate interface.

Create two standard VS, one for 1812 and one for 1813. Use protocol UDP, use a UDP protocol profile, use a RADIUS profile -- these are important to enable the iRules use of the RADIUS command. It may be possible to get away with default profiles for UDP and RADIUS--I haven't tested that. i.e:

ltm virtual /RADIUS-AUTH {
    destination /10.10.10.113:1812
    ip-protocol udp
    mask 255.255.255.255
    persist {
        /RADIUS_STICKY {
            default yes
        }
    }
    pool /pool-1812-radius
    profiles {
        /udp-for-ise-profile { }
        /radius-profile { }
    }
    rules {
        /RADIUS-PERSIST-IRULE
    }
    vlans-disabled
}

Apply a universal persistence profile:

ltm persistence universal /RADIUS_STICKY {
    app-service none
    defaults-from /Common/universal
    match-across-pools disabled
    match-across-services enabled
    match-across-virtuals disabled
    mirror disabled
    override-connection-limit disabled
    rule none
    timeout 600

And the iRule:

ltm rule /RADIUS-PERSIST-IRULE {
 ISE persistence iRules based on MAC Address with fall-back to WLC IP address as persistence identifier
set debug 1
set persist_ttl 14400
when CLIENT_DATA {
    set persist_ttl 14400
     If MAC address is present - use it as persistent identifier
     See Radius AV Pair documentation on https://devcentral.f5.com/wiki/irules.RADIUS__avp.ashx
    if {[RADIUS::avp 31] ne "" }{
        set mac [RADIUS::avp 31]
         Persist config
        persist uie $mac $persist_ttl
        set target [persist lookup uie [RADIUS::avp 31]]
        log local0.alert "Username=[RADIUS::avp 1] MAC=$mac TARGET=$target"

    } else {
        set persist_ttl 14400
        if { $debug > 0 } {log local0.alert "No MAC Address found - Using NAS IP as persistent identifier" }
        set nas_ip [RADIUS::avp 4]
        persist uie $nas_ip $persist_ttl
        set target [persist lookup uie $nas_ip]
        log local0.alert "Username=[RADIUS::avp 1] NAS IP=$nas_ip TARGET=$target"
    }
}
}    

Pool:

ltm pool /pool-1812-radius {
    allow-nat no
    allow-snat no
    members {
        /10.10.194.133:1812 {
            address 10.10.194.133
            session user-disabled
        }
        /10.10.194.134:1812 {
            address 10.10.194.134
        }
        /10.10.194.135:1812 {
            address 10.10.194.135
        }
    }
    monitor /radius-auth-1812
}

Monitors are straightforward--just use the RADIUS ones on the box.

ltm profile radius /radius-child-31 { app-service none clients none defaults-from /Common/radiusLB persist-avp 31 } ltm profile udp /radius-child-31-profile { app-service none defaults-from /Common/udp }

Depending on your configuration you may also need an additional std VS to send DHCP :67 traffic to the PSN servers. I've also seen where an forwarding VS from the PSN network out: UDP/0.0.0.0:1700 was needed--and to that VS assign a SNAT Pool that uses the same IP as the RADIUS server VS IP.

I'm not sure if I have made this less muddy but hopefully there is enough config examples above to get you rolling in the right direction.

Cheers!

Few things we learn with our ISE installation :

• Disable datagram LB : see : http://support.f5.com/kb/en-us/solutions/public/3000/600/sol3605.html

   

• Use one single VS listening on all ports. Having 2 separate VS with UIE persist across services/vs/pool does not persist 100% of the time.

   

• F5 drop UDP packets. If you see failure code "12953 - Received EAP packet from the middle of conversation ..." most likely this is caused by F5 dropping packet. We see this issue happen with 6000+ users. Testing environment with 1000 users does not inherit this issue. 11.5 is the worst offender while 11.3 is somewhat better. We have up to 25% failure rates with 11.5 and only 5% with 11.3

• If you must support MSCHAP (challenge-response) authentication things get messy.
• Apparently Datagram LB assumes a single request/response, so additional responses may get dropped or grabbed by a wildcard forwarding virtual server and incorrectly routed (with RADIUS server as source IP).
• If you disable Datagram LB then persistence is based on the UDP "connection" and not each individual RADIUS packet.

• It appears that you can get around this issue by setting the UDP profile's idle timeout to "Immediate" and then setting up one or more outbound forwarding virtual servers configured to SNAT using the RADIUS virtual server's IP.

   

• Does anyone have experience with this?

   

http://www.cisco.com/c/dam/en/us/td/docs/security/ise/how_to/HowTo-95-Cisco_and_F5_Deployment_Guide-ISE_Load_Balancing_Using_BIG-IP.pdf

http://www.cisco.com/c/dam/en/us/td/docs/security/ise/how_to/HowTo-95-Cisco_and_F5_Deployment_Guide-ISE_Load_Balancing_Using_BIG-IP.pdf

I have the cisco ISE deployment guide and followed it to a tee. But what I am seeing is only half the devices connecting will log the radius AVP 31 which is the calling station ID or MAC address, and this causes the other half to persist with the IP address whish is not working. Anyone ever see this behavior before? I am on 11.5.4

Thanks,