... | ... | @@ -118,21 +118,21 @@ switches](/Switch#commercial-producer). |
|
|
|
|
|
## Switch management
|
|
|
|
|
|
### Q: Can WR Switch get the IP address on the Management Ethernet port from DHCP server ?
|
|
|
### Q: Can the WR Switch get its IP address on the Management Ethernet port from DHCP server ?
|
|
|
|
|
|
A: Yes, WR Switch has a DHCP client software. Please remember though, if
|
|
|
you modify the startup scripts to assign a static IP address, the
|
|
|
configuration got from DHCP server will be overwritten.
|
|
|
A: Yes, the WR Switch has a DHCP client software. Please remember
|
|
|
though, if you modify the startup scripts to assign a static IP address,
|
|
|
the configuration received from the DHCP server will be overwritten.
|
|
|
|
|
|
??Author: Grzegorz Daniluk,
|
|
|
[CERN](http://cern.ch??)
|
|
|
|
|
|
### Q: Is it possible to forward received UDP packets to the switch's Management (copper) Ethernet port?
|
|
|
|
|
|
A: It is possible. However, it is a dangerous idea which is strongly
|
|
|
discouraged as it can have very bad consequences including switch
|
|
|
crashing. Therefore, this is not supported and no information on how to
|
|
|
do it will be provided by the switch developers.
|
|
|
A: It could be done, but is not supported. It is a dangerous idea which
|
|
|
is strongly discouraged as it can have very bad consequences including
|
|
|
switch crashing. Therefore, this is not supported and no information on
|
|
|
how to do it will be provided by the switch developers.
|
|
|
|
|
|
??Authors: Alessandro Rubini,
|
|
|
[Gnudd](https://www.ohwr.org/companies/gnudd), Maciej Lipinski,
|
... | ... | @@ -140,42 +140,42 @@ do it will be provided by the switch developers. |
|
|
|
|
|
### Q: Why on older switches (up to Feb 2013) it was possible to access (e.g.: ssh) WR switch through any port (wr0-wr17 and management) and in the newer software releases (from July 2013, v3.3) it is not ?
|
|
|
|
|
|
A: Accessing WR switch for management (e.g. ssh) through "normal" port
|
|
|
(e.g. wr17) instead of management port is one of the dangerous features
|
|
|
that you won't find on "normal switches" - it is a serious security
|
|
|
breach. This is why it shall not be supported out-of-the-box on WR
|
|
|
switches and it is strongly advised by WR developers to avoid doing
|
|
|
it.
|
|
|
A: Accessing the WR switch for management (e.g. ssh) through a "normal"
|
|
|
port (e.g. wr17) instead of through the copper Ethernet management port
|
|
|
is one of the dangerous features that you won't find on "industrial
|
|
|
switches" - as it would open a serious security hole. This is why it
|
|
|
shall not be supported out-of-the-box on WR switches and it is strongly
|
|
|
advised by WR developers to avoid doing it.
|
|
|
Here are some dangers of doing so:
|
|
|
|
|
|
1. What it effectively does is enable any user in the network to break
|
|
|
the network completely by ssh-ing to the switch and doing whatever.
|
|
|
This is why management port should be used and it should be
|
|
|
This is why only the management port should be used that should be
|
|
|
connected to a separate network which is limited-access only by the
|
|
|
administrator (we call it technical network). This is especially
|
|
|
true for "normal networks" with public access, less in
|
|
|
administrator (we call it technical network at CERN). This is
|
|
|
especially true for "normal networks" with public access, less in
|
|
|
control\&acquisition systems
|
|
|
2. Management port will work regardless of FPGA binary and even
|
|
|
2. The management port will work regardless of FPGA binary and even
|
|
|
operating system/daemons on the switch. This means that if you
|
|
|
upgrade FPGA's binary or software on the WR switch and something
|
|
|
goes wrong for some reason, chances are, you can still access the
|
|
|
switch using management port but you will surely have no access
|
|
|
through wrPorts - if you limit your access to the switch only to
|
|
|
wrPort (e.g. wr17) in a remote site... there are more chances you
|
|
|
upgrade the FPGA binary or software on the WR switch and something
|
|
|
goes wrong for some reason, chances are that you can still access
|
|
|
the switch using the management port but you will surely have no
|
|
|
access through wrPorts - if you limit your access to the switch only
|
|
|
to wrPort (e.g. wr17) in a remote site... there are more chances you
|
|
|
will need to go there physically to fix something.
|
|
|
3. Using wrPort (e.g. wr17) might degrade performance of frame
|
|
|
forwarding as well as the daemons (e.g. WRPTP timing) running on CPU
|
|
|
- remember that CPU is connected with all the wrPorts through a
|
|
|
single "virtual" port which is multiplexed. Your ssh session (as
|
|
|
well as scp and whatever you use over wr17) is shared the with the
|
|
|
daemons that make sure your network works properly. If your
|
|
|
management activities overwhelm the wrPort (and CPU), you might end
|
|
|
up managing misbehaving switch.
|
|
|
|
|
|
To sum up, using non-management port (e.g. wr17) for ssh and management
|
|
|
is possible on WR switch but needs special configuration. It is
|
|
|
something you might do for some reasons in the lab or while testing
|
|
|
system but should definitely avoid doing in a deployed
|
|
|
3. Using a wrPort (e.g. wr17) might degrade performance of frame
|
|
|
forwarding as well as the daemons (e.g. WRPTP timing) are running on
|
|
|
the CPU - remember that CPU is connected with all the wrPorts
|
|
|
through a single "virtual" port which is multiplexed. Your ssh
|
|
|
session (as well as scp and whatever you use over wr17) is shared
|
|
|
the with the daemons that make sure your network works properly. If
|
|
|
your management activities overwhelm the wrPort (and CPU), you might
|
|
|
end up managing a misbehaving switch.
|
|
|
|
|
|
To sum up, using a non-management port (e.g. wr17) for ssh and
|
|
|
management is possible on a WR switch but needs special configuration.
|
|
|
It is something you might do for some reasons in the lab or while
|
|
|
testing systems, but it should definitely be avoided in a deployed
|
|
|
network.
|
|
|
|
|
|
-----
|
... | ... | |