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.html
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
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
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
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
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.....
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...
Dave Taht wrote:
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.
Listen to spanning tree protocol.
Masataka Ohta
[Dave asked me to repost this to the list -- not sure how useful this
little lead is; haven't worked on this for more than half a decade.]
I don't have a good platform to test this on today, but one way to
detect a wireless bridge a couple of years ago was to send a SNAP packet
(actually anything with an Ethernet length -- as opposed to ethertype --
in it) that is shorter than Ethernet minimum length (14 + 46), and then
see whether the padding you put in on one end survives over to the other
end. That of course only works with bridges that actually optimize this
case (plus you can detect those that completely mess up this case --
there are quite a few of those).
Hope that helps; would need to do experiments with real hardware to say
anything more substantive.
Grüße, Carsten
PS.: In case you wonder what the work was that led to this observation:
https://tools.ietf.org/html/draft-bormann-rohc-over-802-02
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.....
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!
From what you've posted, you don't want to detect the difference
between a switch and a bridge, you want to detect the differenceTo 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
[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.
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
[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.
[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
[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.