From: Shirley Ma <hidden> Date: 2003-11-20 00:21:38
Hi, Alexy,
A while ago, we had a discussion about IPv6 Prefix Table implementation.
I agree with you it's not necessary to process offlink prefix.
In each ipv6PrefixTable, there are 9 objects, which are Ifindex, Type, Prefix,
Length, Origin(addrconf, manually, dhcp, others), OnLinkFlag, AutonomoueFlag,
AdvPreferredLiftTime and ValidLifeTime.
As we know, the routing table has all on-link prefix routes. But only Prefix,
Length, Ifindex are saved in routing table, the rest objects info are not saved
anywhere.
One implementation detail question, do you think I need to save all the other
Prefix Objects: Type, Origin(addrconf, manually, dhcp, others), OnLinkFlag,
AutonomoueFlag, AdvPreferredLiftTime and ValidLifeTime in routing table also?
If so, sounds like I add a big structure in each prefix route entry in the routing table.
Thanks
Shirley Ma
IBM Linux Technology Center
=======================
List: linux-netdev
Subject: Re: [Issues] Implementation for IPv6 MIB:ipv6PrefixTable
From: kuznet () ms2 ! inr ! ac ! ru
Date: 2003-10-24 17:59:27
Hello!
First, do you think it's a good idea to save all prefix objects in routing
table?
Those which are on-link, of course.
Second, where is the best location for the off-link prefix, on-link flag 0
prefix to be saved?
Do you really think off-link prefixes are to be saved? Prefix in use is onlink
by defintion, so just return 1 in these bit and ignore off-link prefixes
completely, they are meaningless, are not they?
Third, do you think it's a good idea to implement a prefix table/per
interface in the kernel?
Well, if SNMP is going to be used as a tool to snoop ndisc promiscuously
(which seems to be the case if it shows inforrmation about offlink prefixes),
then it is definitely not a kernel task.
Alexey
One implementation detail question, do you think I need to save all the o=
ther=20
Prefix Objects: Type, Origin(addrconf, manually, dhcp, others),
These two things should be stored right now. Existing implementation is
quite a mess, but we definitely want to remember origin of each route
in "protocol" and another flags, they are of common interest.
AutonomoueFlag, AdvPreferredLiftTime and ValidLifeTime
ValidLifeTime is "expires" on this route.
What's about AdvPreferredLiftTime I am puzzled a little,
preferred time is not an attribute of a prefix at all,
it is attribute of address, is not it? Unless the prefix is used
to install local address it does not make sense, right?
Alexey
From: Shirley Ma <hidden> Date: 2003-12-05 20:14:47
I add this because there are some 64-bit counters in the new IPv6 MIBs.
This patch has been tested agaist linux-2.6.0-test9, and cleanly applied to
linux-2.6.0-test11.
Thanks
Shirley Ma
IBM Linux Technology Center
From: David S. Miller <hidden> Date: 2003-12-05 20:31:33
On Fri, 5 Dec 2003 12:14:47 -0800
Shirley Ma [off-list ref] wrote:
I add this because there are some 64-bit counters in the new IPv6 MIBs.
This patch has been tested agaist linux-2.6.0-test9, and cleanly applied to
linux-2.6.0-test11.
"sizeof(unsigned long)" evaluates to 8 on 64-bit systems,
yet you assume it always evaluated to 4 as on 32-bit systems.
Maybe it would be wiser to explicitly use 'u32' and 'u64' for
the types of the snmp counters?
This has always been a sore area.
From: Shirley Ma <hidden> Date: 2003-12-05 21:51:47
Once receiving a router advertisement message for prefix info,
a netlink notification event will be created.
This patch has been tested against linux-2.6.0-test11.
Thanks
Shirley Ma
IBM Linux Technology Center
From: David S. Miller <hidden> Date: 2003-12-05 22:57:00
On Fri, 5 Dec 2003 13:51:47 -0800
Shirley Ma [off-list ref] wrote:
Once receiving a router advertisement message for prefix info,
a netlink notification event will be created.
This patch has been tested against linux-2.6.0-test11.
Let's queue this up for 2.6.1, please resend it after 2.6.0 is
released.
From: Shirley Ma <hidden> Date: 2004-01-14 22:52:51
"sizeof(unsigned long)" evaluates to 8 on 64-bit systems,
yet you assume it always evaluated to 4 as on 32-bit systems.
Maybe it would be wiser to explicitly use 'u32' and 'u64' for
the types of the snmp counters?
This has always been a sore area.
This is the new patch against 2.6.1 kernel.
Thanks
Shirley Ma
IBM Linux Technology Center
From: David S. Miller <hidden> Date: 2004-01-15 08:48:33
On Wed, 14 Jan 2004 16:21:26 -0800
Shirley Ma [off-list ref] wrote:
This patch is against 2.6.1 kernel.
Can you explain what this patch is doing, and specifically what bug it is fixing?
I feel dense as I can't figure it out just by studying your patch and the code it
touches :-)
From: David S. Miller <hidden> Date: 2004-01-15 08:52:52
On Wed, 14 Jan 2004 15:52:51 -0800
Shirley Ma [off-list ref] wrote:
Once receiving a router advertisement message,
a netlink notification event will be created.
This patch is against linux-2.6.1.
This patch looks fine, except I can't see how RTM_GETRA is used anywhere.
Even if it will be used by some future change, please remove it until that
later change is made.
So please either show where RTM_GETRA is used or regenerate the patch with
that macro definition removed.
Thanks.
From: David S. Miller <hidden> Date: 2004-01-15 08:57:29
On Wed, 14 Jan 2004 14:52:51 -0800
Shirley Ma [off-list ref] wrote:
quoted
"sizeof(unsigned long)" evaluates to 8 on 64-bit systems,
yet you assume it always evaluated to 4 as on 32-bit systems.
Maybe it would be wiser to explicitly use 'u32' and 'u64' for
the types of the snmp counters?
This has always been a sore area.
This is the new patch against 2.6.1 kernel.
I am personally fine with this patch, but I do believe some folks might find
it controversial (for whatever reason) to move all of these stats over to 64-bits.
So I'm going to let this sit for another day or two so people can voice any
objections they may have.
In article [off-list ref] (at Thu, 15 Jan 2004 00:52:52 -0800), "David S. Miller" [off-list ref] says:
quoted
Once receiving a router advertisement message,
a netlink notification event will be created.
This patch is against linux-2.6.1.
This patch looks fine, except I can't see how RTM_GETRA is used anywhere.
Even if it will be used by some future change, please remove it until that
later change is made.
Hmm, why do we need this? What kind of usage?
I think you can do this in user space by opening raw socket.
--yoshfuji