I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case? deviceA -> ethernet switch -> deviceB ethernet switch -> deviceC with bridged wifi and ethernet question came up in the context of: http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.ht... -- Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi
On Tue, Dec 15, 2015 at 10:48:50AM +0100, Dave Taht wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
deviceA -> ethernet switch -> deviceB ethernet switch -> deviceC with bridged wifi and ethernet
question came up in the context of:
http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.ht...
The best way I've seen is to measure latency to the devices and infer from there. You can always make the latency longer, but making it shorter is much harder :) - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Why do you care if there's a bridge? Seems you care about higher latency, packet loss, lower reliability, etc. Measure what matters and act on that, rather than trying to guess performance from link type. Matthew Kaufman (Sent from my iPhone)
On Dec 15, 2015, at 5:48 AM, Dave Taht <dave.taht@gmail.com> wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
deviceA -> ethernet switch -> deviceB ethernet switch -> deviceC with bridged wifi and ethernet
question came up in the context of:
http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.ht...
-- Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi
Flip a bit in the Ethernet FCS as it egresses deviceA. If the frame arrives with a correct checksum at deviceB, then there's a switch in the middle. Most modern switches recalculate FCS at egress port. If the frame never arrives, most likely there is a switch in between. If the frame arrives with the broken FCS, there is no intermediate switch. --Andrew On 12/15/15 4:48 AM, Dave Taht wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
deviceA -> ethernet switch -> deviceB ethernet switch -> deviceC with bridged wifi and ethernet
question came up in the context of:
http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.ht...
-- Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi
On Tue, Dec 15, 2015 at 4:48 AM, Dave Taht <dave.taht@gmail.com> wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
Hi Dave, Start with precision in language. An ethernet switch is one form of ethernet bridge although the reverse is not necessarily true. So, a switch is always a bridge by definition. Q.E.D.
From what you've posted, you don't want to detect the difference between a switch and a bridge, you want to detect the difference between a wired and wireless segment segment in the network. Is that correct? Any wireless link or just radio? Any radio link or just 802.11 wifi? Are you just trying to detect stations behind wireless or do you want to identify segments that are carried over wireless?
Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Tue, Dec 15, 2015 at 4:19 PM, William Herrin <bill@herrin.us> wrote:
On Tue, Dec 15, 2015 at 4:48 AM, Dave Taht <dave.taht@gmail.com> wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
Hi Dave,
Start with precision in language. An ethernet switch is one form of ethernet bridge although the reverse is not necessarily true. So, a switch is always a bridge by definition. Q.E.D.
Sure.
From what you've posted, you don't want to detect the difference between a switch and a bridge, you want to detect the difference
To be more clear I wanted to detect if there was more than one bridge on the network, where the bridge being a PITA was a wired/wireless bridge.
between a wired and wireless segment segment in the network. Is that correct? Any wireless link or just radio? Any radio link or just 802.11 wifi?
I believe the radios in this case were probably ubnt. https://nodes.wlan-si.net/network/statistics/
Are you just trying to detect stations behind wireless or do you want to identify segments that are carried over wireless?
The latter. In this case a routing optimization that works well on wired links was enabled when there were wireless bridges on that segment, leading to some chaos in the originally referenced thread. The "right", slower, inefficient on wired, routing metric is the ETX metric in that case, but knowing when to turn that on, automatically, would be nice... which means somehow detecting there was a wireless bridge on that network. So as no announcements of BPDUs are seen, I was hoping there was some sort of active query that could be made asking if there was anything weird and wireless nearby..... https://nodes.wlan-si.net/topology/
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Dave Taht Sent: Wednesday, December 16, 2015 4:37 AM To: William Herrin <bill@herrin.us> Cc: NANOG <nanog@nanog.org> Subject: Re: reliably detecting the presence of a bridge? The latter. In this case a routing optimization that works well on wired links was enabled when there were wireless bridges on that segment, leading to some chaos in the originally referenced thread. The "right", slower, inefficient on wired, routing metric is the ETX metric in that case, but knowing when to turn that on, automatically, would be nice... which means somehow detecting there was a wireless bridge on that network. So as no announcements of BPDUs are seen, I was hoping there was some sort of active query that could be made asking if there was anything weird and wireless nearby..... https://nodes.wlan-si.net/topology/ ---------------------------------------------------------------------------- Seems there are two possible ways to attach wireless clients to a wired network (at least 2 common ways). A consumer-grade wireless router doing NAT, or a true layer 2 AP. Assuming neither are sending BPDUs, there are a few ways to detect them I can think of, assuming you've got control of the switch they're attached to: Wireless AP (L2 only) - port security limiting number of learnable MAC address per port is pretty easy. In the case of UBNT you mentioned, it's even easier. They use a discovery protocol (multicast I believe) and have CDP, both on by default. NATing router - a little tougher to do. Scanning your DCHP database or ARP/MAC tables for OUI that shouldn't be on the network - Linksys, D-Link, Netgear etc. Or perhaps occasionally port-scan your network looking for open TCP/8080, I think that's the most common port for managing these. They may not respond on the WAN side if configured right, but the old default was on. NMAP and its fingerprinting might come in handy too, if they're turned off access from the WAN side. Chuck
If LLDP (link layer discovery protocol) is enabled, you could try using that. There is a system capabilities TLV in the LLDPDU sent by a system, but I'm not sure how reliably it is filled in, especially if a device is capable of both switching and routing. The way LLDP is supposed to work is a device will receive LLDPDUs from other devices immediately adjacent to it. It can then read the LLDP database of those devices (via management) and figure out what those devices are connected to, and so on. Otherwise, bridges are supposed to be "transparent," so there is no way to know they are present by using user data frames. Anoop
In the end, there seems to be no "reliable" way to ask the network my question. But... WOW! Thank you all for your interesting and clever techniques!
On Wed, Dec 16, 2015 at 4:36 AM, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Dec 15, 2015 at 4:19 PM, William Herrin <bill@herrin.us> wrote:
From what you've posted, you don't want to detect the difference between a switch and a bridge, you want to detect the difference
To be more clear I wanted to detect if there was more than one bridge on the network, where the bridge being a PITA was a wired/wireless bridge.
Hi Dave, I recommend you stop using the word "bridge." I think see where you're heading with it, but I think you're chasing a blind alley which encourages a false mental model of how layer 2 networks function. You came here for answers. This is one of them. "Bridge" describes a device which existed in layer 2 networks a quarter century ago. You had a 10-base2 ethernet with every station connected to a shared coax wire. Or you had a token ring where each station was wired to the next station in a loop. Or if you were sophisticated you had 10-baseT with a hub that repeated bits from any port to all ports with no concept of packets. And then you had a bridge which could connect these networks together, buffering complete packets and smartly repeating only the packets which belong on the other side. The bridge let you expand past the distance limitations imposed by the ethernet collision domain, and it let you move between two different speed networks. These networks are now largely a historical curiousity. There are no hubs, no 10-base2, no token passing rings. Not any more. Individual stations now connect directly to a bridge device, which these days we often call a "switch." Even where the stations have a shared media (e.g. 802.11), the stations talk to the bridge, not to each other. Bridge specifies a condition that, today, is close enough to always true as makes no difference.
Are you just trying to detect stations behind wireless or do you want to identify segments that are carried over wireless?
The latter.
In this case a routing optimization that works well on wired links was enabled when there were wireless bridges on that segment, leading to some chaos in the originally referenced thread.
The short answer to your question is: No, there is no reliable way for software operating at layer 3 to determine that it's working across links which contain wired or wireless. The longer answer is that you may be asking the wrong question. Layer 2 links transit different kinds of media. Copper. Fiber. Radio. Laser. Sometimes they travel virtual medias where the underlying technologies are deliberately hidden. VPNs. MPLS. Sometimes it starts copper, transits a media converter and ends up fiber. The media types do not, in and of themselves, make much difference with respect to optimizing layer-3 traffic flows. Capacity Loss Latency Jitter These are the factors which matter. A full duplex licensed radio link will tend to have exactly the same characteristics as a copper ethernet across the same distance. An 802.11 radio link will not -- 802.11 is half duplex with retransmission. It will tend to exhibit much higher jitter than the licensed radio link and has a true capacity limit far below the data rate. The layer 2 media type is not known at layer 3. Optimizing for media type is probably barking up the wrong tree anyway. Optimize for the network characteristics which matter. Capacity Loss Latency Jitter These are the things you want to detect and optimize for. Favor higher capacity links. Avoid loss like the plague. Favor low latency. Prefer low jitter. If a link isn't too full and isn't suffering high jitter, you can often estimate capacity by sending some small pings and some large pings and measuring the difference in round-trip latency. But this doesn't work if the link is comprised of parallel paths -- you'll get the capacity of a single path instead of the total capacity. For example, a 128kbps ISDN BRI running multilink PPP will detect as 64kbps. And it doesn't work with half duplex paths where capacity is a stochastic function based on the number of colliding speakers. Loss is the deadly one. Packet loss above a fractional percent kills TCP/IP pretty fast. Detecting it is highly situational. In principle your routers could keep track of packet counts sent and received from each neighbor and communicate them with each other. Then alter the base link metric depending on differences in the counts. I haven't seen this done anywhere though. Except on point to point links the router generally doesn't know or track which neighbor sent which packet. Latency (delay) changes with distance and buffering. Can't really tell the difference between the two from layer 3. Can't measure latency without actively polliing, which consumes capacity. And high jitter renders latency measurements unreliable. Jitter is the degree to which latency changes from packet to packet. Links operating near capacity will express higher jitter as some packets are buffered and some aren't. Links with an underlying error detection and retransmission mechanism (like 802.11) will express higher jitter. Half duplex links with collision avoidance or collision detection (802.11 or old-school 10-baseT) will express higher jitter as packets from simultaneously transmitting stations collide and are delayed with a backoff before retransmission. Jitter can be measured on a link, but it can't be predicted. Once measured, you can't know the cause: whether it's a full duplex link running near capacity or a half duplex link that occasionally has other stations speaking. Which makes it hard to predict whether and how often the jitter will recur. Anyway, the bottom line is that you only think you care whether a link is wired or wireless. What you *really* care about is: Capacity Loss Latency Jitter Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 12/19/2015 12:17, William Herrin wrote: [snip]
I recommend you stop using the word "bridge." I think see where you're heading with it, but I think you're chasing a blind alley which encourages a false mental model of how layer 2 networks function. You came here for answers. This is one of them.
"Bridge" describes a device which existed in layer 2 networks a quarter century ago. You had a 10-base2 ethernet with every station connected to a shared coax wire. Or you had a token ring where each station was wired to the next station in a loop. Or if you were sophisticated you had 10-baseT with a hub that repeated bits from any port to all ports with no concept of packets.
And then you had a bridge which could connect these networks together, buffering complete packets and smartly repeating only the packets which belong on the other side. The bridge let you expand past the distance limitations imposed by the ethernet collision domain, and it let you move between two different speed networks.
These networks are now largely a historical curiousity. There are no hubs, no 10-base2, no token passing rings. Not any more. Individual stations now connect directly to a bridge device, which these days we often call a "switch." Even where the stations have a shared media (e.g. 802.11), the stations talk to the bridge, not to each other.
Bridge specifies a condition that, today, is close enough to always true as makes no difference.
Super explanation. But I still have one question (which might be based on errors)-- I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals. Are they operating as a Radia Perlman "bridge", or is this yet another example if the Wiffy World high-jacking words and terms that used to have actual meanings? Nice write-up, even though it is sort of sad to be confronted with the fact that my experience and knowledge with hose-connected (10base5. 10base2) or token-ring networks, and hubs, and stuff is now without value. That is the very worst part of getting old. Next objective: Somebody to 'splain at what happened to the wonderfulness of the OSI model where layer X did not know, could not know, did not care what layer X-1 was, did, or how it did it. -- sed quis custodiet ipsos custodes? (Juvenal)
I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals.
The ones I've seen Normally those things are routers, typically with NAT on the wifi side. If you put it in bridge mode it is indeed a bridge, passing the packets back and forth without messing with them. Depending on which way you set them up, it might be a wireless link between two wired networks, or an extra access point with the wire running back to the router.
Next objective: Somebody to 'splain at what happened to the wonderfulness of the OSI model where layer X did not know, could not know, did not care what layer X-1 was, did, or how it did it.
It never actually existed. If you built your network that way, passing each packet up and down six or seven layers, it would have been absurdly slow. In reality the layers only happen in places where you can plug in multiple things at one layer, e.g., different physical connections underneath your IP layer. R's, John
On Dec 19, 2015, at 4:53 PM, Larry Sheldon <larrysheldon@cox.net> wrote:
On 12/19/2015 12:17, William Herrin wrote:
[snip]
I recommend you stop using the word "bridge." I think see where you're heading with it, but I think you're chasing a blind alley which encourages a false mental model of how layer 2 networks function. You came here for answers. This is one of them.
"Bridge" describes a device which existed in layer 2 networks a quarter century ago. You had a 10-base2 ethernet with every station connected to a shared coax wire. Or you had a token ring where each station was wired to the next station in a loop. Or if you were sophisticated you had 10-baseT with a hub that repeated bits from any port to all ports with no concept of packets.
And then you had a bridge which could connect these networks together, buffering complete packets and smartly repeating only the packets which belong on the other side. The bridge let you expand past the distance limitations imposed by the ethernet collision domain, and it let you move between two different speed networks.
These networks are now largely a historical curiousity. There are no hubs, no 10-base2, no token passing rings. Not any more. Individual stations now connect directly to a bridge device, which these days we often call a "switch." Even where the stations have a shared media (e.g. 802.11), the stations talk to the bridge, not to each other.
Bridge specifies a condition that, today, is close enough to always true as makes no difference.
Super explanation.
But I still have one question (which might be based on errors)--
I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals.
Are they operating as a Radia Perlman "bridge", or is this yet another example if the Wiffy World high-jacking words and terms that used to have actual meanings?
Bridge Mode (ATT Passthrough) simply means that the router between the WAN connection and the LAN/WiFi ports is turned off and all ports share the same switch (so packets just “pass through”. Thus all ports appear connected to a common switch. Call that what you will, there is no spanning tree here even though we all love Radia.
Nice write-up, even though it is sort of sad to be confronted with the fact that my experience and knowledge with hose-connected (10base5. 10base2) or token-ring networks, and hubs, and stuff is now without value. That is the very worst part of getting old.
Next objective: Somebody to 'splain at what happened to the wonderfulness of the OSI model where layer X did not know, could not know, did not care what layer X-1 was, did, or how it did it.
The TCP/IP suite was “free” and essentially drove IPX/SPX, DECNet, AppleTalk, and SNA out of any large market. Digital Equipment Corporation, for example, viewed DECnet networking as a profit center rather than a sales enabler for their hardware and software. And nobody wanted to spend the probably very large cost to remove what was essentially network code from applications. This is why almost every application existing need (still needs) modification just to accommodate larger address integers and a different display mechanism for addresses .
-- sed quis custodiet ipsos custodes? (Juvenal)
Nobody.
On 12/19/2015 16:53, James R Cutler wrote: [snip]
But I still have one question (which might be based on errors)--
I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals.
Are they operating as a Radia Perlman "bridge", or is this yet another example if the Wiffy World high-jacking words and terms that used to have actual meanings?
Bridge Mode (ATT Passthrough) simply means that the router between the WAN connection and the LAN/WiFi ports is turned off and all ports share the same switch (so packets just “pass through”. Thus all ports appear connected to a common switch. Call that what you will, there is no spanning tree here even though we all love Radia.
I have three radios in my little toy network (two because the original installation was in a big house that had annoying dead spots with only one, one because I had to replace the router and the router replacement included a radio). I just looked at one (I'm pretty sure the others are similar of the same) that has a pick fir "AP Mode" which offers "Access Point (default) which is what I run, "AP Client", "Wireless Repeater" and "Wireless Bridge". I just realized that I don't know (or don't remember--I am old) what the documentation says (see--I am so old I think there IS documentation and that it WILL explain stuff.)
-- sed quis custodiet ipsos custodes? (Juvenal)
Nobody.
Heh -- sed quis custodiet ipsos custodes? (Juvenal)
On 12/19/2015 17:15, Larry Sheldon wrote:
On 12/19/2015 16:53, James R Cutler wrote:
[snip]
But I still have one question (which might be based on errors)--
I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that offer a "bridge" mode, apparently to build a dedicated radio link between two such terminals.
Are they operating as a Radia Perlman "bridge", or is this yet another example if the Wiffy World high-jacking words and terms that used to have actual meanings?
Bridge Mode (ATT Passthrough) simply means that the router between the WAN connection and the LAN/WiFi ports is turned off and all ports share the same switch (so packets just “pass through”. Thus all ports appear connected to a common switch. Call that what you will, there is no spanning tree here even though we all love Radia.
I have three radios in my little toy network (two because the original installation was in a big house that had annoying dead spots with only one, one because I had to replace the router and the router replacement included a radio).
I just looked at one (I'm pretty sure the others are similar of the same) that has a pick for "AP Mode" which offers "Access Point (default) which is what I run, "AP Client", "Wireless Repeater" and "Wireless Bridge".
I did not make it clear--this on is by no means a router--it has two interfaces, 10baseT, and radio.
I just realized that I don't know (or don't remember--I am old) what the documentation says (see--I am so old I think there IS documentation and that it WILL explain stuff.)
I did look it up, and now don't know as much as I did. -- sed quis custodiet ipsos custodes? (Juvenal)
On Tue, 15 Dec 2015, Dave Taht wrote:
I am curious if there is some sort of igmp or other form of message that would reliably detect if a switch had a bridge on it. How could deviceA detect deviceC was a bridge in this case?
deviceA -> ethernet switch -> deviceB ethernet switch -> deviceC with bridged wifi and ethernet
question came up in the context of:
http://lists.alioth.debian.org/pipermail/babel-users/2015-December/002231.ht...
It seems that the goal here is to find out if there is some kind of L2 device that bridges to a medium that uses retransmits to handle that it's not natively up to the 10^-12 BER that wired ethernet adheres to and that might have variable transfer speeds and might stall due to adverse conditions from time to time? I would say no, there is no simple way of doing that. You can heuristically detect if multiple parties on the LAN participates and if you're willing to send probe packets to see if there is a mac-learning device in the middle, but it's hard to determine if this just a regular wired ethernet switch or if it uses some other medium. Easiest way for babel is most likely to do the link quality detection on all mediums, or at least do it as soon as there has been some packet loss seen. If the devices are willing to time stamp the packets and they check that the RTT between the devices is always sub-1ms, then that's a decent indicator that the link is high speed and wired, and if it's over 1ms, it's time to start running the link quality estimation algorithm. Facing bufferbloat so that link is over 1ms RTT, you probably want to link-estimate it anyway... -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (12)
-
Andrew McConachie -
Anoop Ghanwani -
Chuck Church -
Dave Taht -
James R Cutler -
Jared Mauch -
John Levine -
Larry Sheldon -
Masataka Ohta -
Matthew Kaufman -
Mikael Abrahamsson -
William Herrin