RFC 5549?

[Andrey V. Elsukov]

On 18.12.2018 00:43, Donald Sharp wrote:
> I took the code, compiled at and got FRR working with the v6 nexthop.
> https://github.com/FRRouting/frr/pull/3502.  Route installation from
> FRR appears to be working for me now:
> 
> Janelle# show ip route
> Codes: K - kernel route, C - connected, S - static, R - RIP,
>        O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
>        T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
>        F - PBR, f - OpenFabric,
>        > - selected route, * - FIB route
> 
> K>* 0.0.0.0/0 [0/0] via 10.50.12.1, em0, 00:13:13
> B>* 10.50.11.0/24 [20/0] via fe80::a00:27ff:fe28:3b50, em1, 00:13:09
> C>* 10.50.12.0/24 is directly connected, em0, 00:13:13
> B>* 10.232.0.16/32 [20/0] via fe80::a00:27ff:fe28:3b50, em1, 00:13:09
> B>* 192.168.209.0/24 [20/0] via fe80::a00:27ff:fe28:3b50, em1, 00:13:09
> B>* 192.168.230.0/24 [20/0] via fe80::a00:27ff:fe28:3b50, em1, 00:13:09
> B>* 192.168.231.0/24 [20/0] via fe80::a00:27ff:fe28:3b50, em1, 00:13:09
> Janelle# exit
> sharpd at Janelle ~/frr> netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags     Netif Expire
> default            10.50.12.1         UGS         em0
> 10.50.11.0/24      fe80::a00:27ff:fe28:3b50%em1 UG1      em1
> 10.50.12.0/24      link#1             U           em0
> 10.50.12.121       link#1             UHS         lo0
> 10.232.0.16        fe80::a00:27ff:fe28:3b50%em1 UGH1      em1
> 127.0.0.1          link#4             UH          lo0
> 192.168.209.0/24   fe80::a00:27ff:fe28:3b50%em1 UG1      em1
> 192.168.230.0/24   fe80::a00:27ff:fe28:3b50%em1 UG1      em1
> 192.168.231.0/24   fe80::a00:27ff:fe28:3b50%em1 UG1      em1
> 
> On the other hand, ping doesn't appear to be working( but I think you
> probably knew that):
> sharpd at Janelle ~/frr> sudo tcpdump -i em1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 11:41:59.559457 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 27, length 64
> 11:42:00.626966 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 28, length 64
> 11:42:01.659515 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 29, length 64
> 11:42:02.732074 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 30, length 64
> 11:42:03.759432 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 31, length 64
> 11:42:04.833242 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 32, length 64
> 11:42:05.859559 IP 0.0.0.0 > 192.168.230.1: ICMP echo request, id
> 2119, seq 33, length 64
> ^C
> 7 packets captured
> 21 packets received by filter
> 0 packets dropped by kernel
> 
> This is pretty awesome progress though

Hi,

I think this happens when you try to ping from the router via interface
without IPv4 address. In this case rip_output() fills only destination
address in hope that ip_output() will fill source address. But since
there are no IPv4 addresses on the interface, in the line
https://svnweb.freebsd.org/base/head/sys/netinet/ip_output.c?annotate=339219#l452

it uses some zero filled word as source address.
Probably, we can just drop the packet, when gw->af_family == AF_INET6
and ip_src == INADDR_ANY. Also we can do some sort of source address
selection, but this variant needs more code :)

I think generic forwarding should work, when you use router only as
transit point.

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20181218/98887302/attachment.sig>