ISE load-balancing with multiple interfaces.

[dazza_johnson]

Hey guys, need some feedback from 'the crew' on this..... I read the Cisco Live preso on load-balancing and just wanted to confirm the theory.

I have some PSNs behind an F5 load-balancer. I want to load-balance only the RADIUS traffic to the PSNs, with all management traffic not going through the F5 LTM. I thought I could do this using the configuration below. Basically, Gig0 is the management IP and it uses a default gateway of 10.1.1.254 (does not go through the F5 LTM). The Gig1 IP address is behind a load-balancer and return traffic is sent to gateway 192.168.100.100 which is the F5 LTM.

1. Is it true that traffic (in ISE v2) always responds on the interface it was received on? i.e. RADIUS traffic received on interface Gig1 would respond on Gig1 using the Gig1 gateway 192.168.100.100
2. Is the config below correct? The gateway for Gig0 is configure using 'ip default-gateway' and the gateway for Gig1 is configured using a static default route 'ip route 0.0.0.0 0.0.0.0....' command?
3. Is this a valid/recommended design?

ise-ccie/admin#

interface GigabitEthernet 0

  ip address 10.1.1.2 255.255.255.0

!       

interface GigabitEthernet 1

  ip address 192.168.100.2 255.255.255.0

!       

ip default-gateway 10.1.1.254

!       

ip route 0.0.0.0 0.0.0.0 gateway 192.168.100.100

!

ise-ccie/admin# sh ip route

Destination          Gateway              Iface              

-----------          -------              -----              

192.168.100.0/24     0.0.0.0              eth1               

10.1.1.0/24          0.0.0.0              eth0               

default              192.168.100.100      eth1               

default              10.1.1.254           eth0               

ise-ccie/admin#

[Craig Hyps · Accepted solution]

Yes, that is the behavior outlined in the reference version of BRKSEC-3699.

For outbound traffic initiated by PSN, the static route table will be referenced with the default-gateway serving as the true default in absence of more specific route.

Design is valid, but cannot vouch as recommended design since that is based on your specific needs.  If it meets your networking and security requirements, then that is the key.  However, in any design involving multiple interfaces and goal is traffic separation, there is likely to be some undo complexity for certain use cases.  For example, although RADIUS AAA may follow desired path with the above configuration, you may be challenged with restricting RADIUS CoA to eth1.  Since the target for CoA is the NAD, you would need a way to consolidate all NAD IP addresses for static routing (possibly via a loopback pool unique to all NADs and set as RADIUS source interface).

This requirement may be difficult to achieve.  Therefore, it may be a smaller target list to identify all IP addresses/networks which are required for management and make eth1 the default-gateway.

Craig

[bart.t]

Hi Craig,

Bit late, but stumbled upon your excellent explanation. However I couldn't find anything in the presentation you mentioned.

Finally figured out it should be BRKSEC-3432:

https://www.ciscolive.com/c/dam/r/ciscolive/apjc/docs/2019/pdf/BRKSEC-3432.pdf

Regards

[dazza_johnson]

@

Thanks chyps

These PSNs won't be issuing COAs for the purpose they are serving, its basic RADIUS ACCEPT/REJECT responses so all good on that side.

The fact that the ISE node responds on the interface it was received on is good enough for. The gateway for Gig0 is configured using 'ip default-gateway' and the gateway for Gig1 is configured using a static default route 'ip route 0.0.0.0 0.0.0.0....' command - is that correct?

[Craig Hyps]

You could go as far as adding a static 0.0.0.0 route out GE0 in event that you change the global default gateway.  This way, any changes to global default will result in symmetric traffic for externally-initiated requests.

Note that CoA tends to occur for many reasons, so don't discount its use.  Examples:

• All guest flows (Hotspot, CWA, ...)
• Posture
• BYOD
• MDM
• Profile changes
• ANC/EPS/RTC triggered by external server via API/pxGrid
• TC-NAC
• Easy Connect
• Endpoint Purge/Deletions
• Admin triggered via UI/API

/Craig

[wladimir.gruenemaier]

Hi Guys,

I had a similiar Design, but when i upgraded from 2.3 to 2.4 i wasn't able to access ISE Management.

Version 2.3:

!      

interface GigabitEthernet 0

  ip address 172.16.1.33 255.255.255.0

  ipv6 address autoconfig

  ipv6 enable

!      

interface GigabitEthernet 1

  ip address 172.17.0.33 255.255.255.0

  ipv6 address autoconfig

  ipv6 enable

!      

ip name-server 172.16.1.12 172.16.1.13

!      

ip default-gateway 172.16.1.1

!      

ip route 0.0.0.0 0.0.0.0 gateway 172.17.0.254

!      

I had to change Routing for Version 2.4 to:

!      

interface GigabitEthernet 0

  ip address 172.16.1.33 255.255.255.0

  ipv6 address autoconfig

  ipv6 enable

!      

interface GigabitEthernet 1

  ip address 172.17.0.33 255.255.255.0

  ipv6 address autoconfig

  ipv6 enable

!      

ip name-server 172.16.1.12 172.16.1.13

!      

ip default-gateway 172.17.0.254

!      

ip route 0.0.0.0 0.0.0.0 gateway 172.16.1.1

!      

can somebody explain what happened?

thx Wladimir

[Craig Hyps]

You changed your ip default gateway from GE0 to GE1 and management traffic must go in/out GE0.

[wladimir.gruenemaier]

Hi Craig,

i had to change it that way, otherwise i was not able to reach the management anymore. The strange thing is i had another Customer, where i upgraded from 2.3 to 2.4 and there i had no issues.

regards,

Wladimir