Re: Re (2): Linux hub
On Wed, 08 Sep 2010 13:21:58 -0500 Stan Hoeppner wrote: ... > Considering the cost of the entire switch IC in a $10 USD 8 port switch > (which includes an external AC/DC transformer and a 3 foot ethernet > patch cable for the price) is less than $1 in 10k unit quantities, the > cost of say 64KB RAM on that switch chip is going to be in the 10 cent > range or less. > > The reason many/most cheap 4/8/16 port switches have an 8192 entry MAC > table is because they're all likely using the same switch chip from a > single vendor, and this chip was designed with an 8192 entry MAC table. > The chip is cheap, reliable, and available in large quantities, so > everyone uses it. Makes sense, thanks. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908145930.64678532.cele...@gmail.com
Re: Re (2): Linux hub
Celejar put forth on 9/7/2010 6:58 PM: > I suppose, but since the vast majority of applications of cheap > switches don't require this capability, wouldn't it be cheaper to leave > it out, and only include it as an extra feature for those who need it? > > I don't actually know what it costs them to include the RAM for the MAC > table, though; perhaps it's negligible, so they just always throw it in. Considering the cost of the entire switch IC in a $10 USD 8 port switch (which includes an external AC/DC transformer and a 3 foot ethernet patch cable for the price) is less than $1 in 10k unit quantities, the cost of say 64KB RAM on that switch chip is going to be in the 10 cent range or less. The reason many/most cheap 4/8/16 port switches have an 8192 entry MAC table is because they're all likely using the same switch chip from a single vendor, and this chip was designed with an 8192 entry MAC table. The chip is cheap, reliable, and available in large quantities, so everyone uses it. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c87d446.3050...@hardwarefreak.com
Re: Re (2): Linux hub
On Tue, 07 Sep 2010 19:18:49 -0500 John Hasler wrote: > Celejar writes: > > I suppose, but since the vast majority of applications of cheap > > switches don't require this capability, wouldn't it be cheaper to > > leave it out, and only include it as an extra feature for those who > > need it? > > They have to have a MAC table and with current technology it costs no > more to store 8K MAC addresses then 8. I suspected that that might be the case. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907211205.b1bd143a.cele...@gmail.com
Re: Re (2): Linux hub
Celejar writes: > I suppose, but since the vast majority of applications of cheap > switches don't require this capability, wouldn't it be cheaper to > leave it out, and only include it as an extra feature for those who > need it? They have to have a MAC table and with current technology it costs no more to store 8K MAC addresses then 8. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqwp84uu@thumper.dhh.gt.org
Re: Re (2): Linux hub
On Tue, 07 Sep 2010 00:04:42 -0500 Stan Hoeppner wrote: > Celejar put forth on 9/6/2010 8:42 PM: > > > I'm curious; especially for the cheap switches, why would they need to > > store so many MAC addresses? What's the use case for a cheap switch > > actually seeing thousands of MACs since 'boot'? > > Scenario: I work for a huge company that has 7,000 employees in a > single campus, with more than that many PCs, Servers, printers, etc, > each having a MAC address. I'm doing layer 2 switching campus wide, and > only routing at the network edge to/from the internet/wan provider. > > I'm in a tech lab, and I need to jack in a small switch for testing > servers. People all over the campus are going to need to hit the test > servers. Thus, this little 8 port switch in my lab needs to be able to > store more than 7,000 mac addresses. > > Maybe not the best scenario, but it's a valid one. I suppose, but since the vast majority of applications of cheap switches don't require this capability, wouldn't it be cheaper to leave it out, and only include it as an extra feature for those who need it? I don't actually know what it costs them to include the RAM for the MAC table, though; perhaps it's negligible, so they just always throw it in. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907195819.3e9b4254.cele...@gmail.com
Re: Re (2): Linux hub
On Tuesday, September 07, 2010 10:13:51 you wrote: >> Original Message >>From: b...@iguanasuicide.net >>>In <380-2201091623840...@netptc.net>, ow...@netptc.net wrote: I'm not disagreeing with you in practice but many years ago these WERE the definitions the ITU and ISO dealt with. >>> >>>I love to see an actual ISO or ITU document that provides a >>>normative >>>definition of the any of those terms. Since you are claiming such a >>>document >>>exists, perhaps you could provide a URL, ISBN, or other reference? > >I'll see if I can dig up a reference. Remember this was in the 80s. ISO tends to keep documents around. For example, the drafts for the C89 standard, written during the 80s are still available from the C language working group's web site. (Of course, drafts aren't generally considered normative.) The standard itself may even still be available from the web store, even though it has been supplanted by the C99 standard. For less volatile areas under the auspices of ISO, much older standards are still available from the web store. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Re (2): Linux hub
> > > > Original Message >From: jesus.nava...@undominio.net >To: debian-user@lists.debian.org >Subject: Re: Re (2): Linux hub >Date: Tue, 7 Sep 2010 16:10:55 +0200 > >>Hi, owens: >> >>On Tuesday 07 September 2010 01:08:40 ow...@netptc.net wrote: >>[...] >> >>> Boyd >>> I'm not disagreeing with you in practice but many years ago these >>> WERE the definitions the ITU and ISO dealt with. IIRC it was the >>> vendors who screwed things up by introducing such products as >>> "swithcing hub" >> >>For one time this is not because of marketing: a "switch" *is* a >switching hub >>just as a "hub" is a multiport repeater. They are just plain >descriptions of >>what they do. >> >> >>-- >>To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org >>with a subject of "unsubscribe". Trouble? Contact >listmas...@lists.debian.org >>Archive: http://lists.debian.org/201009071610.55390.jesus.nava...@un >dominio.net >> Somewhat OT but I found more modern "definitions" of these terms in the IEEE Standard Dictionary of Electrical and Electronics Terms (I have the Sixth Edition) Larry >> -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/380-2201092718838...@netptc.net
Re: Re (2): Linux hub
> > > > Original Message >From: b...@iguanasuicide.net >To: ow...@netptc.net >Subject: Re: Re (2): Linux hub >Date: Mon, 6 Sep 2010 18:45:33 -0500 > >>In <380-2201091623840...@netptc.net>, ow...@netptc.net wrote: >>>> Original Message >>>>From: b...@iguanasuicide.net >>>>>In <380-22010905162433...@netptc.net>, ow...@netptc.net wrote: >>>>>>> Original Message >>>>>>>From: peasth...@shaw.ca >>>>>>>>From: "PT M." >>>>>>>>Quoting from http://en.wikipedia.org/wiki/Network_switch, >>>>>>>>"Switches may operate at one or more OSI layers, including >>>>>>>>physical, >>>>>>>>data link, network, or transport (i.e., end-to-end)." >>>>>> >>>>>>Lots of terminology confusion. It used to be hubs were at level >1, >>>>>>switches at level 2, routers at level 3 and gateways above level >3. >>>>>>Larry >>>>> >>>>>TL;DR: That's an over-simplification or a case of nostalgia. >>> >>>I'm not disagreeing with you in practice but many years ago these >>>WERE the definitions the ITU and ISO dealt with. >> >>I love to see an actual ISO or ITU document that provides a >normative >>definition of the any of those terms. Since you are claiming such a >document >>exists, perhaps you could provide a URL, ISBN, or other reference? >>-- >>Boyd Stephen Smith Jr. ,= ,-_-. =. >>b...@iguanasuicide.net ((_/)o o(\_)) >>ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' >>http://iguanasuicide.net/\_/ >> I'll see if I can dig up a reference. Remember this was in the 80s. Larry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/380-22010927151351...@netptc.net
Re: Re (2): Linux hub
Hi, owens: On Tuesday 07 September 2010 01:08:40 ow...@netptc.net wrote: [...] > Boyd > I'm not disagreeing with you in practice but many years ago these > WERE the definitions the ITU and ISO dealt with. IIRC it was the > vendors who screwed things up by introducing such products as > "swithcing hub" For one time this is not because of marketing: a "switch" *is* a switching hub just as a "hub" is a multiport repeater. They are just plain descriptions of what they do. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009071610.55390.jesus.nava...@undominio.net
Re: Re (2): Linux hub
Celejar put forth on 9/6/2010 8:42 PM: > I'm curious; especially for the cheap switches, why would they need to > store so many MAC addresses? What's the use case for a cheap switch > actually seeing thousands of MACs since 'boot'? Scenario: I work for a huge company that has 7,000 employees in a single campus, with more than that many PCs, Servers, printers, etc, each having a MAC address. I'm doing layer 2 switching campus wide, and only routing at the network edge to/from the internet/wan provider. I'm in a tech lab, and I need to jack in a small switch for testing servers. People all over the campus are going to need to hit the test servers. Thus, this little 8 port switch in my lab needs to be able to store more than 7,000 mac addresses. Maybe not the best scenario, but it's a valid one. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c85c7ea.9000...@hardwarefreak.com
Re: Re (2): Linux hub
Boyd Stephen Smith Jr. put forth on 9/6/2010 6:16 AM: > But, > they are still "smart" devices when compared to a hub, cable, repeater, or > other device that operates with no internal state. Agreed in that "smart" here simply means the device looks at the content of a frame, specifically the target MAC address, and decides which port to transmit the frame out of based on that data. An ethernet hub, or repeater, simply retransmits electrical,or sometimes optical, signals. Some switches are much much smarter than others, making low end switches look more akin to a hub. We're on the same page. I was being a bit pedantic. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c85c430.20...@hardwarefreak.com
Re: Re (2): Linux hub
On Mon, 06 Sep 2010 00:43:38 -0500 Stan Hoeppner wrote: ... > A traditional el cheapo desktop 8 port ethernet switch, such as the $10 > Rosewill 10/100 switch on my desk, has a single simple 8x8 crossbar > switch ASIC, enough RAM to store 8192 MAC addresses, and possibly a ... > The larger switch ASICs cost far more than those in $10 eight port > switches, have more memory for storing MAC addresses, and have extensive I'm curious; especially for the cheap switches, why would they need to store so many MAC addresses? What's the use case for a cheap switch actually seeing thousands of MACs since 'boot'? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100906214237.da06e888.cele...@gmail.com
Re: Re (2): Linux hub
In <380-2201091623840...@netptc.net>, ow...@netptc.net wrote: >> Original Message >>From: b...@iguanasuicide.net >>>In <380-22010905162433...@netptc.net>, ow...@netptc.net wrote: > Original Message >From: peasth...@shaw.ca >>From: "PT M." >>Quoting from http://en.wikipedia.org/wiki/Network_switch, >>"Switches may operate at one or more OSI layers, including >>physical, >>data link, network, or transport (i.e., end-to-end)." Lots of terminology confusion. It used to be hubs were at level 1, switches at level 2, routers at level 3 and gateways above level 3. Larry >>> >>>TL;DR: That's an over-simplification or a case of nostalgia. > >I'm not disagreeing with you in practice but many years ago these >WERE the definitions the ITU and ISO dealt with. I love to see an actual ISO or ITU document that provides a normative definition of the any of those terms. Since you are claiming such a document exists, perhaps you could provide a URL, ISBN, or other reference? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Re (2): Linux hub
> > > > Original Message >From: b...@iguanasuicide.net >To: debian-user@lists.debian.org >Subject: Re: Re (2): Linux hub >Date: Sun, 5 Sep 2010 14:56:53 -0500 > >>In <380-22010905162433...@netptc.net>, ow...@netptc.net wrote: >>>> Original Message >>>>From: peasth...@shaw.ca >>>>>From: "PT M." >>>>>Quoting from http://en.wikipedia.org/wiki/Network_switch, >>>>>"Switches may operate at one or more OSI layers, including >physical, >>>>>data link, network, or transport (i.e., end-to-end)." >>> >>>Lots of terminology confusion. It used to be hubs were at level 1, >>>switches at level 2, routers at level 3 and gateways above level 3. >>>Larry >> >>That's not quite true; it's never been that clear cut, although some >would >>like to believe that. >> >>Hubs are "dumb" devices, almost always implemented entirely in >hardware, and >>as such basically ignored everything above layer 1. Mostly they >should be >>avoided for TCP/IP over Ethernet, since they generate more traffic >then >>required by Ethernet (which is layer 1 and 2). In hubs, the most >complex IC >>would not be complex enough to call a CPU in modern times. >> >>Switches are smart devices, but not traditionally programmable. >They do use >>some RAM to store information about seen packets in order to make >decisions >>about future packets. They do not use out-of-band information to >make >>switching decisions. With TCP/IP over Ethernet, they generally >operate at >>layer 2 (Ethernet, which is also layer 1) or 3. Switches that do >understand a >>layer above 2 will generally fall back to layer 2 when encountering >a higher >>layer protocol they do not recognize. Switches generally have a >CPU, for >>handling the configuration interface, which might be extensive, even >on layer >>2 switches, given all the parts of the Ethernet protocol. However, >the >>hardware is designed so that packets do not have to travel through >the CPU >>bus. >> >>Routers are programmable devices. They have detailed configurations >plus >>static routes and routing rules. In addition, they generally use >out-of-band >>information (like BGP etc.) to update their routes and rules in >near-real- >>time. They likely drop data that doesn't correspond to a layer 3 >protocol >>they understand, but could be configured to route it somewhere. >They will >>inspect layer 4 and possibly above data to aid their layer 3 >routing. They >>will certainly have a CPU, but they also have switch-like hardware >so that >>packets do not have to travel through the CPU bus. Even packets >that need to >>travel to the CPU for special processing may be routed but also >saved so that >>traffic doesn't have to wait on the CPU; alternatively there may be >>specialized processors have more bandwidth then the CPU but much >more limited >>functionality. >> >>A PC can pretend to be a router, switch, or even a hub. However, >unless it >>has some fairly specialized hardware, high load will reveal the PC. >The main >>cause of this is saturation of the bus between the network card and >the CPU, >>since all the packets have to flow to the CPU and back. >> >>Gateway is a much more generic term, but basically it connects your >network >>with an outside network (or the Internet). It will generally have >at least >>minimal routing capabilities, but it may simply be an intermediary, >linking a >>single switch/router to a single other gateway. However, it may >also be a >>feature-complete router and firewall along with doing layer 5-7 >inspection to >>enforce network policy. For most personal and small business needs, >it can >>simply be a PC; the traffic to outside networks being too >constrained to need >>more bandwidth then is available across a modern PC bus, especially >if all >>that bandwidth is through a single connection to a single ISP at any >one time. >>Once external traffic reaches some level though, you'll need >specialized >>hardware, so your gateway will likely be an "enterprise" router. >> >>The specialized hardware that routers need, basically a >"programmable" version >>of the hardware in a switch, was/is one of the main roadblocks on >the way to a >>optical-only Internet backbone. For the longest time, even when the >links >>where optical
Re: Re (2): Linux hub
In <4c847f8a.3060...@hardwarefreak.com>, Stan Hoeppner wrote: >Layer 2 ethernet switches, the bulk of all sold to date, don't have any >knowledge of "packets". They don't store information about "seen >packets". > >Packets exist at layer 3 in OSI. Sorry, I was overusing the term "packet". I was not referring to an IP packet. I was referring to an Ethernet frame. It's still packet-ized data, rather than something like a TCP stream. Switches are quite aware of Ethernet frames. I've even uttered the the phrase "Ethernet packet" and most people understood what I meant, even though no such animal actually exists. I own a switch (actually, it is a roommate's) that operates at layers 2 and 3, does QOS, Vlans, STP, etc. It does not handle true routing, as all this configuration is either static or based on recently seen related packets. It doesn't understand BGP, OSPF, or any of the other routing protocols. Processing and possibly emitting data from one of the routing protocols is the main requirement to call something a router in my mind. Anything less is just a switch. Some of them are quite smart; others are relatively dumb. But, they are still "smart" devices when compared to a hub, cable, repeater, or other device that operates with no internal state. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Re (2): Linux hub
Rick Thomas put forth on 9/5/2010 10:51 PM: > Does Spanning Tree Protocol and/or V-lan tagging count as "out-of-band > information"? Yes. As does L2TP, L2QOS, port mirroring, link aggregation (channel bonding), etc, etc. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c84809b.2020...@hardwarefreak.com
Re: Re (2): Linux hub
Boyd Stephen Smith Jr. put forth on 9/5/2010 2:56 PM: > Switches are smart devices, but not traditionally programmable. They do use > some RAM to store information about seen packets in order to make decisions > about future packets. Ethernet switches are not "smart" devices at all, unless you're talking about more expensive models such as Cisco units that support things such as VLANs, layer 2 QOS, multi switch stacking, etc. A traditional el cheapo desktop 8 port ethernet switch, such as the $10 Rosewill 10/100 switch on my desk, has a single simple 8x8 crossbar switch ASIC, enough RAM to store 8192 MAC addresses, and possibly a small frame buffer per port (2k to 16k), since the switching mode is store and forward--buffering even just one 1500 byte frame can substantially increase performance under load. Layer 2 ethernet switches, the bulk of all sold to date, don't have any knowledge of "packets". They don't store information about "seen packets". The only information they store is the MAC addresses of all the devices which have broadcast their MAC address over the wire at power on. Packets exist at layer 3 in OSI, and can be from any number of protocols including IPX/SPX, TCP/IP, encapsulated fiber channel, PPPoE, PPTP, etc, etc. Switches are ignorant of packets. Switches accept and pass ethernet _frames_ which contain the packets. And every frame passing through a switch does go through the "CPU" of the switch, called the crossbar, which is a very simple ASIC in low end switches. Larger switches, such as some 576 (max) port core switches (24 blades w/24 ports each), have rather large central crossbar ASICs, or multiple smaller ones connected in a grid. The switch ASIC on each blade card, say a 24 port 10/100/1000 switch blade, will likely be a 26x26 crossbar, with 24 full duplex 10/100/100 device ports, and two full duplex 10 Gb/s back plane connections to the central switch ASIC(s). The larger switch ASICs cost far more than those in $10 eight port switches, have more memory for storing MAC addresses, and have extensive management processing power. But the core design is the same, a crossbar switching ethernet frames in one port and out another, with or without buffering. Switches aren't really smart devices. For "smart", you need something processing layer 3 and higher protocols, such as a router or firewall. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c847f8a.3060...@hardwarefreak.com
Re: Re (2): Linux hub
On Sunday, September 05, 2010 22:51:16 you wrote: >Thanks for the informative discussion! > >On Sep 5, 2010, at 3:56 PM, Boyd Stephen Smith Jr. wrote: >> Switches are smart devices, ... They do not use out-of-band >> information to make >> switching decisions. > >Does Spanning Tree Protocol and/or V-lan tagging count as "out-of-band >information"? Vlan mapping is configuration information. Single ports are tagged as either trunked (expect vlan header and process it) or vlan $n (expect packets with no vlan header and "add" it; remove vlan header when sending). The headers themselves are in-band, since they are directly attached to the packet they apply to. I suppose there might be some protocol I'm not familiar with that dynamically rearranges vlan mappings much the same way BGP plays with routing tables. I don't believe it part of Ethernet standard, but it certainly could exist. I believe a device that spoke this hypothetical protocol would be more appropriately called a router (or a "layer 2" router). Whether STP is on is a configuration information. Keeping track of which MACs are on each port, and which ports are part of the same tree, also just requires "memorizing" information about the existing packet flow, and can be read from the packets themselves. I referred to BGP as "out-of-band" since it contains information about how to route "unrelated" packets. Seeing that a certain MAC/IP was visible on a certain port and sending packets destined to that address down that port is remembering information about related packets, which is what switches do. STP is an extension to this process. Some switches are less feature-complete then others and have very little (or nothing) in the way of configuration information. They are barely more than a hub, and don't support vlans or STP, but only the base Ethernet specification. When they first came out, they were layer 2 devices, now they don't even support all our layer 2 features, but as long as they understand a bit more than the physical layer, they are a switch and not a hub. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Re (2): Linux hub
Thanks for the informative discussion! On Sep 5, 2010, at 3:56 PM, Boyd Stephen Smith Jr. wrote: Switches are smart devices, ... They do not use out-of-band information to make switching decisions. Does Spanning Tree Protocol and/or V-lan tagging count as "out-of-band information"? Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/63b0cad0-8c28-4670-8467-04543a255...@pobox.com
Re: Re (2): Linux hub
Hi: On Sunday 05 September 2010 17:14:34 peasth...@shaw.ca wrote: > From: Andrei Popescu > Date: Sun, 05 Sep 2010 09:08:04 +0300 > > > AFAICT, what you ask for is a gateway/router. Here is a very short > > tutorial: ... > > Thanks. http://carnot.yi.org/NetworksPage.html shows that dalton > and joule have been performing this function for some time; years > in fact. The question of the previous message about hub or switch > was asked with the intention of adding the specific capability of > transmitting communication of carnot through dalton rather than > through the Allied Telesis 3612TR. There's neither "carnot" nor "Allied Telesis 3612TR" in your provided diagram so it's a bit difficult to follow you. It would be better if you provided a complete an up-to-date diagram. Anyway, I'll try to make use of my crystal ball: * The ISP you connect dalton to has given you control of the public network 142.103.107.128/25 or at least has given you some IP addresses on that range, right? * dalton's eth0 is configured with the public IP 142.103.107.137/25, right? * carnot's eth0 is configured with the public IP 142.103.107.138/25, right? * You expect carnot's eth0 being connected to dalton's eth1 by means of a crossover cable, right? If all my previous assumptions are right, then you need to configure an IP bridge between dalton's eth0 and eth1. That's all. In dalton's /etc/network/interfaces something along the following lines should do the trick (you should delete other ethN stanzas -you'll readd your VPN and other networks later, once you know your bridge is working properly, and you'd better have physical access to dalton since probably you'll need more than a try -oh, and make sure the iproute and bridge-utils packages are installed): auto br0 iface br0 inet static address 142.103.107.137 gateway 142.103.107.254 netmask 255.255.255.128 bridge_ports eth0 eth1 Cheers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009052347.48996.jesus.nava...@undominio.net
Re: Re (2): Linux hub
In <380-22010905162433...@netptc.net>, ow...@netptc.net wrote: >> Original Message >>From: peasth...@shaw.ca >>>From:"PT M." >>>Quoting from http://en.wikipedia.org/wiki/Network_switch, >>>"Switches may operate at one or more OSI layers, including physical, >>>data link, network, or transport (i.e., end-to-end)." > >Lots of terminology confusion. It used to be hubs were at level 1, >switches at level 2, routers at level 3 and gateways above level 3. >Larry That's not quite true; it's never been that clear cut, although some would like to believe that. Hubs are "dumb" devices, almost always implemented entirely in hardware, and as such basically ignored everything above layer 1. Mostly they should be avoided for TCP/IP over Ethernet, since they generate more traffic then required by Ethernet (which is layer 1 and 2). In hubs, the most complex IC would not be complex enough to call a CPU in modern times. Switches are smart devices, but not traditionally programmable. They do use some RAM to store information about seen packets in order to make decisions about future packets. They do not use out-of-band information to make switching decisions. With TCP/IP over Ethernet, they generally operate at layer 2 (Ethernet, which is also layer 1) or 3. Switches that do understand a layer above 2 will generally fall back to layer 2 when encountering a higher layer protocol they do not recognize. Switches generally have a CPU, for handling the configuration interface, which might be extensive, even on layer 2 switches, given all the parts of the Ethernet protocol. However, the hardware is designed so that packets do not have to travel through the CPU bus. Routers are programmable devices. They have detailed configurations plus static routes and routing rules. In addition, they generally use out-of-band information (like BGP etc.) to update their routes and rules in near-real- time. They likely drop data that doesn't correspond to a layer 3 protocol they understand, but could be configured to route it somewhere. They will inspect layer 4 and possibly above data to aid their layer 3 routing. They will certainly have a CPU, but they also have switch-like hardware so that packets do not have to travel through the CPU bus. Even packets that need to travel to the CPU for special processing may be routed but also saved so that traffic doesn't have to wait on the CPU; alternatively there may be specialized processors have more bandwidth then the CPU but much more limited functionality. A PC can pretend to be a router, switch, or even a hub. However, unless it has some fairly specialized hardware, high load will reveal the PC. The main cause of this is saturation of the bus between the network card and the CPU, since all the packets have to flow to the CPU and back. Gateway is a much more generic term, but basically it connects your network with an outside network (or the Internet). It will generally have at least minimal routing capabilities, but it may simply be an intermediary, linking a single switch/router to a single other gateway. However, it may also be a feature-complete router and firewall along with doing layer 5-7 inspection to enforce network policy. For most personal and small business needs, it can simply be a PC; the traffic to outside networks being too constrained to need more bandwidth then is available across a modern PC bus, especially if all that bandwidth is through a single connection to a single ISP at any one time. Once external traffic reaches some level though, you'll need specialized hardware, so your gateway will likely be an "enterprise" router. The specialized hardware that routers need, basically a "programmable" version of the hardware in a switch, was/is one of the main roadblocks on the way to a optical-only Internet backbone. For the longest time, even when the links where optical cable, the routers where traditional electronic devices, so that the signal had to be decoded/encoded from optical to electric to optical which can introduce unnecessary delays. TL;DR: That's an over-simplification or a case of nostalgia. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Re (2): Linux hub
In <171056613.33698.296...@heaviside.invalid>, peasth...@shaw.ca wrote: >A salient detail is that >carnot has a public address whereas a masqueraded machine under >a router typically has a private address. Masquerading is not a required part of routing. While NAT and similar masquerading technologies have become very popular (as we are running out of IPv4 addresses), your average TCP/IP connection will go through more routers that do not masquerade the connection than router that do masquerade the connection. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
RE: Re (2): Linux hub
> > > > Original Message >From: peasth...@shaw.ca >To: debian-user@lists.debian.org >Subject: RE: Re (2): Linux hub >Date: Sun, 5 Sep 2010 08:44:00 -0700 > >>From: "PT M." >>Date: Sun, 05 Sep 2010 13:58:26 +0800 >>> Switch/Hub is not those things and OS thould do, Switch work at >the layer of Link, ... >> >>Quoting from http://en.wikipedia.org/wiki/Network_switch, >>"Switches may operate at one or more OSI layers, including physical, > >>data link, network, or transport (i.e., end-to-end)." >>Also >http://en.wikipedia.org/wiki/Network_switch#Layer-specific_functional >ity . >> >>> http://www.linuxhorizon.ro/bonding.html >> >>Will read. Thanks, ... Peter E. >> >>-- >>VoIP 7785886232 is gone. Please use 13604502132. >>Shop pages http://carnot.yi.org/ accessible as long as the old >>drives survive; installation of netbsd on new drives pending. >>Personal pages, http://members.shaw.ca/peasthope/ . >> >> >>-- >>To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org >>with a subject of "unsubscribe". Trouble? Contact >listmas...@lists.debian.org >>Archive: http://lists.debian.org/171056613.35584.296...@heaviside.in >valid >> Lots of terminology confusion. It used to be hubs were at level 1, switches at level 2, routers at level 3 and gateways above level 3. Larry >> -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/380-22010905162433...@netptc.net
