[no subject]
___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] 802.1p priority (fixed)
> > Having the possibility to test and set the 802.1p or TOS values > > separately would avoid making a "trust"/"override" subtlety and will > > obviously make it more flexible. > > I agree on this point. The one thing to be careful of is that 802.1p > priorities and TOS values work rather differently in that TOS values fit > in to an existing field of the packet and 802.1p values require > modifications to the header and adding data between the header and the > real body, possiably with a resuling reduction in MTU (though what > you're doing trying to use 802.1p priority with crappy nic I don't know > :-). I do not understand your point here. TOS is indeed an existing field of the IPv4 header but AFAIK, this is the same for the 802.1p header [1]. There are already 3 bits reserved for priority (802.1p) near the 802.1q field which are both inside what they call "Tag Control Information". Regards, [1] http://www.networkdictionnary.com/protocols/8021p.php -- Jeremie Le Hen [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] 802.1p priority (fixed)
On Sun, Jan 23, 2005 at 12:22:19PM +0100, Jeremie Le Hen wrote: > > > Having the possibility to test and set the 802.1p or TOS values > > > separately would avoid making a "trust"/"override" subtlety and will > > > obviously make it more flexible. > > > > I agree on this point. The one thing to be careful of is that 802.1p > > priorities and TOS values work rather differently in that TOS values fit > > in to an existing field of the packet and 802.1p values require > > modifications to the header and adding data between the header and the > > real body, possiably with a resuling reduction in MTU (though what > > you're doing trying to use 802.1p priority with crappy nic I don't know > > :-). > > I do not understand your point here. TOS is indeed an existing field > of the IPv4 header but AFAIK, this is the same for the 802.1p header [1]. > There are already 3 bits reserved for priority (802.1p) near the 802.1q > field which are both inside what they call "Tag Control Information". At the point you are examining layer 3 state, you either have already stripped off the ethernet header or have not created it yet so you can't just modify it. At least according to what I've read, you may or may not want to tag all traffic so if you strip the tags, you not want to use a vlan tag on the packet. You do have the actual storage the TOS values will use since you have the IP header. I'm basicly saying that they aren't necessicairly as similar as you might think. It might make sense to modify the TOS bits directly in the firewall, but it is simply not possiable to modify the 802.1p bits at that point because there's no where to put them. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpZHKbvZ7UE8.pgp Description: PGP signature
Re: [PATCH] 802.1p priority (fixed)
On Sun, Jan 23, 2005 at 11:05:19AM +0500, Boris Kovalenko wrote: > Hello! > > > >I'm not sure why you need trust and override. It seems like you only > >need the ability to set or remove values as well as acting on already > >attached tags (which we're going to need to carry around as m_tags so >we > >can filter on and modify them in conjunction with layer 3 information). > > For example I have vlan of devices, which can set 802.1p themself > (Cisco IP Phones for example) based on their knowledge of situation. I > should just pass-trough their 802.1p because I don't know the situation. > In this case I should trust. Another example - I have devices that can > not set 802.1p (or more simply - it always 0), so I should set (or in > other words - override received value :) 802.1p myself. I still don't see how this usefull differs from taking action or not taking action. > > 3. Mark 802.1p at vlan drivers like 2 > > ifconfig vlan0 > > vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0 > > Here we are trusting received from low level information and set 6 if it > > is omitted > > ifconfig vlan0 > > vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0 > > Here we silently set 6. > > >If you're not going to do separate interfaces per priority (or > >perhaps set of priorities[0]) I'm not sure what the point of having the > >interface do anything is. Filtering is the job of the firewall so I'm > >not convinced we should be doing it in the vlan device. There's also > > Hmm... If You remember, the idea of filtering is not mine :) I wrote > it may be realized, but see no sense in that. The only thing I > suggested is > to set 802.1p values. Again, there are working realizations of 802.1p in > a world. Cisco for example. I can not access/modify 802.1p in firewall > (PIX/ACL/VACL). The only place where I may set 802.1p is the Catalyst > port. And on trunking port I may trust received values or reset them. > So, may be we should not to invent a bicycle? What Cisco does is of rather limited relevence IMO. The default case of a FreeBSD system is not a bridge or router but a host. We need to determine what makes sense for both the bridge/router case and the host case. Cisco's are for all practical purposes, not hosts. > >the complication that we need to handle the vlan=0 case which shouldn't > >be treated as a vlan at all and should be decapsulated in the actual > >device without a trip through the vlan code. > > What the vlan=0 is? On a wire we may receive tagged or untagged > frames. Untagged should go usual way, tagged via vlan driver (IMHO). I've found at least one refrence when googling for 802.1p which says that vlan 0 is reserved and means that the tag is only a priority. In that case there is no vlan and I don't think vlan devices should be involved. If they are, you must set the priority on every frame or priority and non-priority frames will be delivered to different intefaces which may or may not be what you want. I'm not 100% sure that's correct, but the IEEE has made it practialy impossiable to find 802.1p. I haven't found it yet. > >My suspicion is that we need to rethink the current separation of > >ether and vlan code. Making vlans less optional and doing more of the > >handling in ether_input and ether_output might be a good thing. > > I'm not a guru of FreeBSD net infrastructure, so I can not raise an > objection on this words. > > >[0] What I've read says that many switches group sets of priority > >values together reducing the set of valid values. > > And what this changes? Some switches totally ignore 802.1p. We're > talking about IEEE standard and should fully support it. Also, may You > point me where You have read this? The issue is that you may need the ability to treat some values as though they are the same because some network environments will do this. While I think a lower level solution will be the most useful in the end, I don't object to an interface based solution. I think you should proceed with that with the idea that you add a third, optional keyword to vlan initalization to specify priority. That way you can create seperate interfaces for each priority for any vlan tag. Something like: ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3 -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpc7vdkVWLjf.pgp Description: PGP signature
Weird situation
Here I am again, experimenting with FreeBSD on the network.
My last questions here helped me get a firewall to help our network.
Now, I have a test setup in a virtual environment… but I have a problem.
(why else would I be writing here then?). At the moment I have no clue what
to even look up on Google or the archives (so all I’ve been able to do at
the moment is experiment).
The problem: traffic is flowing through one way, not back, through a test
environment.
The setup:
Main connection:
Router -> [vlan0][fxp1] firewall (production) [fxp0][vlan1] -> managed
switch, cuts off the vlan tag.
>From the switch -> secondary switch -> {FreeBSD test firewall -> FreeBSD
test server}
The two servers between '{' and '}' are running inside virtual PC on a
windows 2000 server (the best I could make up for a "lab"). They were build
by having the test firewall de0 linked with the physical nic, and de1 to a
"Microsoft loopback adapter", de0 of the test server as well.
Problem:
Pings from the test server at the end of the chain to the router don't come
back all the way.
Tests to date:
I've been using tcpdump -i {interface} "host {test_ip}" at each stage.
At the main firewall, tcpdump shows both request and reply, no problem.
On the win2k server, ethereal shows both request and reply, no problem.
On the test firewall, I see only the outgoing ICMP ping request.
At all points, the TTL seems fine (still 255 when captured by the win2k
server).
So I wondered, is virtual PC not sending the packet along?
But the freebsd firewall server can ping the router no problem.
What about the communication between the two freebsd servers?
Ping works with no problem at all.
The test firewall is as open as I can make, it is built with the same kernel
configuration as the production firewall, it is enabled in rc.conf with type
OPEN.
I'm not sure I know what to do about this problem at the moment, And
therefore ask if anybody knows what I could do about this?
Writing a this down, I had a crazy idea that depresses me... what if
Virtual PC is not respecting the PROMISC mode of the virtual network card
and then the test server is not seeing traffic not specifically meant for
it... :( Can anybody confirm or give any suggestions?
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Weird situation
I apologize for hitting the send button too quickly.
Once all noted down, it clicked in my mind that virtual pc mustn't be
respecting the PROMISCUOUS mode of the virtual network card. Once I had a
question in mind, a google search answered that yes, that is a limitation of
virtual PC. So, *sigh* there goes a day of installation and preparation.
So the only remaining solution I can imagine, is... does anybody have an
idea how I could have the virtual firewall test server register itself for
the IP address of the second test server and still function as a gateway
properly (it does have the two nics bridged)? Maybe using ipfw to forward
the traffic by MAC address? I'm going to sleep on it, anybody with advice
would receive my full gratitude!
Andrew
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andrew Seguin
Sent: Sunday, January 23, 2005 11:26 PM
To: freebsd-net@freebsd.org
Subject: Weird situation
Here I am again, experimenting with FreeBSD on the network.
My last questions here helped me get a firewall to help our network.
Now, I have a test setup in a virtual environment… but I have a problem.
(why else would I be writing here then?). At the moment I have no clue what
to even look up on Google or the archives (so all I’ve been able to do at
the moment is experiment).
The problem: traffic is flowing through one way, not back, through a test
environment.
The setup:
Main connection:
Router -> [vlan0][fxp1] firewall (production) [fxp0][vlan1] -> managed
switch, cuts off the vlan tag.
>From the switch -> secondary switch -> {FreeBSD test firewall -> FreeBSD
test server}
The two servers between '{' and '}' are running inside virtual PC on a
windows 2000 server (the best I could make up for a "lab"). They were build
by having the test firewall de0 linked with the physical nic, and de1 to a
"Microsoft loopback adapter", de0 of the test server as well.
Problem:
Pings from the test server at the end of the chain to the router don't come
back all the way.
Tests to date:
I've been using tcpdump -i {interface} "host {test_ip}" at each stage.
At the main firewall, tcpdump shows both request and reply, no problem.
On the win2k server, ethereal shows both request and reply, no problem.
On the test firewall, I see only the outgoing ICMP ping request.
At all points, the TTL seems fine (still 255 when captured by the win2k
server).
So I wondered, is virtual PC not sending the packet along?
But the freebsd firewall server can ping the router no problem.
What about the communication between the two freebsd servers?
Ping works with no problem at all.
The test firewall is as open as I can make, it is built with the same kernel
configuration as the production firewall, it is enabled in rc.conf with type
OPEN.
I'm not sure I know what to do about this problem at the moment, And
therefore ask if anybody knows what I could do about this?
Writing a this down, I had a crazy idea that depresses me... what if
Virtual PC is not respecting the PROMISC mode of the virtual network card
and then the test server is not seeing traffic not specifically meant for
it... :( Can anybody confirm or give any suggestions?
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 1/21/2005
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] 802.1p priority (fixed)
Brooks Davis wrote:
Hello!
I still don't see how this usefull differs from taking action or not
taking action.
Just more simple to understand (trusted or not trusted vlan (IMHO)), but
taking action via IPFW of course will be more flexible.
What Cisco does is of rather limited relevence IMO. The default case of
a FreeBSD system is not a bridge or router but a host. We need to
determine what makes sense for both the bridge/router case and the host
case. Cisco's are for all practical purposes, not hosts.
Thinking my idea satisfies router/bridge an host as well. We may set
value or may pass-trough it.
I've found at least one refrence when googling for 802.1p which says
that vlan 0 is reserved and means that the tag is only a priority. In
that case there is no vlan and I don't think vlan devices should be
involved. If they are, you must set the priority on every frame or
priority and non-priority frames will be delivered to different
intefaces which may or may not be what you want.
I'm not 100% sure that's correct, but the IEEE has made it practialy
impossiable to find 802.1p. I haven't found it yet.
Augh... it that case. Yes, VLID==0 is reserved for "priority" packets,
but it should not be used in usual way. And this packet will have full
802.1Q header indeed.
And what this changes? Some switches totally ignore 802.1p. We're
talking about IEEE standard and should fully support it. Also, may You
point me where You have read this?
The issue is that you may need the ability to treat some values as
though they are the same because some network environments will do this.
Don't think that. What to do with each value is our own decision and
only when we want to implement priority queues, in all other cases we
may just ignore it (this way FreeBSD currently does).
While I think a lower level solution will be the most useful in the
end, I don't object to an interface based solution. I think you should
proceed with that with the idea that you add a third, optional keyword
to vlan initalization to specify priority. That way you can create
seperate interfaces for each priority for any vlan tag. Something like:
ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3
But this is already done with my patch!!! :))) Have You seen it? I've
added also ability to set apropriate CFI. Attached patch again to this
message. Please review it again :)
-- Brooks
--
With respect,
Boris
--- sbin/ifconfig/ifconfig.h.orig Wed Jan 19 10:44:20 2005
+++ sbin/ifconfig/ifconfig.hFri Jan 21 09:11:22 2005
@@ -49,6 +49,8 @@
extern void setvlantag(const char *, int, int, const struct afswtch *rafp);
extern void setvlandev(const char *, int, int, const struct afswtch *rafp);
+extern void setvlanpri(const char *, int, int, const struct afswtch *rafp);
+extern void setvlancfi(const char *, int, int, const struct afswtch *rafp);
extern void unsetvlandev(const char *, int, int, const struct afswtch *rafp);
extern void vlan_status(int s, struct rt_addrinfo *);
--- sbin/ifconfig/ifconfig.c.orig Wed Jan 19 10:56:44 2005
+++ sbin/ifconfig/ifconfig.cFri Jan 21 09:11:54 2005
@@ -247,6 +247,8 @@
#endif
#ifdef USE_VLANS
{ "vlan", NEXTARG,setvlantag },
+ { "vlanpri",NEXTARG,setvlanpri },
+ { "vlancfi",NEXTARG,setvlancfi },
{ "vlandev",NEXTARG,setvlandev },
{ "-vlandev", NEXTARG,unsetvlandev },
#endif
--- sbin/ifconfig/ifvlan.c.orig Thu Apr 18 23:14:09 2002
+++ sbin/ifconfig/ifvlan.c Fri Jan 21 12:19:38 2005
@@ -59,6 +59,8 @@
"$FreeBSD: src/sbin/ifconfig/ifvlan.c,v 1.5 2002/04/18 17:14:09 imp Exp $";
#endif
static int __tag = 0;
+static int __pri = 0;
+static int __cfi = 0;
static int __have_tag = 0;
void
@@ -72,9 +74,10 @@
if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
return;
- printf("\tvlan: %d parent interface: %s\n",
- vreq.vlr_tag, vreq.vlr_parent[0] == '\0' ?
- "" : vreq.vlr_parent);
+ printf("\tvlan: %d 802.1p: %d CFI: %d parent interface: %s \n",
+ EVL_VLANOFTAG(vreq.vlr_tag), EVL_PRIOFTAG(vreq.vlr_tag),
+ EVL_CFIOFTAG(vreq.vlr_tag),
+ vreq.vlr_parent[0] == '\0' ? "" : vreq.vlr_parent );
return;
}
@@ -88,13 +91,66 @@
__tag = tag = atoi(val);
__have_tag = 1;
+ if(tag < 1 || tag > 4094)
+ errx(1, "VLAN ID shoud be in range 1..4094");
+
+ bzero((char *)&vreq, sizeof(struct vlanreq));
+ ifr.ifr_data = (caddr_t)&vreq;
+
+ if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCGETVLAN");
+
+ vreq.vlr_tag = EVL_MAKETAG(tag, __pri, __cfi);
+
+ if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
+ err(1, "SIOCSETVLAN");
+
+ return;
+}
+
+void
+setvlanpri(const char *val, int d, int s, const struct afswtch *afp)
+{
+ u_
