Subnet mask and swos

HaPe · June 14, 2014, 7:53pm

Hi,
which subnet mask does swos use(/8, /24, /16 …)?

dimnik · February 17, 2015, 2:19pm

http://wiki.mikrotik.com/wiki/SwOS#System_Tab
“Note: SwOS uses a simple algorithm to ensure TCP/IP communication - it just replies to the same IP and MAC address packet came from. This way there is no need for Default Gateway on the device itself.”

Hotz1 · March 23, 2015, 7:28pm

Oh, there is definitely a need for them; it’s just that it works in a lot of places without them.

ZeroByte · March 23, 2015, 8:48pm

What a hilarious response! So true, too.

chechito · May 7, 2015, 9:51pm

no need???

no way to manage it remotely using vlans and accessing from a remote VPN

Hotz1 · June 10, 2015, 12:40pm

What they’re saying is that it replies via Layer 2. A device connected to the switch hands the switch a packet. When the switch builds its reply, it still sets the Dst IP to the Src IP of the original message, but then it sets the Dst MAC to the original Src MAC, regardless of the Dst IP. That means replies always get handed back to the same neighbor that forwarded the original packet. So, as long as the switch is on a network managed by a router, you can reach it in any way the router supports–including VLANs, PPTP, etc.

The switch does answer to its own IP on whatever VLAN you use to reach it, so it doesn’t truly support the “management vlan” concept; but as long as your router assigns the management address space to the appropriate VLAN, it will work as though it did. (But if you force its address onto a different VLAN, it will still reply.)

If you mean the switch should be able to establish its own tunnel to the NOC, you’re going to need a more expensive ($$$$) switch.

chechito · June 10, 2015, 12:59pm

Hotz1:

chechito:

dimnik:

http://wiki.mikrotik.com/wiki/SwOS#System_Tab
“Note: SwOS uses a simple algorithm to ensure TCP/IP communication - it just replies to the same IP and MAC address packet came from. This way there is no need for Default Gateway on the device itself.”

no need??? no way to manage it remotely using vlans and accessing from a remote VPN

What they’re saying is that it replies via Layer 2. A device connected to the switch hands the switch a packet. When the switch builds its reply, it still sets the Dst IP to the Src IP of the original message, but then it sets the Dst MAC to the original Src MAC, regardless of the Dst IP. That means replies always get handed back to the same neighbor that forwarded the original packet. So, as long as the switch is on a network managed by a router, you can reach it in any way the router supports–including VLANs, PPTP, etc.

The switch does answer to its own IP on whatever VLAN you use to reach it, so it doesn’t truly support the “management vlan” concept; but as long as your router assigns the management address space to the appropriate VLAN, it will work as though it did. (But if you force its address onto a different VLAN, it will still reply.)

If you mean the switch should be able to establish its own tunnel to the NOC, you’re going to need a more expensive ($$$$) switch.

thanks for your reply

i only want the sw os to have a default gateway only that.

because with the actual functionality i cannot manage it from a different subnet, the only way i found to manage it from a different subnet was using local router as a web proxy

bpwl · January 28, 2021, 12:20pm

There should be no need for the web proxy. The SwOS will answer with the original src IP as dst IP, and the MAC address of the router (the src MAC address in the received request) . The router will forward according its routing tables.

k6ccc · January 31, 2021, 6:26pm

I have not found a situation where I could not access any of my switches. At the very least, the computer is on a different VLAN than the switch is listening on, so traffic is going through a router or two to get there and it always finds its way back. This computer has an IP on my .101 LAN. Although it is plugged directly into my family room switch, the switch IP is on my .201 LAN, and the switch is set to only accept traffic on the 201 VLAN. So to get to the switch from this PC is as follows: PC on .101 VLAN > [through switch 1 and switch 2] > router 1 > router 2 [through switch 2] > Switch 1

C:\windows\system32>tracert 192.168.201.1
Tracing route to 192.168.201.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.101.251 (Router 1)
2 <1 ms <1 ms <1 ms 192.168.211.252 (Router 2)
3 <1 ms <1 ms <1 ms 192.168.201.1 (Switch 1)
Trace complete.

I often get to the switches from remote locations via the internet (yes, there is some serious firewalling in the routers on that).
Never failed.

bpwl · January 31, 2021, 8:25pm

The only thing with this “answer with src IP and src MAC as destination” mechanism is that the switch cannot initiate a connection to something outside the own subnet, as it does not have a clue on the gateway to use. But I see no process that initiates a connection from the switch (like SNMP trigger, syslog send, SNTP request, DNS request…).

If the return-path is correct in the router/gateway, there should be no problem to answer, respond to, or maintain a remotely initiated connection.

k6ccc · January 31, 2021, 9:17pm

Check for System Upgrade - and that, for me always works…

bpwl · January 31, 2021, 11:24pm

I admit the “upgrade” check puzzled me too. (Maybe the switch had router discovery methods ?)

But as you stated it , I started having a little check.

There is no IP session originating from the switch at my edge gateway/firewall. (There should have been an open NAT session)

So where does it come from ? There is traffic from my PC. So let’s check the browser page. (Chrome has the developers tools built in).
And the browser is checking upgrade.microsoft .com to fill in this page. The switch is not initiating a request.
..

k6ccc · February 1, 2021, 2:33am

Ain’t that interesting…