Hi Darren,
Thanks for the comments.
Why are we fabricating the ethernet header rather than having snoop
ask lo0 what MAC type it is and using that to understand that there
is no MAC header to speak of?
The reason for this was to allow existing applications to work without
modification. However, given we will be getting libpcap updated to support
the new DL_IPNET type we will also make /dev/lo0 of type DL_IPNET.
How will the inter-zone obersvability play with pfhooks? And how will
this compare with seen with packet going in out of a physical
interface? For example, now with snoop, you see all packets that are
"on the wire" - how does this translate to inter-zone traffic with
pfhooks and snoop?
It will mirror the behaviour of what's seen for physical interfaces.
On the topic of zones, you mention that you'll publish the
appropriate zoneid "where available." Are you making any changes to
IP to increase or improve the availability of zone information with
respect to packets?
e.g the problem observed in this bug might be relevant:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6352430
There are no plans on adding anything formal in this space.
In your document, you write:
However,
right now there is no generic hook framework or PEF and so the only
choice is to implement our own. The Packet Filtering Hook case
does not provide a generic framework.
Would you like to expand on where the pfhooks case does not provide
you with a generic framework?
Perhaps the wording isn't clear here. As we've discussed before it's the
lack of multiple consumers that's the issue, not the location of hooks.
When this was discussed adding support for multiple consumers wasn't
something people wanted to tackle right now. I can modify the text to make
the problem clearer if it's necessary.
The description of dl_netinfo_t needs some work. Rather than using
uint64_t for zones, you should be using zoneid_t.
We disagree here. Consumers still need make assumptions about the actual
representation of zoneid_t to use it (eg. print it out). By using the
widest fixed width integral type (uint64_t) we avoid the problem. We've
asked the zones team for their advice over whether using uint64_t is ok
here and they have no problem with it.
Regarding changes to other software...
Why are we changing 3rd party software to interface with libdlpi.so
and not snoop as well?
The plan is to make 3rd party applications work with the new DL_IPNET
devices, this may not require changing the applications to use libdlpi.
In answer to you question about snoop, snoop will be modified to use
libdlpi.
Is there any value in snoop'ing based on zones when Solaris isn't
correctly tagging packets with the right zone? (See above.)
I think so. On a system where you've multiple zones configured
administrators might prefer not to think in terms of addresses, they
might prefer to deal in terms of zones. Of course they could also use
hostnames, adding the zones flags is there to make things easier.
Thanks
Phil
_______________________________________________
networking-discuss mailing list
[email protected]
