..

Tricky Network Issue in KCPS-Baremetal Testbed

This tricky network issue consists of:

  • Subnet overlapping
  • ARP request not ignored
  • Proxy ARP race condition
  • Asymmetric routing

arp_ignore

arp_ignore - INTEGER
	Define different modes for sending replies in response to
	received ARP requests that resolve local target IP addresses:
	0 - (default): reply for any local target IP address, configured
	on any interface
	1 - reply only if the target IP address is local address
	configured on the incoming interface
	2 - reply only if the target IP address is local address
	configured on the incoming interface and both with the
	sender's IP address are part from same subnet on this interface
	3 - do not reply for local addresses configured with scope host,
	only resolutions for global and link addresses are replied
	4-7 - reserved
	8 - do not reply for all local addresses

	The max value from conf/{all,interface}/arp_ignore is used
	when ARP request is received on the {interface}

Proxy ARP

Though not the best practice, you can design a network to use one subnet on multiple VLANs and use routers with proxy ARP enabled to forward traffic between hosts in those VLANs.

Proxy ARP Disabled at VLAN 5 Interface

Dst3650X#sh ip int vlan5 | i Proxy
  Proxy ARP is disabled
  Local Proxy ARP is disabled
[haas@haas ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.008cfaef7e3a       no              eth0
[haas@haas ~]$ arping -f -I br1 10.5.168.168
ARPING 10.5.168.168 from 10.5.131.1 br1
Unicast reply from 10.5.168.168 [00:25:90:CA:62:04]  0.785ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
[root@BAMPI ~]# tcpdump -i eth0.5 -en arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.5, link-type EN10MB (Ethernet), capture size 65535 bytes
12:01:12.900997 00:8c:fa:ef:7e:3a > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.5.168.168 (Broadcast) tell 10.5.131.1, length 46
12:01:12.901030 00:25:90:ca:62:04 > 00:8c:fa:ef:7e:3a, ethertype ARP (0x0806), length 42: Reply 10.5.168.168 is-at 00:25:90:ca:62:04, length 28
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Proxy ARP Enabled at VLAN 5 Interface

[root@BAMPI ~]# tcpdump -i eth0.5 -en arp | grep "0.254"
...
14:23:40.983008 80:71:1f:4c:be:01 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.5.1.20 tell 10.5.0.254, length 46
...
^C326 packets captured
326 packets received by filter
0 packets dropped by kernel

rp_filter

rp_filter - INTEGER
	0 - No source validation.
	1 - Strict mode as defined in RFC3704 Strict Reverse Path
	    Each incoming packet is tested against the FIB and if the interface
	    is not the best reverse path the packet check will fail.
	    By default failed packets are discarded.
	2 - Loose mode as defined in RFC3704 Loose Reverse Path
	    Each incoming packet's source address is also tested against the FIB
	    and if the source address is not reachable via any interface
	    the packet check will fail.

	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric routing
	or other complicated routing, then loose mode is recommended.

	The max value from conf/{all,interface}/rp_filter is used
	when doing source validation on the {interface}.

	Default value is 0. Note that some distributions enable it
	in startup scripts.

rp_filter stands for reverse path filtering. The reverse path filter will check if the source of a packet that was received on a certain interface is reachable through the same interface it was received. The purpose is to prevent spoofed packets, with a changed source address, not being processed/routed further. In a router it could also prevent routing packets that have a private IP address as source to the internet as they obviously will never find their way back.

References