Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Linksys Velop system in bridge mode (connected to NAT router by Ethernet) doesn't give info on which nodes are/aren't connected to each other
1,898 views
Skip to first unread message
NY
Feb 14, 2022, 11:20:22 AM2/14/22
to
I used to have my Linksys Velop nodes configured as Automatic DHCP,
connected by Ethernet to a router which was acting as an ordinary NAT/DHCP
router. To avoid double-NAT problems, I've now put the Velop system into
bridge mode which turns off its NAT and DHCP, with those functions being
performed only by the router (a TPlink TD9980).
Everything appeared to be working fine, but I notice that nodes which used
to connect to each other now have to be turned on one at a time, when (with
a couple of exceptions) the same nodes in the same locations used to connect
automatically if the system was rebooted or all the nodes turned on at the
same time after a power cut. Also, the Linksys app, talking to the Velop
network, does not give "disconnected" indications for other nodes so there
is no easy way to tell whether a node has gone offline, other than by
walking around and looking at the lights - or waiting for people to say
"there isn't a good signal in this room".
This came to light because I accidentally turned the router off (I dislodged
its PSU from the wall socket) and so the Velop had nothing to talk to. All
the nodes had then gone into flashing-red-light mode and simply rebooting
the primary node did not fix it.
Does bridge mode affect the ability of nodes to talk to each other and to
handle the common situation where the nodes are positioned far enough away
that they are close to the limit of 5 GHz connectivity, which means that
there is a lot of overlap of 2.4 GHz and therefore competition for free
channels. It's a crying shame that the Velop nodes can't have 2.4 turned on
*selectively* so it's only on for the nodes which have devices nearby that
cannot talk 5 GHz.
connected by Ethernet to a router which was acting as an ordinary NAT/DHCP
router. To avoid double-NAT problems, I've now put the Velop system into
bridge mode which turns off its NAT and DHCP, with those functions being
performed only by the router (a TPlink TD9980).
Everything appeared to be working fine, but I notice that nodes which used
to connect to each other now have to be turned on one at a time, when (with
a couple of exceptions) the same nodes in the same locations used to connect
automatically if the system was rebooted or all the nodes turned on at the
same time after a power cut. Also, the Linksys app, talking to the Velop
network, does not give "disconnected" indications for other nodes so there
is no easy way to tell whether a node has gone offline, other than by
walking around and looking at the lights - or waiting for people to say
"there isn't a good signal in this room".
This came to light because I accidentally turned the router off (I dislodged
its PSU from the wall socket) and so the Velop had nothing to talk to. All
the nodes had then gone into flashing-red-light mode and simply rebooting
the primary node did not fix it.
Does bridge mode affect the ability of nodes to talk to each other and to
handle the common situation where the nodes are positioned far enough away
that they are close to the limit of 5 GHz connectivity, which means that
there is a lot of overlap of 2.4 GHz and therefore competition for free
channels. It's a crying shame that the Velop nodes can't have 2.4 turned on
*selectively* so it's only on for the nodes which have devices nearby that
cannot talk 5 GHz.
Theo
Feb 14, 2022, 11:45:51 AM2/14/22
to
NY <m...@privacy.invalid> wrote:
> Does bridge mode affect the ability of nodes to talk to each other and to
> handle the common situation where the nodes are positioned far enough away
> that they are close to the limit of 5 GHz connectivity, which means that
> there is a lot of overlap of 2.4 GHz and therefore competition for free
> channels. It's a crying shame that the Velop nodes can't have 2.4 turned on
> *selectively* so it's only on for the nodes which have devices nearby that
> cannot talk 5 GHz.
I have no idea about Velops, but are you by any chance using the same SSID
> Does bridge mode affect the ability of nodes to talk to each other and to
> handle the common situation where the nodes are positioned far enough away
> that they are close to the limit of 5 GHz connectivity, which means that
> there is a lot of overlap of 2.4 GHz and therefore competition for free
> channels. It's a crying shame that the Velop nodes can't have 2.4 turned on
> *selectively* so it's only on for the nodes which have devices nearby that
> cannot talk 5 GHz.
on the Velops as on the router, with the Velop plugged into the router?
That could be the source of nodes 'roaming' from Velop to router or vice
versa, eg if they drop off Velop and reattach to the same SSID on the
router, or fall off 5G and find 2.4G instead. Also if you have different
SSIDs but devices know about both of them.
The reason is that, as far as the router is concerned, devices are swapping
from internal wifi to the Velop's ethernet port - this can cause troubles if
the router isn't OK with this.
Theo
Tweed
Feb 14, 2022, 12:50:35 PM2/14/22
to
use wired Ethernet backhaul) because they use a private 5 GHz link between
each other to establish the mesh.
You can separately name the 5 and 2.4 GHz networks with different SSIDs. I
do this, so for example, my iPad isn’t registered with the 2.4 GHz network
and is thus forced to use the 5 GHz signal.
Chris Green
Feb 14, 2022, 1:48:04 PM2/14/22
to
Tweed <usenet...@gmail.com> wrote:
>
> Your nodes should always be in good 5 GHz range of each other (unless you
> use wired Ethernet backhaul) because they use a private 5 GHz link between
> each other to establish the mesh.
>
I have to say that this is what puts me off wireless connected mesh
>
> Your nodes should always be in good 5 GHz range of each other (unless you
> use wired Ethernet backhaul) because they use a private 5 GHz link between
> each other to establish the mesh.
>
systems. 5Ghz works so awfully in our house that I'd need a mesh node
in every room to get a half decent system. Since we have a rambling
six bedroom house this would be rather expensive!
--
Chris Green
·
NY
Feb 14, 2022, 3:20:33 PM2/14/22
to
"Theo" <theom...@chiark.greenend.org.uk> wrote in message
news:J7i*oh...@news.chiark.greenend.org.uk...
No, the Velop and router SSIDs are similar but different. And the router
SSID can be turned off because it's not needed: I only had it on (5 GHZ
only) while testing in case I needed to connect directly to the router
before I had the Velop system running.
news:J7i*oh...@news.chiark.greenend.org.uk...
SSID can be turned off because it's not needed: I only had it on (5 GHZ
only) while testing in case I needed to connect directly to the router
before I had the Velop system running.
Tweed
Feb 14, 2022, 3:50:49 PM2/14/22
to
NY <m...@privacy.invalid> wrote:
> "Chris Green" <c...@isbd.net> wrote in message
> news:bfkqdi-...@esprimo.zbmc.eu...
> Join the club: part of our house dates from 1800s and has very thick walls
> both inside and out, the rest of the house is 1990s and is normal brick
> cavity wall outside and plasterboard stud internal. It has three different
> loft spaces which have internal brick dividing walls that I'd need to drill
> through if I wanted to pass a Cat 6 cable and RJ45 plug. And then I'd have
> the problem of getting the Cat 6 down into the rooms to connect to mesh
> nodes or wifi access points - or else of getting mains into the loft if I
> put the nodes up there (which makes them very difficult to get to...).
> There's also the problem that one of the loft spaces has an Alice in
> Wonderland door that is only just big enough for me to wriggle through by
> squeezing my shoulders in. I can't think why the builders didn't make it 6"
> wider and higher.
>
> I've attached an SVG floorplan of the house (I drew it as a "class exercise"
> when teaching myself Inkscape) with the Primary and Secondary Velops marked
> (note that the first floor is above bedrooms 2 and 3 of the ground floor).
> All the Secondaries seemed to manage to talk directly to the Primary apart
> from the one in the garage which talked to the conservatory, and the kitchen
> one which sometimes connected to bedroom 3 rather than Primary because the
> lounge/dining and dining/kitchen walls block a good line of sight. All
> windows are modern double-glazed which *may* have a heat-reflecting coating
> that could attenuate signals a bit.
>
>
> We initially bought a 3-pack of Velop nodes and then found that they needed
> to be much closer than anticipated for them to have decent 5 GHz backhaul
> comms, so we needed another 3-pack. I feel very embarrassed that we have
> completely filled the 2.4 GHz spectrum. Luckily we are about 100 m from the
> houses on either side so there is scope for inverse-square law to apply ;-)
>
>
>
I’m afraid your attachment didn’t attach. (Text only news group)
If your house is like most in the UK and has a suspended wooden floor for
the upstairs rooms use this to your advantage. Such floors are mainly
transparent to 5 GHz. So illuminate the ground floor rooms from above.
There tends to be thinner walls upstairs, so joining the units on the first
floor is often easier.
I have K glass double glazing - it’s transparent to 5 GHz. However the
frames, which contain metal are not. Standing the Velop on a small box on
the window sill to give it a bit of height above the frame makes a huge
difference.
> "Chris Green" <c...@isbd.net> wrote in message
> news:bfkqdi-...@esprimo.zbmc.eu...
> both inside and out, the rest of the house is 1990s and is normal brick
> cavity wall outside and plasterboard stud internal. It has three different
> loft spaces which have internal brick dividing walls that I'd need to drill
> through if I wanted to pass a Cat 6 cable and RJ45 plug. And then I'd have
> the problem of getting the Cat 6 down into the rooms to connect to mesh
> nodes or wifi access points - or else of getting mains into the loft if I
> put the nodes up there (which makes them very difficult to get to...).
> There's also the problem that one of the loft spaces has an Alice in
> Wonderland door that is only just big enough for me to wriggle through by
> squeezing my shoulders in. I can't think why the builders didn't make it 6"
> wider and higher.
>
> I've attached an SVG floorplan of the house (I drew it as a "class exercise"
> when teaching myself Inkscape) with the Primary and Secondary Velops marked
> (note that the first floor is above bedrooms 2 and 3 of the ground floor).
> All the Secondaries seemed to manage to talk directly to the Primary apart
> from the one in the garage which talked to the conservatory, and the kitchen
> one which sometimes connected to bedroom 3 rather than Primary because the
> lounge/dining and dining/kitchen walls block a good line of sight. All
> windows are modern double-glazed which *may* have a heat-reflecting coating
> that could attenuate signals a bit.
>
>
> We initially bought a 3-pack of Velop nodes and then found that they needed
> to be much closer than anticipated for them to have decent 5 GHz backhaul
> comms, so we needed another 3-pack. I feel very embarrassed that we have
> completely filled the 2.4 GHz spectrum. Luckily we are about 100 m from the
> houses on either side so there is scope for inverse-square law to apply ;-)
>
>
>
I’m afraid your attachment didn’t attach. (Text only news group)
If your house is like most in the UK and has a suspended wooden floor for
the upstairs rooms use this to your advantage. Such floors are mainly
transparent to 5 GHz. So illuminate the ground floor rooms from above.
There tends to be thinner walls upstairs, so joining the units on the first
floor is often easier.
I have K glass double glazing - it’s transparent to 5 GHz. However the
frames, which contain metal are not. Standing the Velop on a small box on
the window sill to give it a bit of height above the frame makes a huge
difference.
Andy Burns
Feb 14, 2022, 3:53:22 PM2/14/22
to
Tweed wrote:
> I’m afraid your attachment didn’t attach. (Text only news group)
It managed to sneak through on NIN, and was even shown directly in-place
> I’m afraid your attachment didn’t attach. (Text only news group)
thunderbird.
Graham J
Feb 14, 2022, 3:54:04 PM2/14/22
to
NY wrote:
> I used to have my Linksys Velop nodes configured as Automatic DHCP,
> connected by Ethernet to a router which was acting as an ordinary
> NAT/DHCP router. To avoid double-NAT problems, I've now put the Velop
> system into bridge mode which turns off its NAT and DHCP, with those
> functions being performed only by the router (a TPlink TD9980).
>
>
> Everything appeared to be working fine, but I notice that nodes which
> used to connect to each other now have to be turned on one at a time,
> when (with a couple of exceptions) the same nodes in the same locations
> used to connect automatically if the system was rebooted or all the
> nodes turned on at the same time after a power cut. Also, the Linksys
> app, talking to the Velop network, does not give "disconnected"
> indications for other nodes so there is no easy way to tell whether a
> node has gone offline, other than by walking around and looking at the
> lights - or waiting for people to say "there isn't a good signal in this
> room".
I suspect this is a limitation (feature!) of the Velop system.
> I used to have my Linksys Velop nodes configured as Automatic DHCP,
> connected by Ethernet to a router which was acting as an ordinary
> NAT/DHCP router. To avoid double-NAT problems, I've now put the Velop
> system into bridge mode which turns off its NAT and DHCP, with those
> functions being performed only by the router (a TPlink TD9980).
>
>
> Everything appeared to be working fine, but I notice that nodes which
> used to connect to each other now have to be turned on one at a time,
> when (with a couple of exceptions) the same nodes in the same locations
> used to connect automatically if the system was rebooted or all the
> nodes turned on at the same time after a power cut. Also, the Linksys
> app, talking to the Velop network, does not give "disconnected"
> indications for other nodes so there is no easy way to tell whether a
> node has gone offline, other than by walking around and looking at the
> lights - or waiting for people to say "there isn't a good signal in this
> room".
Were you able to resolve the difficutly with using the Velop as an
Ethernet router, and the TPlink TD9980 as a modem? I suggested in my
reply to you on 13/02/2022, 09:10 that your problem as reported on
12/02/2022, 19:07 was that you had VLAN ID (101) set in the PPPoE page
for the Velop, whenI think that VLAN ID (101) is only required in the
modem (the TPlink TD9980).
Did you try removing VLAN ID (101) from the Velop?
--
Graham J
Tweed
Feb 14, 2022, 4:11:42 PM2/14/22
to
other node they are connected to. Admittedly it doesn’t show offline nodes,
but you can deduce the offline ones by noting that they aren’t listed.
There’s no need to go round looking at the lights.
Chris Green
Feb 14, 2022, 5:18:03 PM2/14/22
to
Tweed <usenet...@gmail.com> wrote:
>
> If your house is like most in the UK and has a suspended wooden floor for
> the upstairs rooms use this to your advantage. Such floors are mainly
> transparent to 5 GHz. So illuminate the ground floor rooms from above.
> There tends to be thinner walls upstairs, so joining the units on the first
> floor is often easier.
>
Well it's not what I see. I'm currently in our lounge, line of sight
>
> If your house is like most in the UK and has a suspended wooden floor for
> the upstairs rooms use this to your advantage. Such floors are mainly
> transparent to 5 GHz. So illuminate the ground floor rooms from above.
> There tends to be thinner walls upstairs, so joining the units on the first
> floor is often easier.
>
to the wooden floor above which is my study where there is a Draytek
Vigor 2860n+ router. The 2.4Ghz connection from it gives 144Mb/s, the
5Ghz connection is 120Mb/s.
--
Chris Green
·
Tweed
Feb 15, 2022, 1:58:29 AM2/15/22
to
currently sitting gives me the full 200 Mbit/sec of my Virgin Media cable
connection on 5GHz.
Chris Green
Feb 15, 2022, 4:03:04 AM2/15/22
to
connection speed. I'm on VDSL so the 'outside world' is only 80Mb/s.
If I connect to a very close 5Ghz router (just trying now) I get
300Mb/s, same as 2.4Ghz to the same router. I.e. nothing at all to do
with my VDSL speed.
What does 2.4Ghz give you to your Velop in the same location? ... or
can't you force use of 2,4Ghz?
--
Chris Green
·
NY
Feb 15, 2022, 4:09:08 AM2/15/22
to
"Tweed" <usenet...@gmail.com> wrote in message
news:suefb7$371$1...@dont-email.me...
would get stripped off.
I've uploaded a PNG version of it
https://i.postimg.cc/B6C6XyL1/house-with-Velop-nodes.png
> If your house is like most in the UK and has a suspended wooden floor for
> the upstairs rooms use this to your advantage. Such floors are mainly
> transparent to 5 GHz. So illuminate the ground floor rooms from above.
> There tends to be thinner walls upstairs, so joining the units on the
> first
> floor is often easier.
>
> I have K glass double glazing - it’s transparent to 5 GHz. However the
> frames, which contain metal are not. Standing the Velop on a small box on
> the window sill to give it a bit of height above the frame makes a huge
> difference.
Yes I've got all the Velops very close to window frames and standing on
books/boxes to make sure the node is above the level of the frame. I was
concerned when we first moved here because all the windows have inserts
between the two layers of glass to make them look like very old small-pane
windows - but those inserts turned out to be plastic rather than metal so
won't have any effect on 2.4 or 5 GHz.
news:suefb7$371$1...@dont-email.me...
>> I've attached an SVG floorplan of the house
> I’m afraid your attachment didn’t attach. (Text only news group)
Grr. I'd seen it attached to the message in the outbox and forgot that it
would get stripped off.
I've uploaded a PNG version of it
https://i.postimg.cc/B6C6XyL1/house-with-Velop-nodes.png
> If your house is like most in the UK and has a suspended wooden floor for
> the upstairs rooms use this to your advantage. Such floors are mainly
> transparent to 5 GHz. So illuminate the ground floor rooms from above.
> There tends to be thinner walls upstairs, so joining the units on the
> first
> floor is often easier.
>
> I have K glass double glazing - it’s transparent to 5 GHz. However the
> frames, which contain metal are not. Standing the Velop on a small box on
> the window sill to give it a bit of height above the frame makes a huge
> difference.
books/boxes to make sure the node is above the level of the frame. I was
concerned when we first moved here because all the windows have inserts
between the two layers of glass to make them look like very old small-pane
windows - but those inserts turned out to be plastic rather than metal so
won't have any effect on 2.4 or 5 GHz.
NY
Feb 15, 2022, 4:18:34 AM2/15/22
to
"Graham J" <nob...@nowhere.co.uk> wrote in message
news:suefha$70t$1...@dont-email.me...
I'd already set up the Velop and router as Velop=bridge and router=NAT/DHCP
by the time I saw all the answers. If I have problems with this set up, I'll
try reversing things and make the Velop the NAT/DHCP and the router into a
modem.
I thought I was being correct in transcribing all the settings - including
the VLAN ID - that had been on the router (when it was in NAT/DHCP mode)
onto the Velop to pass to the router acting as a modem. But it sounds as if
I should have left that field blank on the Velop and let the router (as
modem) work out the value for itself.
news:suefha$70t$1...@dont-email.me...
by the time I saw all the answers. If I have problems with this set up, I'll
try reversing things and make the Velop the NAT/DHCP and the router into a
modem.
I thought I was being correct in transcribing all the settings - including
the VLAN ID - that had been on the router (when it was in NAT/DHCP mode)
onto the Velop to pass to the router acting as a modem. But it sounds as if
I should have left that field blank on the Velop and let the router (as
modem) work out the value for itself.
NY
Feb 15, 2022, 4:18:34 AM2/15/22
to
"Tweed" <usenet...@gmail.com> wrote in message
news:suegic$q8u$1...@dont-email.me...
>> NY wrote:
>>> Everything appeared to be working fine, but I notice that nodes which
>>> used to connect to each other now have to be turned on one at a time,
>>> when (with a couple of exceptions) the same nodes in the same locations
>>> used to connect automatically if the system was rebooted or all the
>>> nodes turned on at the same time after a power cut. Also, the Linksys
>>> app, talking to the Velop network, does not give "disconnected"
>>> indications for other nodes so there is no easy way to tell whether a
>>> node has gone offline, other than by walking around and looking at the
>>> lights - or waiting for people to say "there isn't a good signal in this
>>> room".
>>> Everything appeared to be working fine, but I notice that nodes which
>>> used to connect to each other now have to be turned on one at a time,
>>> when (with a couple of exceptions) the same nodes in the same locations
>>> used to connect automatically if the system was rebooted or all the
>>> nodes turned on at the same time after a power cut. Also, the Linksys
>>> app, talking to the Velop network, does not give "disconnected"
>>> indications for other nodes so there is no easy way to tell whether a
>>> node has gone offline, other than by walking around and looking at the
>>> lights - or waiting for people to say "there isn't a good signal in this
>>> room".
> My Linksys app shows me the nodes that are online, and also shows what
> other node they are connected to. Admittedly it doesn’t show offline
> nodes,
> but you can deduce the offline ones by noting that they aren’t listed.
> There’s no need to go round looking at the lights.
This is very weird. When I looked yesterday when the light on every node had
> other node they are connected to. Admittedly it doesn’t show offline
> nodes,
> but you can deduce the offline ones by noting that they aren’t listed.
> There’s no need to go round looking at the lights.
turned red, the app was not displaying "node disconnected" messages. Once
I'd got things working, each node did not display the "connected to <primary
node>" message at the bottom of its page on the app.
But when I look now, each node *does* indicate which other node it is
connected to, as it did when the Velop system was in Auto DHCP mode. I bet
if I deliberately turn a node off, the app will show it as disconnected (or
not list it at all) now, even though it didn't earlier.
So the change from Auto DHCP to bridge has *not* destroyed the info about
which nodes are connected to which other ones, despite earlier appearances
;-) Panic over.
BrightsideS9
Feb 15, 2022, 4:57:56 AM2/15/22
to
On Tue, 15 Feb 2022 09:08:49 -0000, "NY" <m...@privacy.invalid> wrote:
>"Tweed" <usenet...@gmail.com> wrote in message
>news:suefb7$371$1...@dont-email.me...
>>> I've attached an SVG floorplan of the house
>
>> I’m afraid your attachment didn’t attach. (Text only news group)
>
>Grr. I'd seen it attached to the message in the outbox and forgot that it
>would get stripped off.
>
Agent happily showed the attachment,(server eternal september),
>"Tweed" <usenet...@gmail.com> wrote in message
>news:suefb7$371$1...@dont-email.me...
>>> I've attached an SVG floorplan of the house
>
>> I’m afraid your attachment didn’t attach. (Text only news group)
>
>Grr. I'd seen it attached to the message in the outbox and forgot that it
>would get stripped off.
>
opened with in my case Edge.
--
brightside s9
Graham J
Feb 15, 2022, 6:22:54 AM2/15/22
to
NY wrote:
[snip]
>> Were you able to resolve the difficutly with using the Velop as an
>> Ethernet router, and the TPlink TD9980 as a modem? I suggested in my
>> reply to you on 13/02/2022, 09:10 that your problem as reported on
>> 12/02/2022, 19:07 was that you had VLAN ID (101) set in the PPPoE page
>> for the Velop, whenI think that VLAN ID (101) is only required in the
>> modem (the TPlink TD9980).
>>
>> Did you try removing VLAN ID (101) from the Velop?
>
> I'd already set up the Velop and router as Velop=bridge and
> router=NAT/DHCP by the time I saw all the answers. If I have problems
> with this set up, I'll try reversing things and make the Velop the
> NAT/DHCP and the router into a modem.
[snip]
I haven't found a good explanation of this. In the early days of VDSL
(i.e. FTTC) no ISPs understood the need for VLAN Tag 101 so Googling
finds lots of annoyed customers.
However, from:
<https://community.plus.net/t5/Fibre-Broadband/VLAN-tagging-on-Fibre-connection/td-p/1761339>
I see: "Every ISP/CP in the UK supplying a service, carried via the
Openreach FTTC (VDSL2, ITU-T G.993.2) product, makes use of a VLAN
(tagged 101) between the modem and the upstream equipment. The VLAN
end-point is the modem. Any equipment connected downstream of the modem
has no knowledge of that VLAN. The Openreach modems (in their default
configuration) will remove the VLAN tagging, so as far as the router is
concerned, there is no VLAN on your connection. EE's advice to set VLAN
101 will be for combined modems/routers, where you need to specify VLAN
101 in the modem configuration section (this doesn't apply when you have
a separate modem and router). "
There is some background info at:
<https://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html>
In summary, VLAN tag 101 is used in the modem, not the router. Clearly,
if the router contains a modem (as with my Vigor 2860) then the page
that configures its internal modem needs the VLAN tag to be set
correctly. So your Velop router should NOT need VLAN Tag 101 anywhere
when connecting to an Ethernet modem, but your TPlink TD9980 in bridge
mode (functioning as an Ethernet modem) will need it.
I suspect the purpose is to allow several ISPs to share a single cable
or fibre.
I note that for FTTP Openreach might supply its Optical Network
Termination (ONT) which provides one RJ45 socket for a connection to the
user's Ethernet router, and a POTS socket to receive the BS 6312 431A
plug as found on an ordinary telephone. When Openreach discontinue the
POTS service in 2025 - see:
<https://www.ispreview.co.uk/index.php/2020/05/openreach-to-stop-selling-copper-phone-in-118-areas-go-fttp.html>
users who do not require a broadband service will be supplied with VoIP
via this ONT. So the one fibre to the premises will potentially carry
two broadband services simultaneously, and I suspect this will be
achieved with VLAN tagging in the ONT.
If anybody has better technical references to explain this, I woudl
appreciate it.
--
Graham J
[snip]
>> Were you able to resolve the difficutly with using the Velop as an
>> Ethernet router, and the TPlink TD9980 as a modem? I suggested in my
>> reply to you on 13/02/2022, 09:10 that your problem as reported on
>> 12/02/2022, 19:07 was that you had VLAN ID (101) set in the PPPoE page
>> for the Velop, whenI think that VLAN ID (101) is only required in the
>> modem (the TPlink TD9980).
>>
>> Did you try removing VLAN ID (101) from the Velop?
>
> I'd already set up the Velop and router as Velop=bridge and
> router=NAT/DHCP by the time I saw all the answers. If I have problems
> with this set up, I'll try reversing things and make the Velop the
> NAT/DHCP and the router into a modem.
I haven't found a good explanation of this. In the early days of VDSL
(i.e. FTTC) no ISPs understood the need for VLAN Tag 101 so Googling
finds lots of annoyed customers.
However, from:
<https://community.plus.net/t5/Fibre-Broadband/VLAN-tagging-on-Fibre-connection/td-p/1761339>
I see: "Every ISP/CP in the UK supplying a service, carried via the
Openreach FTTC (VDSL2, ITU-T G.993.2) product, makes use of a VLAN
(tagged 101) between the modem and the upstream equipment. The VLAN
end-point is the modem. Any equipment connected downstream of the modem
has no knowledge of that VLAN. The Openreach modems (in their default
configuration) will remove the VLAN tagging, so as far as the router is
concerned, there is no VLAN on your connection. EE's advice to set VLAN
101 will be for combined modems/routers, where you need to specify VLAN
101 in the modem configuration section (this doesn't apply when you have
a separate modem and router). "
There is some background info at:
<https://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html>
In summary, VLAN tag 101 is used in the modem, not the router. Clearly,
if the router contains a modem (as with my Vigor 2860) then the page
that configures its internal modem needs the VLAN tag to be set
correctly. So your Velop router should NOT need VLAN Tag 101 anywhere
when connecting to an Ethernet modem, but your TPlink TD9980 in bridge
mode (functioning as an Ethernet modem) will need it.
I suspect the purpose is to allow several ISPs to share a single cable
or fibre.
I note that for FTTP Openreach might supply its Optical Network
Termination (ONT) which provides one RJ45 socket for a connection to the
user's Ethernet router, and a POTS socket to receive the BS 6312 431A
plug as found on an ordinary telephone. When Openreach discontinue the
POTS service in 2025 - see:
<https://www.ispreview.co.uk/index.php/2020/05/openreach-to-stop-selling-copper-phone-in-118-areas-go-fttp.html>
users who do not require a broadband service will be supplied with VoIP
via this ONT. So the one fibre to the premises will potentially carry
two broadband services simultaneously, and I suspect this will be
achieved with VLAN tagging in the ONT.
If anybody has better technical references to explain this, I woudl
appreciate it.
--
Graham J
Tweed
Feb 15, 2022, 12:32:28 PM2/15/22
to
cable speed is the easiest thing to do as all I need to do is run one of
the speed test apps. I don’t have any local NAS storage, so finding
something to exercise the LAN would be a bit of a faff.
5 GHz gives me the full 200 Mbit/sec. 2.4 GHz gives me 75 MBits/sec.
Theo
Feb 15, 2022, 3:54:23 PM2/15/22
to
Tweed <usenet...@gmail.com> wrote:
> Oh yes, I know the local speed could be higher, but testing against my VM
> cable speed is the easiest thing to do as all I need to do is run one of
> the speed test apps. I don’t have any local NAS storage, so finding
> something to exercise the LAN would be a bit of a faff.
You can run iperf on two machines:
> Oh yes, I know the local speed could be higher, but testing against my VM
> cable speed is the easiest thing to do as all I need to do is run one of
> the speed test apps. I don’t have any local NAS storage, so finding
> something to exercise the LAN would be a bit of a faff.
https://iperf.fr/iperf-download.php
On one, run 'iperf -s'. This is the server.
On the other, you have various options, but something like
iperf -c <ip of server>
would do a basic TCP test over 10 seconds.
Unlike downloading files which depends on how good the server is, iperf is
pretty good at making full use of the bandwidth you have - eg you can get a
solid 935Mbps out of gigabit ethernet.
Theo
NY
Feb 16, 2022, 4:32:32 AM2/16/22
to
"Theo" <theom...@chiark.greenend.org.uk> wrote in message
news:G7i*-s...@news.chiark.greenend.org.uk...
so that isn't a rate-limiting step. 935 Mbps - watch that Cat 6 cable glow
red hot ;-)
Tweed
Feb 16, 2022, 1:11:36 PM2/16/22
to
you? If you’ve got local storage you need to access across the network it
might be a valid test. Me, knowing I can get my full 200 Mbit/sec Virgin
Internet connection across the house is what is sensible to test.
NY
Feb 16, 2022, 5:18:02 PM2/16/22
to
"Tweed" <usenet...@gmail.com> wrote in message
news:sujeom$vjd$1...@dont-email.me...
>>> You can run iperf on two machines:
>>> https://iperf.fr/iperf-download.php
>>>
>>> On one, run 'iperf -s'. This is the server.
>>> On the other, you have various options, but something like
>>> iperf -c <ip of server>
>>> would do a basic TCP test over 10 seconds.
>>>
>>> Unlike downloading files which depends on how good the server is, iperf
>>> is
>>> pretty good at making full use of the bandwidth you have - eg you can
>>> get
>>> a
>>> solid 935Mbps out of gigabit ethernet.
>>
>> And raw transport tests like this don't involve any reading/writing to
>> disc,
>> so that isn't a rate-limiting step. 935 Mbps - watch that Cat 6 cable
>> glow
>> red hot ;-)
>>
>>
>
> But other than making you feel good (or disappointed) where does it get
> you? If you’ve got local storage you need to access across the network it
> might be a valid test. Me, knowing I can get my full 200 Mbit/sec Virgin
> Internet connection across the house is what is sensible to test.
Yes, raw transport tests are good for showing whether you've got an
>>> https://iperf.fr/iperf-download.php
>>>
>>> On one, run 'iperf -s'. This is the server.
>>> On the other, you have various options, but something like
>>> iperf -c <ip of server>
>>> would do a basic TCP test over 10 seconds.
>>>
>>> Unlike downloading files which depends on how good the server is, iperf
>>> is
>>> pretty good at making full use of the bandwidth you have - eg you can
>>> get
>>> a
>>> solid 935Mbps out of gigabit ethernet.
>>
>> And raw transport tests like this don't involve any reading/writing to
>> disc,
>> so that isn't a rate-limiting step. 935 Mbps - watch that Cat 6 cable
>> glow
>> red hot ;-)
>>
>>
>
> But other than making you feel good (or disappointed) where does it get
> you? If you’ve got local storage you need to access across the network it
> might be a valid test. Me, knowing I can get my full 200 Mbit/sec Virgin
> Internet connection across the house is what is sensible to test.
efficient transport stack and/or anything in the network infrastructure
which is slowing down traffic eg by dropping packets and prompting retries.
But it's not very real-world.
In the 1990s I worked in a team that was porting LAN Manager for UNIX
(LM/X), which is effectively SAMBA, to our servers. A lot of the work was
unpicking byte-ordering assumptions for Intel so the same source code with
ifdefs would work on SPARC with opposite byte-ordering. We were planning to
run over TCP/IP, OSLAN (ICL's implementation of OSI) and NetBEUI. This was
in the days of non-Windows PCs or else Windows with DOS transport stacks.
And we did a lot of tests of raw transport speed between the same PC and the
same server, using OSLAN+NetBIOS or TCP+NetBIOS or NetBEUI - repeat enough
times that statistical variations for a given stack were averaged out. I
forget the exact results, but I think we found that NetBEUI was the fastest
and OSLAN was the slowest. We also found that it made a difference for DOS
stacks whether the one being used was in ordinary 640 KB memory or HIMEM or
Upper Memory, when you had to play "transport stack tetris" and try to load
several stacks on the same PC.
I spent ages trying to work out why I couldn't achieve more than 10 Mbps
even though the PC and UNIX server definitely had 100 Mbps network interface
cards. Then I discovered that somewhere in the cabling for our private LAN,
there was a 10/100 switch that had got "stuck" on 10 and wouldn't
auto-adjust if both ends of a conversation were 100 Mbps.
My real-world throughput tests nowadays consist of copying a 1-2 GB .ts
recording of a TV programme from one place to another. Raspberry Pi to
Windows ("pulled" from Windows) copied at 42 MB/sec (roughly 420 Mbit/sec)
and Windows to Pi ("pushed" from Windows) managed 27 MB/sec. That's over
gigabit Ethernet with gigabit switches. The equivalent over 5 GHz wifi
Wireless N were 27 and 11 MB/sec respectively - for Windows PC connected by
wifi but Pi still connected by Ethernet. In all cases, copying from spinning
HDD to spinning HDD. So the Pi is managing about half the rated LAN speed at
best, which is pretty damn good for a £90 computer. In the past I've seen a
*very* wide variation in transfer speeds over wifi, even when the Windows
computer is always connected to the same Linksys mesh network node and is
showing similar signal levels (measured as number of bars of signal) and
there's little other traffic.
You can get too engrossed in the figures. The main conclusion is that
all-Ethernet is fast and constant, whereas wifi is slower and a lot more
variable, both during the course of a file transfer and between one file
transfer and another. But it still beats the "sneakernet" approach of
copying onto a portable HDD, walking to the other end of the house and
copying off the portable drive. However I will never forget the email sig of
one of my colleagues: "Never underestimate the baud rate of an HGV full of
mag tapes" - it may take several hours to drive from A to B, but if the HGV
is crammed with mag tapes, the total amount of information that you have
transferred in that time is phenomenal, measured as bits per second.
Tweed
Feb 17, 2022, 1:52:27 AM2/17/22
to
0 new messages