OK.  Disconnect it from the Core switch factory reset it, re-configure the VLAN and ports and then test again.  IF that fails its definitely a defective switch.    ... View more

Not necessarily. Did you put another device, not just the gateway on in that same VLAN on the core switch? How about if you put two static IP'd devices on switch 2 ca they ping each other? Enable SSH and show the output of 'show switchport <interface to other switch>' on each swtich ... View more

OK.  Next thing to try is plug a couple of devices in VLAN 11 into both the CSW and SW2 and give them static addresses.  Can they ping each other?  If that works there is something more complicated going on.  ... View more

All I can say is that I've worked with multiple vendors (Cisco, Juniper, Palto Alto, and even PFsense) and haven't come across one yet that does an upstream query for its public IP. They all report the IP configured on the WAN port which is typically given out via DHCP by the ISP.  Unlike DHCP on a LAN where the client usually renews its lease with that same IP, ISPs typically change it every lease period.    My guess is that the reason they don't do it is that the upstream method to obtain that IP (google, whatismyip, ipchicken, etc) isn't in their control and if those providers changed urls or the the query format it would would require firmware updates to fix it. That's too much trouble. Where as an open source software such as the Dynamic Update Client can easily be refreshed with a yum or apt function. Additionally you would still have the very complicated issue that the upstream router is NATing which means that have to configure port forwarding on the upstream device and that NATing device isn't always under your control. Most people would have the router directly connected to the ISP with dynamic public IP, which is what the DDNS client is designed to do.   ... View more

So are you saying its reporting as a VLAN mismatch or simply that one device has VLAN 1 and one device has VLAN 4? That ussually doesn't happen unless one side is configured as a trunk and CDP will detect the mismatch.  Its only a warning to let you know that traffic is going to be retagged on the native VLAN.   In that scenario frames egressing in either direction would be untagged and upon ingress would get tagged with the PVID of the port (VLAN1 on the RV and VLAN 4 on the SG)  ... View more

Yes. On a trunk port if the Native VLAN is not specifically configured it forwards untagged traffic on the default VLAN.  Basically a managed switch forwards all untagged traffic on the PVID of the port.  The PVID is determined by one of the following settings   1) Explicitly set value for the trunk native VLAN ID, or 2) Explicitly set value access VLAN ID, or 3) Default VLAN ID for the switch if neither of the above is configured.   In my case the Router is not tagging and it will not receive traffic if the port is configured via either method 1 or 2 unless the Default VLAN ID for the entire switch is configured as the same as PVID on the port. While the FiOS router is the only device I have found to be affected by this, it is definitely an issue with the Sg300 as the end device is supposed to be completely agnostic to what the VLAN configuration on the switch is.  ... View more

If understand that correctly, you are saying that you have an upstream router that you control that has 192.168.3.x/24 and one that you don't control that is giving the 192.168.42.x/24 that are connected to the RV325 on the two WAN ports?   The DDNS client on the RV325 is going to report the IPs that are assigned to the two WAN ports. It does not do any upstream query like the Dynamic Update client in Linux.  It is working exactly as designed.    You have two options.  If they are capable see if the upstream routers can be configured in bridge mode so that the RV325 is layer-2 connected directly to the ISP side of those router/modems.  If you can't the other option is go out and buy two cheap 4 port unmanaged switches and put them in between the RV325 and the upstream routers. Then connect up two linux boxes to the 4 port switches and configure the Dynamic Update Client as shown in the NO-IP guides. I would recommend two Raspberry Pis as they are cheap and all they need to do is run the DUC to tell NO-IP what the upstream public IP is.    Is this only for outbound initiated connection or are you serving up something on the inside to the public such as a webserver behind the RV325 or a VPN from the RV325?  I assume so since there isn't much point to using DDNS if this is only for outbound connectivity. If you have to use option2, this is where that gets tricky.  Those two upstream routers are NAT'ing. For your solution to work at all you need to configure port forwarding on those two upstream routers to get those services to the RV325.       **Please mark helpful posts and solutions** ... View more

Generally Speaking, this is typically a issue (bug or undocumented feature) with the Captive Network Assistant (CNA). I have encountered variants of this story after "updates" on just about all mobile makes. The simplest way to test is when the captive portal comes up, close it and open the captive portal in chrome or firefox on the andriod phone. If it does the redirect after login, then the issue is the CNA. The issue is that the CNA is not handiing the re-direct URL off to the phones default browser. This is either caused by a bug or during an update the preference setting was lost in the phone. Either way the solution is outside your hands.   Verify that there is a default browser set in app preferences then try different default browsers to see if one will handle the hand-off better than others.  ... View more

What is your internal subnet?  I see that the two different ports are registering as 192.168.3.x and 192.168.42.x  typically 192.168 subnets are defaulted to /24 masks (255.255.255.0). In which case those two interfaces are reporting on two different subnets.  Where are they defined?  Are they YOUR private subnets or are you simply noting that they are private subnets (RFC 1918 addresses).  If they are not defined on YOUR device, what I suspect is happening is that your ISP is giving out RFC 1918 addresses on your connection and they are NATing upstream at their router.  Cable companies will often do this to conserve IPs.  They don't waste them sub netting to the customer. I've run into this before.  The ultimate solution I had to use was to configure a RaPi on the LAN with the Dynamic Update Client.  The Dynamic Update Client will query a public server to figure out the IP and send it to whichever service you configure.   NO-IP has guides on how to do this.    However the problem you are going to have is the dual WAN issue.  The small business routers don't support any method of policy based routing so I don't know of any way to force it out one interface or the other when it queries for its public IP. ... View more

I assume by network cable you mean the connection from the "internet".   The port for the internet router is showing down down. This sounds like a negotiation issue. I used to see this with ActionTec routers.  You said you have an unmangged switch and this works.  Try this.. connect a port from the unmanaged switch into the same port on the SG200 that the internet device WAS plugged into.  Does it come up?  If so then plug the internet device into the unmanaged switch.  If this works its becuase the internet device isn't able to negotiate speed and duplex with the SG200.  What you may have to do is fiddle with manually changing the port speed/duplex settings on the SG200 until it shows up up.  ... View more

I assume you mean that  you configured DHCP server scopes for  all the VLANs on the core switch.  Since you are getting the address via SW1 but not SW2 we know that the DHCP-server is accessible via that VLAN and that your VLAN interface is up. It sounds like you are explicitly setting the allowed vlans on the trunk.  Typically I find this to be a simple mistake where you allowed the VLAN on one side of the trunk, but didn't allow it on the other side. ... View more

On update 4 specifically.  VLAN 198 would be untagged on egress of any port that had its PVID set to 198.  Access ports are explicitly assigned the PVID. On trunk ports the PVID is the "Native" VLAN of the trunk. The FiOS router is connected to a access port.    Traffic would never be "redirected" to the default VLAN in any  IEEE compliant managed switch. On a modern managed switch all frames transiting from port to port are tagged ( to prevent VLAN hopping).  Untagged frames are tagged on ingress with the PVID of the port while tagged frames keep their existing tag field value. The default VLAN is simply the PVID of all ports that are not explicitly configured with a different PVID (ether access VLAN or native VLAN).  On older switches if a port was not explicitly configured this was simply sent across the switch untagged, which lead to the VLAN hopping vulnerability. Even then if the port was configured with a specific VLAN it was tagged with that ID and never gets re-tagged.  If traffic was "redirected" (retagged) with the default VLAN how would it know which VLAN the frame belonged to.  ... View more

No.  The Fios Router is just one of the layer-3 devices.  The other VLANs each have some other device connected to the switch acting as the IP gateway.  ... View more

I tested with an unmanaged switch in between and that didn't make a difference.  A managed switch with a default configuration (all ports in the default vlan 1 on the intermediate switch) in between the SG300 and the FioS router does make a difference, so a managed switch is at least rebuilding the frame coming out of the SG300.    Every VLAN in the topology gets layer-3 from an upstream device so moving  layer-3 onto the switch fundamentally changes a lot of what went into the architecture.   What I decided to do for now until Cisco fixes the bug is just set the default VLAN to 198 still in layer 2 mode. So far the only device I have found that is effected is the FiOS router. Thanks to Murphy it of course had to be a critical node in the architecture that has an issue.  If I find other devices on other VLANs that end up with the same issue, my solution will have to be buy a different brand switch.  ... View more

I'm not sure changing it to layer-3 would make a difference as my updates seem to indicate it goes beyond DHCP. Even if I static IP clients the FiOS router seems to drop frames unless it is in the Default VLAN defined on the SG300.  Unless you think that the frame exiting a non-tagged port would be different in layer-3 mode. It would still be layer 2 from the client to the router.     The next thing I am going to try is putting an unmanaged switch in between the router and the access mode port to see if it somehow 'corrects' the frame going to the FiOS router.  ... View more