>Do you have any other suggestions on where zone information for network >interfaces or events related to zones and network interfaces could be useful? I have a specific need for the observability part of Clearview. I need to know zone related information to route traffic to only those users that should be allowed to see it. Thanks Phil
> hi folks > > the quagga/routing management design doc has just > been posted at > > https://www.opensolaris.org/os/community/networking/qu > agga-design.pdf > > the project aims to replace the SFWzebra routing > protocol suite with Quagga (http://www.quagga.net) > and, on a related subject (since Quagga for Solaris > includes an SMF manifest), update routing management > (and routing daemons) to fit with SMF. > > whether your interests lie in routing, SMF or > elsewhere, we're interested in hearing your comments, > and though the project is pretty straightforward, > there are collaboration opportunities if people are > interested. > > as mentioned above, deadline for comments is in 2 > weeks time (9 October). thanks! > > -- > alan maguire (alan dot maguire at sun dot com) Has anyone looked at openbsd's design with openbgpd This message posted from opensolaris.org
Philip Kirk - Solaris Sustaining wrote: > >Do you have any other suggestions on where zone information for network > >interfaces or events related to zones and network interfaces could > be useful? > > I have a specific need for the observability part of Clearview. I need > to know > zone related information to route traffic to only those users that > should be > allowed to see it. In this case, you should really be looking at the cred_t off the dblk_t in order to access the zoneid of the "packet". This would require elevating db_credp to being mentionable on the man page of dblk(9s) and hence making db_credp a stable field of dblk_t. You might need to do something about fixing 6352430 or maybe not. Darren
Darren Reed writes: > > I have a specific need for the observability part of Clearview. I need > > to know > > zone related information to route traffic to only those users that > > should be > > allowed to see it. > > > In this case, you should really be looking at the cred_t off the > dblk_t in order to access the zoneid of the "packet". The cred_t means something only when a user process allocated the message. That's not true for things coming off the wire, so that might not be very helpful here. > This would require elevating db_credp to being mentionable on > the man page of dblk(9s) and hence making db_credp a stable > field of dblk_t. Clearview is integrating in ON, and that's an Consolidation Private interface. There's no reason that it needs to be made stable for Clearview to use it. -- -- James Carlson, KISS Network <james.d.carlson@...> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
On Wed, Mar 01, 2006 at 02:45:21PM -0500, James Carlson wrote: > Darren Reed writes: > > > I have a specific need for the observability part of Clearview. I need > > > to know > > > zone related information to route traffic to only those users that > > > should be > > > allowed to see it. > > > > > > In this case, you should really be looking at the cred_t off the > > dblk_t in order to access the zoneid of the "packet". > > The cred_t means something only when a user process allocated the > message. That's not true for things coming off the wire, so that > might not be very helpful here. But eventually the packet will be processed and either dropped or "consumed" by a socket with a zoneid (allzones sockets, presumably, have the global zone as their zoneid). By then the packetness of the dblk might be lost, I dunno (check what fireengine/yosemite do), but if not then it could be a useful place for a hook (if there isn't one already). Nico -- --
This is a code review request for IPv4/IPv6 Duplicate Address
Detection ("DAD," CR 4728609 et al). I'd like to receive comments by
March 17th, 2006, but if you need more time, that's fine. You may
send comments directly to me if you like or to the networking-discuss
mailing list. Either is fine.
If you're off the SWAN, the materials are here:
http://cr.grommit.com/~carlsonj/dad-webrev/
http://cr.grommit.com/~carlsonj/dad-review/
If you're on the SWAN, then use:
http://zhadum.east/zbuild/carlsonj/4728609-review/webrev/
http://zhadum.east/zbuild/carlsonj/4728609-review/review/
The information is essentially the same in both places; the only real
difference is that the external version has external links for the
bugs and ARC cases. The data are essentially the same. The first
link is the webrev showing the changes and the second link provides
output from the "codereview," "fullreview," and "pdiffs -u" wx
features (for those who like such things). The webrev is sufficient
for review; you needn't look at the rest if you don't want.
In addition, for those on the SWAN only (sorry), there's a workspace
with cscope built in $SRC and $SRC/uts available here:
/net/zhadum.east/export/zbuild/carlsonj/4728609-review/
The CRs are in "fix understood" state because I don't yet have a
(Continue reading)
James Carlson wrote: >Darren Reed writes: > > >>>I have a specific need for the observability part of Clearview. I need >>>to know >>>zone related information to route traffic to only those users that >>>should be >>>allowed to see it. >>> >>> >>In this case, you should really be looking at the cred_t off the >>dblk_t in order to access the zoneid of the "packet". >> >> > >The cred_t means something only when a user process allocated the >message. That's not true for things coming off the wire, so that >might not be very helpful here. > > Indeed, that will have to wait until there is a classifier at a lower level that is capable of making that association. Darren
On Wed, 1 Mar 2006, art wrote:
> Has anyone looked at openbsd's design with openbgpd
Yes, it's interesting. They seem to have made a lot of progress, though
they're still missing a few things (as-path regex matching,
route-refresh or soft-reconfig[1]).
One critique I'd have of OpenBGPd is they seem to have a tendency to
ignore the RFC. OpenBGPd however does the following when accept()ing
connections ('p' represents other the remote peer):
if (p->fd != -1) {
if (p->state == STATE_CONNECT)
session_close_connection(p);
else {
close(connfd);
return;
}
}
Now, that's a whole lot simpler than the RFC admittedly, and it probably
works for 99.999% of cases, however it's not really robust AFAICT (would
be /great/ if it was). The worst case scenario is where both sides
repeatedly connect to each other at the same time - each time the
connections cross, each time both sides close(). I have a vague memory a
well-known vendor tried this trick before and had to back it out due to
interoperability problems.
I've had an email discussion with Henning about this, he swears it's
(Continue reading)
Philip Kirk - Solaris Sustaining wrote: > >Do you have any other suggestions on where zone information for network > >interfaces or events related to zones and network interfaces could > be useful? > > I have a specific need for the observability part of Clearview. I need > to know > zone related information to route traffic to only those users that > should be > allowed to see it. Ok, but what do you need to know zone related information about? Routes? Physical interfaces? Logical interfaces? Packets? ..something else..? Darren
James Carlson wrote: >Darren Reed writes: > >>>I have a specific need for the observability part of Clearview. I need >>>to know >>>zone related information to route traffic to only those users that >>>should be >>>allowed to see it. >>> >> >>In this case, you should really be looking at the cred_t off the >>dblk_t in order to access the zoneid of the "packet". >> > >The cred_t means something only when a user process allocated the >message. That's not true for things coming off the wire, so that >might not be very helpful here. > I should have included that my observations with dtrace indicate that looking at db_credp->cr_zoneid (using dtrace) is quite reliable for packets going out of the system as a means to determine the zone that "owns" a packet. But if you've got a process in a zone that has been granted net_rawaccess can't it then go and write packets out with any IP header? This would make matching on IP address somewhat useless for outbound packets, if so.(Continue reading)
RSS Feed1 | |
|---|---|
8 | |
1 | |
4 | |
2 | |
7 | |
12 | |
4 | |
17 | |
32 | |
17 | |
26 | |
11 | |
19 | |
22 | |
31 | |
45 | |
53 | |
57 | |
108 | |
102 | |
117 | |
209 | |
170 | |
107 | |
118 | |
174 | |
257 | |
196 | |
282 | |
404 | |
201 | |
308 | |
232 | |
255 | |
435 | |
268 | |
233 | |
131 | |
318 | |
374 | |
235 | |
266 | |
240 | |
476 | |
226 | |
225 | |
214 | |
124 | |
138 | |
182 | |
273 | |
381 | |
329 | |
368 | |
239 | |
678 | |
375 | |
310 | |
237 | |
201 | |
275 | |
176 | |
226 | |
247 | |
134 | |
205 | |
175 | |
195 | |
194 | |
289 | |
321 | |
121 | |
119 | |
112 | |
112 | |
90 | |
85 | |
73 | |
26 |
