Design that utilizes a dedicated interface per persona. Is it valid?

[Walker]

The design of our new ISE cube has two SNS-3655 nodes that will act as the Admin/MnT/PSN on each. I am wondering if it is possible to run 3 dedicated connections to the appliance to separate the traffic based on the persona. When I look in the deployment settings, it doesn't seem you can set which interface you would like for that service, but my thinking is that you can set it up in the configuration to accomplish this. For example, for Admin nothing will change, MnT change the logging/remote logging settings to the second interface, and for the PSN we can just configure the switches to point to the third interface. Has anyone configured something similar to this, and if so, does it pose any problems? Unfortunately I do not have a lab to test this on, so your input is greatly appreciated!

[balaji.bandi]

 I am wondering if it is possible to run 3 dedicated connections to the appliance to separate the traffic based on the persona.

what is the use case here, instead why not make a Bundle interfaces to get high availability.

[Walker]

I agree that would make the most sense in a normal situation, but in this case we are mimicking a separate network that would use all the exact same IPs (these networks do not touch the internet). The network we are mimicking is larger and has 10 dedicated nodes, whereas as this one will be condensed to 5 nodes. This is why we had to assign 2 nodes with multiple personas. The idea is to make both cubes look almost identical. I wanted to experiment, but if it does not work I will most likely bundle the interfaces.

[balaji.bandi]

Do you high level diagram what you trying to achieve ? (may be as per the information, that is not possible i know...but wait for other mates comments and any one tried this ?)

[Arne Bier · Accepted solution]

I think I know what @Walker is trying to do here ... but I am also wondering what the point is. It's highly unlikely that a single 1GE or even 10GE interface on this UCS appliance will get a lot of traffic to warrant separating the interfaces. Bonding is the only thing I would consider to provide some resilience in the case where separate uplinks can be connected to two independent switches on the same VLAN.

ISE make use of iptables under the hood to protect/firewall the traffic that comes in on interfaces. Gig0/Bond0 is always used for management - and the other interfaces are typically used for guest portals.  

"All roads lead to Rome" - as the saying goes - what are we trying to achieve by separating the traffic out on individual interfaces? Avoiding the use of a router perhaps?  I think you're going to make life very tricky for yourself - I did that once and ended up with static routes on ISE nodes - it was unpleasant and you quickly and painfully learn how the product works when you deviate from the norm.  I don't understand why OVAs ship with 6 virtual NICs - I always delete all of them and add a single VMXNET3 - in 99.9% of the cases that works great.

[Marcelo Morais · Accepted solution]

Hi @Walker ,

"for academic purposes only",  : )  ... let's put Multiple Interfaces and Bond all together to try to answer your question:

1st:

. ISE Management is restricted to Gigabit Ethernet 0 (Eth0)

. All NICs can be configured with IP Addr.

. Bond configuration: Eth0, Eth2 and Eth4 must be assigned an IPv4 (or IPv6) address (Primary Interface) and Eth1, Eth3 and Eth5 must not be assigned an IP Addr (Backup Interface).

. RADIUS listens on all NICs

 2nd:

. configure Bond0 (Eth0+Eth1) for ISE Management.

ise/admin(config)# interface GigabitEthernet 0 
ise/admin(config-GigabitEthernet)# backup interface GigabitEthernet 1 

. configure the Guest Portals to point to Bond1 (Eth2+Eth3)

In Work Centers > Guest Access > Portal & Components > Guest Portal ... select Portal Settings > choose Bond1.

. configure the NADs to send the RADIUS packets to Bond2 (Eth4+Eth5)

Hope this helps !!!