<HTML><BODY>Deploying VLAN per user with IP unnumbered schema using Linux as access server<br>we face with following problem:<br><br>  BIRD's kernel protocol does not learn routes with nexthop, that resolves trought<br>  another route (recursive routes).<br><br>This is reproducable for both IPv4 and IPv6.<br>----------------------------------------------------------<br><br>While for IPv4 this has minimal impact, as typically customer gets its /32 ip address and<br>entire LAN part of the customer connection uses addresses from RFC1918 and NAT.<br><br>For IPv6 this becomes more complicated:<br>  - there is no NAT in such view as with IPv4, (ok)<br>  - as with IPv4 customer gets one IPv6 address on its WAN interface (ok)<br>  - customer gets additional IPv6 block with 64 long prefix for its LAN interface (fail)<br><br>So for typical IPv6 deplyment with IP unnumbered schema we need:<br># ip -6 route add fd11::2/128 dev vlan10 proto static src fd11::1<br># ip -6 route add fd22::/64 dev vlan10 via fd11::2 proto static src fd11::1<br># birdc 'show route filter { if proto = kernel254 then accept; reject; }'<br>BIRD 1.3.9 ready.<br>fd11::2/128 dev qinq22.226 [kernel254 12:57] * (10)<br><br>Last route MUST be advertised using dynamic routing protocol (BGP in our case).<br><br>Example of such routes for both IPv4 and IPv6 is:<br>------------------------------------------------------------------<br><br># ip -4 route add 192.168.1.2/32 dev vlan10 proto static src 192.168.1.1<br># ip -4 route add 10.0.1.0/24 dev vlan10 via 192.168.1.1 proto static src 192.168.1.1<br># birdc 'show route filter { if net = 10.0.1.0/24 then accept; reject; }'<br>BIRD 1.3.9 ready.<br><br># ip -6 route add fd8e:579a:623c:826a::2/128 dev vlan10 proto static src fd8e:579a:623c:826a::1<br># ip -6 route add fd8e:579a:623c:ffff::/64 dev vlan10<br># birdc 'show route filter { if net = fd8e:579a:623c:ffff::/64 then accept; reject; }'<br><br>Kernel protocol configuration<br>---------------------------------------<br>protocol kernel kernel254 {<br>    persist no;<br>    scan time 120;<br>    learn yes;<br>    device routes no;<br>    kernel table ipt_main;<br>    import filter {<br>        # Import only 'static' routes<br>        if krt_source != ipp_static then<br>            reject;<br>        accept;<br>    };<br>    export all;<br>}<br><br>Workaround<br>-----------------<br>Use static protocol with routes not learned from kernel.<br><br>protocol static static254 {<br>  route fd8e:579a:623c:ffff::/64 drop;<br>}<br><br>Any ideas about solution/other workarouns for this problem are welcome.<br><br>--<br>SP5474-RIPE<br>Sergey Popovich<br></BODY></HTML>