From: Jeff D. <jd...@ka...> - 2002-04-27 15:51:46
|
hav...@gm... said: > I sometimes run mpls over vlan so at least make that 8 bytes overhead, > with label stackin (2+ mpls labels) that would be 12 bytes, I would > like think of that as a minimum acceptable oversized packet. 16 to > have some future margin. Can you explain exactly what you're doing and exactly why an ethernet frame isn't large enough? > It works for me. I choose those values incongruently and arbitrarily, > they should be the same, I just wrote some random number > 12 there. This is why I ignored it last time. I don't just toss random numbers into UML. Jeff |
From: Jeff D. <jd...@ka...> - 2002-04-29 23:35:35
|
md...@de... said: > You don't, and they don't. Plain old ethernet frames are still a > maximum of 1514 bytes, with a 1500-byte data payload. OK, since this is out of the realm of emulating a physical switch, why don't we just add an mtu option to uml_switch for those people who want to tack stuff onto their ethernet frames? If you want 16 extra bytes, '-mtu 1530' sounds like it gives you what you want without throwing random magic numbers into the code. Jeff |
From: Yon U. <hav...@gm...> - 2002-05-01 21:30:52
|
Hi, On Mon, 29 Apr 2002, Jeff Dike wrote: > md...@de... said: > > You don't, and they don't. Plain old ethernet frames are still a > > maximum of 1514 bytes, with a 1500-byte data payload. > > [fragmentation needed] AFAIK & IMHO some switches and some adapters/OS dont care about the extra bytes, they dont care for +4 in the VLAN case, they shouldnt care in the +4/+8/+12/+16 case for the MPLS(/VLAN) case. I doubt very much anybody (like some ISP) running MPLS over VLAN over fastethernet is fragmenting at all. There should be some information on vendor pages. > OK, since this is out of the realm of emulating a physical switch, why don't > we just add an mtu option to uml_switch for those people who want to tack > stuff onto their ethernet frames? > > If you want 16 extra bytes, '-mtu 1530' sounds like it gives you what you > want without throwing random magic numbers into the code. Yes, but the uml part is fixed, isnt it? Maybe add another parameter to the device config (mru?)? HAND yon |
From: Jeff D. <jd...@ka...> - 2002-05-02 03:42:08
|
hav...@gm... said: > Yes, but the uml part is fixed, isnt it? Maybe add another parameter > to the device config (mru?)? OK, so who produces these labels and who consumes them? Jeff |
From: Henrik N. <hn...@ma...> - 2002-05-02 07:21:45
|
On Thursday 02 May 2002 06:43, Jeff Dike wrote: > hav...@gm... said: > > Yes, but the uml part is fixed, isnt it? Maybe add another > > parameter to the device config (mru?)? > > OK, so who produces these labels and who consumes them? The VLAN (IEEE802.1Q) labels are created by: * The Linux kernel, if you have VLAN support enabled. (available in the base 2.4 kernel) * VLAN enabled switches, if you have set the port to "tagged". * VLAN enabled routers etc.. IEEE802.1Q VLANs enlarges the ethernet frames by 4 bytes for the VLAN label between the MAC header and the data (IP). Any devices dealing with IEEE802.1Q VLAN needs to be able to support ethernet frames of at least 1522 bytes. MPLS labels are created by MPLS ingress routers, and then possibly manipulated by MPLS routers. Used by MPLS switches. MPLS allows for a stack of labels (each 4 bytes) between the link header (MAC) and network header (IP). If the packets grows too large fragmentation may occur, but most devices allows for links configured to support large packets. Regards Henrik |
From: Jeff D. <jd...@ka...> - 2002-05-07 03:39:07
|
hn...@ma... said: > The VLAN (IEEE802.1Q) labels are created by: > * The Linux kernel, if you have VLAN support enabled. (available in > the base 2.4 kernel) So, if there's some slop added to the ethernet frame size that's conditional on VLAN support, that would take care of the UML side of things? > * VLAN enabled switches, if you have set the port to "tagged". Does this call for an addition to the uml_switch connection protocol, or is a -mtu switch good enough? And do those two things take care of the problem? Jeff |
From: Yon U. <hav...@gm...> - 2002-05-07 04:47:17
|
Hi, On Mon, 6 May 2002, Jeff Dike wrote: > hn...@ma... said: > > The VLAN (IEEE802.1Q) labels are created by: > > * The Linux kernel, if you have VLAN support enabled. (available in > > the base 2.4 kernel) > > So, if there's some slop added to the ethernet frame size that's conditional > on VLAN support, that would take care of the UML side of things? I dont quite understand that sentence. What I see: uml wont read more than a normal eth frame off the filedescriptors, tossing away the last 4+ bytes. Same issue on uml_switch. The problem is not sending from uml, that works (as far as i can see). It is sending. > > * VLAN enabled switches, if you have set the port to "tagged". > > Does this call for an addition to the uml_switch connection protocol, or > is a -mtu switch good enough? -mtu is enough, AFAI can see, for the uml_switch side of things. Including a redefinition of struct packet to a given maximum mtu, I suggest +20 bytes as the maximum. > And do those two things take care of the problem? |
From: Henrik N. <hn...@ma...> - 2002-05-07 07:24:21
|
On Tuesday 07 May 2002 06:40, Jeff Dike wrote: > So, if there's some slop added to the ethernet frame size that's > conditional on VLAN support, that would take care of the UML side > of things? Correct. This is what has been done for most the Ethernet drivers where allowed by the hardware. > > * VLAN enabled switches, if you have set the port to "tagged". > > Does this call for an addition to the uml_switch connection > protocol, or is a -mtu switch good enough? For experimental purposes -mtu (or simply allowing for slightly oversized frames) suffices I think, but the forwarding core of uml_switch needs to be VLAN extended to use one MAC table per VLAN tag. The same MAC address may appear in two different VLAN's. Initially, I think VLAN support is mostly interesting on TAP connections, allowing the UMLs to be connected to a real switch in a seamless manner. In the long run uml_switch should use some kind of port identification like we have previously discussed to allow the vlan_switch to be fully VLAN enabled (or firewalled). A fully VLAN enabled switch needs to unambiguously identify each port by configuration, as each port needs to be configured a) As a "normal" port, belonging to only one VLAN b) As a "tagged" port, accepting VLAN tagged frames and the UML administrator should from a security perspective have no control of this, making "UMID + interfacenumber + optional password" a suitable identification key. Having uml_switch fully VLAN enabled in a reasonable configurable manner would solve my need of using the old networking code quite easily.. Regards Henrik |
From: Yon U. <hav...@gm...> - 2002-05-07 08:46:20
|
Hi, On Tue, 7 May 2002, Henrik Nordstrom wrote: > On Tuesday 07 May 2002 06:40, Jeff Dike wrote: [snip] > > Does this call for an addition to the uml_switch connection > > protocol, or is a -mtu switch good enough? > > For experimental purposes -mtu (or simply allowing for slightly > oversized frames) suffices I think, but the forwarding core of > uml_switch needs to be VLAN extended to use one MAC table per VLAN > tag. The same MAC address may appear in two different VLAN's. > > Initially, I think VLAN support is mostly interesting on TAP > connections, allowing the UMLs to be connected to a real switch in a > seamless manner. I use VLANs over uml_switch. This allows me to recreate arbitrary topologies over a single uml_switch. VLAN support in uml_switch, as you are now proposing, is a future development, for a better security in the untrusted UMLs case. I want to use VLAN over uml_switch now, as I trust my UMLs (they are just my 'network lab'). > In the long run uml_switch should use some kind of port > identification like we have previously discussed to allow the > vlan_switch to be fully VLAN enabled (or firewalled). A fully VLAN > enabled switch needs to unambiguously identify each port by > configuration, as each port needs to be configured > a) As a "normal" port, belonging to only one VLAN and rejecting tagged frames > b) As a "tagged" port, accepting VLAN tagged frames sometimes called 'trunk' port or interswitch port, AFAIK. > and the UML administrator should from a security perspective have no > control of this, making "UMID + interfacenumber + optional password" > a suitable identification key. > > Having uml_switch fully VLAN enabled in a reasonable configurable > manner would solve my need of using the old networking code quite > easily.. What exactly do you need? What is the 'old networking code'? > Regards > Henrik > |
From: Henrik N. <hn...@ma...> - 2002-05-07 10:30:09
|
Yon Uriarte wrote: > I use VLANs over uml_switch. This allows me to recreate arbitrary > topologies over a single uml_switch. VLAN support in uml_switch, as you > are now proposing, is a future development, for a better security in the > untrusted UMLs case. Both yes and no. uml_switch will break down if the same MAC is seen in more than one VLAN, such as seen when doing bridgeing between VLANs. As I said using uml_switch like this is OK for lab usage, but should be avoided in real life. > > Having uml_switch fully VLAN enabled in a reasonable configurable > > manner would solve my need of using the old networking code quite > > easily.. > > What exactly do you need? What is the 'old networking code'? The "old networking code" is an older UML userspace networking implementation using "um_eth_serv", having a primitive VLAN like capability (without tagged/trunk ports. um_eth_serv acts as an "infinite" number of ethernet hubs). Use this to play with bridgeing, routing, VLAN, firewalling, ipsec, traffic shaping and many more nifty features in different configurations. Typical timespan of a specific setup is minutes before something is changed. What I need is the ability to have Z UML stations, each with 1-4 interfaces on N different "physical" ethernet networks where there may be bridges between one or more of the ethernets, routers betwen others. In theory I shoudl be able do this with uml_switch by running N instances of uml_switch (some running in HUB mode), and telling each UML station which uml_switch instance it should connect to for each interface, but as I have a much simpler setup using the old code I have stayed with it. Having a VLAN enabled uml_switch with a sane configuration would make me interested in switching ;-) Regards Henrik |
From: Yon U. <hav...@gm...> - 2002-04-28 19:48:29
|
Hi hi, On Sat, 27 Apr 2002, Jeff Dike wrote: > hav...@gm... said: > > I sometimes run mpls over vlan so at least make that 8 bytes overhead, > > with label stackin (2+ mpls labels) that would be 12 bytes, I would > > like think of that as a minimum acceptable oversized packet. 16 to > > have some future margin. > > Can you explain exactly what you're doing and exactly why an ethernet frame > isn't large enough? Yes, of course, good idea. Im running VLAN between UMLs communicating over an uml_switch. So I run a logical point2point topology over a physical (well, virtual, but they dont know) broadcast topology. HOST <-tun-> uml_switch <-> UML1 <-> UML2 and UML1 and UML2 run VLAN 10 over uml_switch. And they handle mpls labels over that VLAN. So a each Frame needs at least 8 extra bytes. Sometimes I run up to 4 UML, running 3 VLAN over the single uml_switch. I usually disable IP processing on the main interface with ifconfig eth0 0.0.0.0 > > It works for me. I choose those values incongruently and arbitrarily, > > they should be the same, I just wrote some random number > 12 there. > > This is why I ignored it last time. I don't just toss random numbers into > UML. 16 bytes should be enough to forget about it forever. HTH, HAND yon |
From: Jeff D. <jd...@ka...> - 2002-04-28 20:35:56
|
hav...@gm... said: > And they handle mpls labels over that VLAN. So a each Frame needs at > least 8 extra bytes. This was the real question. What's MPLS, and that are MPLS labels. If you go sticking them on each ethernet frame, how does that avoid confusing physical ethernet cards? Also, how do physical switches handle this? Do they get told to consider an ethernet frame to be 16 bytes longer than usual or is there some kind of MTU negotiation going on? Jeff |
From: Matt Z. <md...@de...> - 2002-04-28 23:37:42
|
On Sun, Apr 28, 2002 at 04:36:56PM -0400, Jeff Dike wrote: > hav...@gm... said: > > And they handle mpls labels over that VLAN. So a each Frame needs at > > least 8 extra bytes. > > This was the real question. What's MPLS, and that are MPLS labels. Multi-Protocol Label Switching. It's a way of attaching an identifier (label) to traffic which is used to create a path through a network in a protocol-independent way. Here's the WG: http://www.ietf.org/html.charters/mpls-charter.html > If you go sticking them on each ethernet frame, how does that avoid > confusing physical ethernet cards? > > Also, how do physical switches handle this? Do they get told to consider > an ethernet frame to be 16 bytes longer than usual or is there some kind > of MTU negotiation going on? You don't, and they don't. Plain old ethernet frames are still a maximum of 1514 bytes, with a 1500-byte data payload. If you have an Ethernet frame with a 1500-byte IP payload, and you need to add an MPLS label to it, the packet must be fragmented. -- - mdz |