L2L3 serialization and broadcast ip-flow-rule problem

book

Article ID: 168136

calendar_today

Updated On:

Products

XOS

Issue/Introduction

This Article explains that under certain conditions it can happen that the very first packet of the flow is lost with L2L3 serialization.First packet lost when L2L3 serialization is used together with broadcast ip-flow-rule in the L3 vap-group.

Cause

If below architecture is used, the first packet of the flow (connection initiation, not a reply) from A to any destination (B or chassis itself) is lost on NPM due to cct field in the u-header is not correct for the very first packet of the flow, which is used for flow classification. There is no FSC being generated and sent to L3 vap group members due to broadcast ip-flow-rule. Unlike FSC code path in flowd codes, cct field is not updated with egress circuit id. The first packet shows up with a circuit id of the bridge circuit, intoutside_ips(1034) instead of dhcp circuit id, 1074. After the flow is provisioned, subsequent packets of the same flow will be forwarded directly to the VAPs with correct circuit id.

A (client) - X_series (ISS IPS - CP) - B (server)

XOS configuration example to verify the issue with icmp traffic, but this is specially critical with VPN Office Mode using firewall as DHCP relay and DHCP pool configured under external DHCP server.

vap-group iss xslinux_v3
max-load-count 1
ap-list ap6
load-balance-vap-list 1 2 3 4 5 6 7 8 9 10
ip-flow-rule lb
action load-balance
activate

vap-group r65 xslinux_v3
vap-count 2
max-load-count 2
ap-list ap1 ap2 ap3 ap4 ap5 ap6 ap7 ap8 ap9 ap10
load-balance-vap-list 1 2
ip-forwarding
ip-flow-rule lb_r65
action load-balance
activate
ip-flow-rule icmp
action broadcast
priority 30
protocol 1 1
activate

circuit intoutside_ips circuit-id 1034
internal
device-name owip
vap-group iss
promiscuous-mode active
vap-group r65

circuit client circuit-id 1074
device-name client
vap-group r65
ip-forwarding
default-egress-vlan-tag 26 hide-vlan-header
ip 172.17.26.182/24 172.17.26.255

circuit server circuit-id 1079
device-name server
vap-group r65
ip-forwarding
default-egress-vlan-tag 25 hide-vlan-header
ip 172.17.25.181/24 172.17.25.255

circuit bridge2_outside circuit-id 1032
device-name brout
vap-group iss
promiscuous-mode active

circuit intoutside_ips circuit-id 1034
internal
device-name owip
vap-group iss
promiscuous-mode active
vap-group r65

circuit inside_non_ips circuit-id 1027
device-name inip
vap-group r65

group-interface inip
interface-type gigabitethernet
mode multi-link circuit inside_non_ips
interface 1/3
interface 2/3
logical server ingress-vlan-tag 25 25
circuit server

group-interface Outside_IPS
interface-type gigabitethernet
mode transparent circuit bridge2_outside
interface-internal circuit intoutside_ips
interface 1/7
device-name outside
logical server ingress-vlan-tag 26 26
circuit client

Note: this issue will happen even without MLT configuration

Resolution

This problem has been corrected in XOS 9.5.2, XOS 9.0.3 and XOS 8.5.5:

ID 27319: In a serialized configuration involving a Layer 2 and a Layer 3 application, if the ip-flow-rule is
configured as broadcast, the first packet is no longer lost.

Workaround

Don't use ip-flow-rule broadcast or increase ip-flow-rule timeout to decrease flow expiration rate and the need to setup a new flow.

ip-flow-rule icmp
action broadcast
timeout 1-hour
priority 30
protocol 1 1
activate