[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)
Konrad,
It was excellent for you to have performed such a thorough
investigation, but the high-order consideration is this:
> Yes, the fib6_age function in ip6_fib.c under some circumstances deletes
> cached routes via non-routers (gateways),
Here, we have an implementation (linux kernel) that is
widely used as the basis for router products, and that
takes action based on the setting of the IsRouter flag
in neighbor cache entries. Linux is operating outside
the letter of the RFC4861 law in this regard, and if
Linux is making its own interpretation (no matter how
innocuous) then other implementations may be making
their own interpretations which may not be so innocuous.
Therefore, there needs to be a warning label.
Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Konrad Rosenbaum
> Sent: Friday, January 08, 2010 5:36 AM
> To: v6ops@ops.ietf.org
> Subject: Re: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
>
> Hi,
>
> I'm trying to confirm this route-loss-problem.
>
> On Wednesday 06 January 2010, Wes Beebee (wbeebee) wrote:
> > If IsRouter is FALSE, Linux will incorrectly garbage collect the
> > addresses, leading to lack of connectivity.
>
> What specific version of Linux is this? I just took a walk through the IPv6
> code in Linux 2.6.26 (Debian kernel) and did some experiments with it. I
> could not find the problem. Although I must admit I'm not a kernel expert.
>
> Yes, the fib6_age function in ip6_fib.c under some circumstances deletes
> cached routes via non-routers (gateways), but there is a difference between
> the FIB main (routing) table and the FIB cache (shortcuts for already
> resolved walks through the main table - it is just a speedup table). The
> entries established during CE-SP handshake will reside in the main table,
> which is not affected. The only collection that happens in the main table
> is timer based (based on the timeout given in RAs).
>
> Experiment:
> SP - a server running pppoe-server, with RAdvD and some DHCP server
> CE - my makeshift router, running pppoe-client and a simple Ethernet
> Host - a simple host on the Ethernet to CE
>
> [SP] <--PPP-link--> [CE] <--Ethernet--> [Host]
>
> The ethernet was setup manually with default route towards CE, so no
> collection here. If I took the steps to setup RAdvD on it, RAs would keep
> everything alive. So no issue either way.
>
> The SP is set up to be router on all interfaces.
>
> The CE is host on PPP and router on Ethernet.
>
> The Host is host.
>
> On the CE the PPP-link is setup in this order: IPCPv6, (automatic) RS-RA,
> optionally DHCP-IAPD which would configure the IP addr and RAdvD for the
> Ethernet, if it honours timeouts it will repeat the process in time. The
> PPP-link and its routes will be kept alive through RA's from the SP, or
> regular RS-RA-pairs. Nothing strange happens...
>
> The SP side of the PPP-link is configured from the PPP scripts. Which means
> manual routes, which do not get collected at all until the link goes down.
>
> I waited for all the timeouts to run out (a few minutes on my setup) and the
> FIB caches to clear (less than a minute). But I could still ping from
> anywhere in my setup to anywhere else in it. Actually the FIB cache was not
> even used for PPP links.
>
> In conclusion: unless I completely and intentionally screw up the setup
> manually, both links will always have complete routes on either end. The
> only difference after FIB cache garbage collection is that the first ping
> packet needs 10ms instead of 5ms.
>
> Did I miss the scenario?
>
> > What mischief happens if the CE Router always sets IsRouter to TRUE on
> > both WAN and LAN interfaces?
>
> The CE would shoot itself squarely into the foot: since it does not do a RS
> on the PPP-link, it will never know about its on-link prefix and will set
> some routes wrongly (which would need to be corrected manually). I wasn't
> even able to get pings to route from Host to SP if the CE had its ppp-link
> configured as router.
>
>
> Konrad