Test pfsync in a more realistic scenario with carp and route_to rules.
Build this topology and initiate a single ping session from client to
server:
┌──────┐
│client│
└───┬──┘
│
┌───┴───┐
│bridge0│
└┬─────┬┘
│ │
┌────────────────┴─┐ ┌─┴────────────────┐
│gw_route_to_master├─┤gw_route_to_backup│
└────────────────┬─┘ └─┬────────────────┘
│ │
┌┴─────┴┐
│bridge1│
└┬─────┬┘
│ │
┌────────────────┴─┐ ┌─┴────────────────┐
│gw_reply_to_master├─┤gw_reply_to_backup│
└────────────────┬─┘ └─┬────────────────┘
│ │
┌┴─────┴┐
│bridge2│
└───┬───┘
│
┌───┴──┐
│server│
└──────┘
gw* jails forward traffic through pf route-to rules, not fib lookups.
If backup_promotion arg is given (as in the pfsync_pbr test case), a
carp failover event occurs during the ping session on both gateways.
Verify that ping messages still go where we expect them to go.
MFC after: 2 weeks
Sponsored by: Orange Business Services