Showing results for 
Search instead for 
Did you mean: 


Introducing the next generation of Cisco Small and Medium Business Switches. Cisco is refreshing its SMB Switch portfolio. Click here  to learn more.


Issues with SRW* Switches


Model: Linksys SRW248G4 sw.



1) [edited]

One is NOT able to add a port to many untagged VLANs (for igress traffic to be directed into all of them)...

Surecom switches allowed to to this, it was helpful.


Web interface is NOT working with IE8 (though it is said in Release notes, it works with IE5.5+). It works with IE5.5 to IE7 (though there are stilllsome bugs revealling, see below), but not with IE8. If the software gets updated at all the hosts in our LAN, we will not be able to configure the sw...

When I get to the "home.htm" page, the javascript engine tells me that
Line: 40
Error: Object expected

Msxml is installed (and is of the latest version). We have tested it with Windows server 2003 and IE8, with Windows XP and IE8... nothing helps (we have also disabled all the restrictions on active x). It just does not work.

The sw is completely unconfigurable in UNIX-only environment... as it relies at the M$ client side "technology"...

CLI functionality is very poor as it allows one to configure only some basic parameters (IP address, local users for auth). It does NOT allow to setup VLANs,*STP,any Security features, etc.

When trying to configure the sw using IE6-7, there is a bug showing up when  we  try to  add one port to many VLANs ("VLAN to Ports" page) and press "Save". The port seems to be added to VLANs but the error message is instantly showing  up  which says that some error appeared, but it doesn't know the error ID or the reason. This is really annoying. =) :


  Line No. Error Type Value Diagnostic   
       1       null       Unknown value       Might be missing parameters (join1)  in page.


We like the sw, but it is so hard to work with it, not mentioning that we have to install M$ Windows to manage it... We'd like to see it working with IE8+ and Firefox (all 3Com and Allied Telesyn sw do!), and we'd like to see more functionality in CLI interface.


And there is another bug: when I set up a port to be Trunk, when after that I create a new VLAN, the port is not associated with it automagically: I have to add it MANUALLY! =) While by definition of the Trunk port type: it is assosiated with all but native VLANs in tagged mode automatically... another way, how does it differ from general mode if I HAVE to add newly created VLANs to it manually? (this is a rethorical question)

Your issues and concearns would best be addresses by calling into the SBSC and creating a case. The number here is 866.606.1866.



One more important problem of the current SRW* switches firmware:

When editing ACLs, one is not able to move around (change their places, eg.) rules in the ACL...

So, it is very incovenient, when you are not able to put some rule in the middle of existing ones, interchange rules' places... you are only allowed to ad a rule to

the end of the list or delete the rule... this is really bad.


  I think there is some confusion here, excuse me in advance for going into lecture mode ..


      a. Keep in mind that there are TWO VLAN-membership to think of: (1) VLAN membership *of the frame* (which is assigned at ingress)
        and (2) VLAN membership of the port. The distinction is important, as you will see blow.

     b. While in-transit in the switch, a frame has a VLAN membership but does NOT have a VLAN tag (I am ignoring the double-tagging case here, I know).
        a tag will or will not be added at egress, but does not exist indie the switch. Even if the frame came in tagged, the tag was removed at ingress.

     c. The  Tagged/Untagged membership of a port in a VLAN is only an EGRESS attribute. If the port is a tagged member of VLAN X, and a frame belonging
          to VLAN X is about to be sent, then if the egress port is a tagged m,em,bers of VLAN X a Tag will be added. If the egress port is an untagged member
          of VLAN X, no tag will be added, and the frame will be sent untagged.

     d. at ingress, every incoming frame is assigned to ONE VLAN. If it came in tagged, the FRAME will belong to the VLAN specified in the tag, if it came
         in untagged, the port PVID will be used. Since a port only has a single PVID, all incoming untagged frames will be placed into a single VLAN. Note this
         assigns a VLAN *to the frame*, not to the port. Usually, the port IS a member of the relevant VLAN, but in general mode, you can (and sometimes it
         is even useful) to create a situation where the port is NOT a member of the VLAN to which the port's PVID sends incoming untagged frames.

     e. The only Tag-related setting you have at ingress is allowing untagged frames to come in, or only allowing tagged frames to come in. This setting
         has nothing to do with any VLAN membership of the port.

     So - you CAN set a port to be an untagged member of multiple VLANs, but this will affect only what happens to outgoing frames.

    While we are at it - Access/Trunk/General modes:

     By the VLAN standard (used to be called IEEE802.1Q, and now part of 802.1D) the switch admin should be able to (and must)  independently
    configure multiple attributes of VLAN handling: Port X membership or not in VLAN Y, If at egress this combination will or will not add a tag, if
    to check that incoming frame and port both belong to the same VLAN, a similar check at egress, and if to allow an incoming frame to be accepted
    if it comes in untagged, or only allow tagged frames.Using the full set you can decide per port per vlan each of these settings. Since this is considered
    too complex for us small-fry users , Cisco (and maybe others) long ago created "Access" and "trunk" ports, which are essentially pre-configured

    setting-combinations of these. This saves work, but reduces your flexibility. In SRWxxx you have these two pre-configured Access and Trunk modes,
    and you also have "general" poret, wheich is the "you can do it all - but you MUST do it all (and correctly)" option.


1) Surecom switches supported adding a port to many VLANs in untagged mode. It might violate standards, but it was helpful.

I may not be right that inability to do this is a bug. Ok, then it's my fault here.

2) On trunk port type: didn't get the point. As I understand it, a "trunk" port must be associated with all but "native" VLANs in tagged mode automatically. Whether I add a new VLAN to the switch, it must be there automatically. Again, I might miss something, still, as it seems to me, there's little help from "trunk" port type if I have to add a newly created VLANs to it manually.

3) On web interface: it works with IE only (it is REALLY BAD (Did Miscrosoft pay Linksys for this?... Seems to be the case)) and does not work with IE8 out of the box.

4) The switch is called "managed", but I didnt' see any capabilities to configure any advanced settings through the telnet/ So, what's the difference from some "web-smart" switch?

5) ACL editing is not flexible. One is not able to insert a new rule between already created rules. One is not able to interchange rules' places.This is very inconvenient. Wildcard masks are not shown in the rules table.

Best regards.

r. Satanovskyl -

You CAN "add a port to many VLANs in Untagged mode" in SRW's. This not only does not violate any

standard - it is in fact *Required* by the standard tobe able to do that.

In SRW set the port to "General" mode and you can assign a port to as many VLANs

as you want, and for each decide if it is tagged or not. (so you can have 10 Tagged

and 10 Untagged VLANs, all on the same port). As I said, this is an EGRESS-ONLY


The problem is that I am not sure this will do what you want.In your original request

you said (as I recall) : "I have a server with a single NIC only capable of sending out

untagged frames, and I want it to be in several VLANs".

But this can be problematic ragardless of which swith you use:

  1. Server sends a frame, which arrives as ingress to the switch on port A. Let's
    assume port A is a member of 20 VLANs, 10 tagged, 10 Not. The switch looks
    at the incoming frame, and since it has no tag, assigns the Frame to the VLAN
    set as PVID  (let's call this VLAN "V-IN"). Note ALL frames from the server will
    get the same handling, (since the switch has no way to differentiate between
    them)  and they all go into the same ingress VLAN V-IN
  2. The switch forwards the frame to an egress port (or more than one) by destination
    address. The frame is still in the VLAN V-IN assigned to it at ingress
  3. The switch also learns the source MAC address from this frame on the ingress port
    A , in the VLAN "V-IN" assigned to the frame at ingress
  4. When a response comes in on another port B, if the response frame is in VLAN "V-In"
    (and this depends on the question did the RESPONSE frame came tagged with this
    VLAN, and if not was the PVID of the port on which it came set to "V-IN" as well)
    then it will be sent to your server as expected, If the response frame is in another
    VLAN "X" then the switch will see the destination address as "unknown" since it was
    learned on V-IN, not on X; So the frame will be flooded to all ports that belong to
    VLAN X; If the sport A s a member of VLAN X, the frame will be sent to the server,
    and it will be SENT  tagged or not depending on the Tagged/Not membership type
    of port A in VLAN X;If the frame is sent Tagged, your server's NIC should be able to
    deal with it.

Note this entire discussion is true for ANY VLAN-aware switch, regardless of model and
vendor. SRW has nothing special here, for good or for bad.
(Actually, I take this back - some switches only have Access and Trunk modes,
and there you will not be able to have more than one untagged VLAN on a port,

SRW does provide you with full control when you need it)

(if you MUST you can play tricks by setting the server's MAC address as a static MAC

address on port A in any VLAN to which Port A belongs, so regardless of which VLAN
the response comes in on, it will always be sent to Port A, as expected.)

As for "Trunk mode" - this is a gray-area, matter-of-taste thing. There is no standard
for this.

  • The way this is done on most Cisco Catalyst switches is that a trunk-mode port
    is automatically associated with any and all VLANs, (and always tagged except for
    a single "Native" VLAN
  • In SRW case, a trunk port is ALLOWED to be associated with as many VLANs as
    you want, all tagged except one, but there is no automatic association: You must
    do it manually.(so you can get to the same end result, but have to DIY)

   You can see this as a bug, a missing feature, or even as a feature (admit it - you saw this one coming ... ;)

    (many Admins do not like invisible side-effects, and the "catalyst way" means that if I set a port to   

    trunk-mode now, and create a VLAN next week, it will silently becomne a member of that VLAN
    then - which will not be a visible effect at the time)

No support for FF - yes, not good. (tough I doubt MS paid for this ...)

The "managed" as opposee to "web-smart" names  - don't you love marketing?


Thank you for these very good posts.



Thanx, Mike.

If you are not against it, I'd like to put here a few words.

First, on the "vlan" question. The detiled description you gave is helpful. Somehow Surecom switches allowed adding a port to many vlans for both ingress and egress traffic in untagged mode. Believe it or not. =) It was useful. Linksys sw does not support it, and let it be, let the question be closed.

Next, more important, on the trunk port type. Nobody likes "side effects". It is not a "grey area",
as you think it to be. It is really inconvenient and makes not much sense
to add newly created vlans to a trunk port manually.

On CLI interface: it's functionality is poor. It is too poor for the switch to be called "managed" (and I do not think this is a "grey area", "matter of taste"). If I am right, a "managed" switch by definition must allow all the functionality be configured using CLI... The discussed one (with current firmware) allows only IP setting and some basic port managent. No VLAN management, etc.

And finally, not the least important, on ACL editing: it is impplemented in a very inconvenient manner,  see arguments above.

Thanks to this forum (or not?), Cisco started making a new firmware for these switches [].

Anyway, thank you for your answering
and best regards, Leonid.


I'm having the same Web Interface problem. I have tried using IE 10 and I cannot get this Web interface however when I try on IE 7.0 it seems to be working. I though cisco would have sorted this out by now.


you are almost certainly not having the same problem Leonid had three years ago, At that time IE10 didn't even exist, and the small business switch software has changed very much since then. So you'd be better off starting a new discussion for that, and be sure to include the version number of the software your switch is running.

Best regards,