active/active HA with layer3 sub-interfaces

Reply
Highlighted
L0 Member

active/active HA with layer3 sub-interfaces

Hi all,

 

Is active/active mode supported with Layer3 sub-interfaces? I'm trying this in a lab with 2 VM-50's, and whilst the cluster is formed, I seem to have intermittent packet loss; not sure if this is just a limitation of the VM series (in particular, VM-50) or the fact that they are not true layer-3 interfaces? The customer has a pair of 5220's for a greenfield deployment, but we are planning on using layer3 sub-interfaces.

 

Both firewalls obviously have the same interface config (VLAN ID, tag etc;) albeit 1 node has IP's configured for VLAN 800-805, whilst the second node has IP's configured for VLAN 806-810. VR is not sync'd between the firewalls and each firewall has individual BGP peerings to the upstream and downstream router.

ikunduraci_0-1586485565049.png

The vSwitch with HA3 interface has MTU 9000. Session owner and session setup is set for first-packet.

 

We require active/active due to asymmetric paths; the routers see ECMP paths through each firewall so depending on the hash, we can't guarantee return traffic through the same firewall node.


Accepted Solutions
Highlighted
L7 Applicator

Re: active/active HA with layer3 sub-interfaces

Yes this is supported

 

Have you found any indication why and where packet loss occurs? Not sure if a VM environment is the best place for AA

reaper - PANgurus.com
I drink and I know things

View solution in original post


All Replies
Highlighted
L7 Applicator

Re: active/active HA with layer3 sub-interfaces

Yes this is supported

 

Have you found any indication why and where packet loss occurs? Not sure if a VM environment is the best place for AA

reaper - PANgurus.com
I drink and I know things

View solution in original post

Highlighted
L0 Member

Re: active/active HA with layer3 sub-interfaces

Thanks Reaper - I managed to fix my issue, it was related to the fact that the interface names were different; I got caught up on the interface name having a .VLANID (e.g. eth1/1.800), I can probably blame Cisco for that

 

After matching the interface names (and modifying VLAN tags accordingly), all works well.

 

Cheers

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!