layer 3 mode

[lukasz_naumowicz]

Hi,

After changing SF300 to layer 3 mode I've lost contact with the switch interface.

The only method I can access switch is console interface.

I've set the management IP address for VLAN 1 interface(default vlan), computer is in the same subnet, but I can;t ping  the switch.

I can ping from the computer(connected to the switch) default gateway, but I can't ping switch address.

Web UI or SSH is also not available. I don;t what I'm doing wrong?

Best Regards,

Lukasz

[thomson77840]

This is strange, you should be able to do what you are describing.  I just applied this setting my self and had no trouble whatsoever accessing the web interface after the switch got it's DHCP IP address.

Make sure that you have enabled the HTTP server: IP configuration > HTTP configuration > then enable it

Look under the IPv4 Address table and see if you can see the IP address listed there:

IP configuration > IPv4 Address Configuration> IP address table

Have you tried HTTPS?

Quick question:

Can you ping out from the switch console?  Try pinging the gateway from inside the switch, also try pinging the PC from the switch. ( note that if your pc's firewall is active it may reject the ping)

IP configuration > Network Configuration > Ping (ipv4)

[lukasz_naumowicz]

Hi,

Here is what I've done to enable layer 3 mode,(today I've checked it again):

1. reset switch to factory default

2. change operation mode from layer 2 to layer 3

3. reboot system

4. set static ip address for management

The topology of network is very easy:

SA520 - SF300 - management_host

Ip addressing:

SA520 - 192.168.75.1

SF300 - management VLAN1 - 192.168.75.220 (static IP address)

management_host - 192.168.75.100 (address from DHCP - SA520)

in the ipv4 address table of SF300 we can see two address:

192.168.75.220 - static

192.168.75.115 - DHCP

Connectivity test, ping:

1. from SA520 to SF300 - fail

2. from SA520 - management_host - pass

3. from SF300 to SA520 - fail

4. from SF300 to management_host - fail

5. from management_host to SF300 - fail

6. from management host to SA520 - pass

I've attached output from ping commands and few screens from console output. I don't know what I'm doing wrong.

Thanks,

Lukasz

[thomson77840]

Thanks for the detailed response!

I still can't replicate your problem on my device, so I have a few more questions for you:

1. What is your firmware version (just for a sanity check)? You can check this through the console: System Configuration Menu > System Information > Versions > SW Version.  The latest is firmware 1.0.0.27 boot code 1.0.0.4

2. What is the IP address of the switch when it first boots up and receives a DHCP lease from your router? (I believe it to be .115)

3. Before you add the static IP address for the management interface, can you log into the web GUI using firefox/ie and the DHCP IP address provided by your router? (in your case .115)

4. In detail, what steps do you take to add the static IP address to the management interface? (your .220 address) When I attempt this step listed in your post, it overwrites the DHCP address in the IP Address Table.  My address table always only shows 1 IP address that gets overwritten when changing from static to DHCP.

The problem that I see in the last post is that there are two IP addresses in your table.  It seems like to me that there should be only 1 address there.

[lukasz_naumowicz]

Hi,

After switch reset, before changing the IP address to static we can get to webUI of the switch on address that was taken from DHCP server: 192.168.75.115.

But just after changing via console address to Static IP, we can see in the address table two different IP addresses. From this moment we can;t get to switch WebUI or ping the switch.

I suppose that when we change address from DHCP to static, it should be overwriten and we should access switch on the new address.

Frames from computer to the router are switched with no errors no matter if switch has one or two IP addresses.

Thank you for help,

Lukasz

[ddiep]

We were able to reproduce the problem. For the work-around , please try to use 192.168.1.x subnet for the time being while we're debugging the problem. Will keep you posted.

Thanks!