Hoi folks,
Taking the following two VPP instances, directly connected, I
configure the following:
vpp0-3# set interface ip address loop0 192.168.10.3/32
vpp0-3# set interface state loop0 up
vpp0-3# set interface unnumbered GigabitEthernet10/0/0 use loop0
vpp0-3# set interface state GigabitEthernet10/0/0 up
vpp0-3# ip route add 192.168.10.2/32 via 192.168.10.2
GigabitEthernet10/0/0
vpp0-2# set interface ip address loop0 192.168.10.2/32
vpp0-2# set interface state loop0 up
vpp0-2# set interface unnumbered GigabitEthernet10/0/1 use loop0
vpp0-2# set interface state GigabitEthernet10/0/1 up
vpp0-2# ip route add 192.168.10.3/32 via 192.168.10.3
GigabitEthernet10/0/1
If on vpp0-2 I try to ping 192.168.0.3, ARP requests are sent
out, arrive at vpp0-3, but they're dropped:
vpp0-3# show err
Count Node
Reason Severity
5
arp-reply IP4 source address not local to sub
error
1 arp-reply IP4 source address
matches local in error
I traced this down to src/vnet/arp/arp.c:522 where I think this
error should not be returned if the interface is arp_unnumbered().
Using this small patch: https://gerrit.fd.io/r/c/vpp/+/40482 and
removing the test that asserts the previous behavior, allows the
ARP request->reply to succeed, and communication to occur:
vpp0-2# ping 192.168.10.3
116 bytes from 192.168.10.3: icmp_seq=2 ttl=64 time=3.5249 ms
116 bytes from 192.168.10.3: icmp_seq=3 ttl=64 time=3.5441 ms
116 bytes from 192.168.10.3: icmp_seq=4 ttl=64 time=2.3656 ms
116 bytes from 192.168.10.3: icmp_seq=5 ttl=64 time=2.3756 ms
Statistics: 5 sent, 4 received, 20% packet
loss
Now I don't know for sure if this doesn't cause other regressions
although I think the use case of unnumbered interfaces being able
to ARP for one another is valid (for one, OSPFv2 and Babel can run
in a mode where these point to point loopbacks are utilized).
Can anybody think of a reason why not to allow this topology (and
merge the change)? rfc826 doesn't forbid it, but it's kind of a
fun one to re-read :)
groet,
Pim
