[Oisf-users] Suricata inline networking HSRP/VRRP across the bridge

Chris Boley ilgtech75 at gmail.com
Sat Mar 4 14:20:53 UTC 2017

I've had to work with this at length.
My scenario includes mostly Cisco Routers (in router on a stick topology)
trunked to cisco switches.

I have to set my router interfaces as active and my L3 switch as standby in
my HSRP configs so that if the router fails, the switch will elect as
master and continue to route internally. When introducing the inline linux
bridge to the mix it very much complicates things. HSRP occasionally breaks
the routing as often times it doesn't do the active/standby election
process properly and the switch will become active instead of the router.
Usually when I have to reboot the linux server for whatever reason.

It's become so cumbersome I've made the decision to move to span ports and
change modes from IPS to IDS. It's not what I wanted from my Suricata usage
as it almost defeats the purpose of what I wanted it for in the first place.

I've found that I'm able to configure the bridge properly and set proper
sysctl flags for scanning the dot1q traffic inline. That part is fine.

But I often run into big trouble / pitfalls because the hsrp "handshake"
that happens between the two devices on either side of the bridge seems
unreliable. I'm running into what I like to call an engineering minefield.
I find it's very dependent on the two devices setting on either side of the
linux bridge which facilitates the inline scanning.
i.e.. Cisco IOS or IOS-XE versions. Device models etc..

I have properties all over the US and run into different makes/models of
switches and routers.

Has anyone else worked with looking at traffic inline as I have and had to
support HSRP or VRRP through a Linux bridge?

My user case is probably quite unique. I was hoping to find someone else
who has had experience in this area.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170304/633779c2/attachment.html>

More information about the Oisf-users mailing list