Recent content by infoMatt

Not too much of a pain if you have an AD domain and all client PCs are joined to the domain itself. Deploy a GPO policy to enable authentication to the NICs, configure the switch to authenticate via RADIUS to the NPS service on the DC and hey presto you've effectively locked down your network...

Hmmm... 802.1x enters the chat. :)

I did absolutely nothing... all credit goes to @fohdeesha ;) But I'm glad that you've managed to solve the issue!

Hmmm... very very strange... Why is the switch responding with mac address "01:92:00:00:00:00"? Hmmmm.... Now I am hitting the table with my forehead too :D Maybe @fohdeesha has seen it before.

No need to apologize... everyone has started from zero at some point in their life. ;) And every sysadmin faces those days where you can't really find the solution for hours, where maybe a colleague says "have you tried doing this or that?"... "Damn it!". It's the life. It shouldn't be, as a...

Which of the two addresses have you tried? You've defined 192.168.1.1/24 on Mgmt and 192.168.2.1/24 on VE1. I suspect there's a routing problem, and I am not sure if the switch can route between management and VEs... I am not sure, but you might be able to specify source address for the tftp...

You can't, because the packets have a TTL=1 and so they will expire at the first router. You have to install a reflector like Avahi in a linux VM or similar, and give it an address (and thus an interface, it could be on a trunk) on each VLAN where you want to forward to the queries and replies.

I don't know the details about what DBMS you are using under the hood, but for example PostgreSQL has a very useful feature called Write Ahead Log (WAL), and it can be configured to split (and archive) the files created by size or by timeout. I imagine that most DBMS platforms have something...

Don't worry too much, everyone has learned the lessons the hard way by breaking something... at worst case, simply don't save to startup config and pull the plug :p Now I am the one missing someting as I don't know about how the USG handles NAT for networks not defined... I don't think it goes...

There's no need for an helper address if the DHCP server is on the same broadcast domain (ie. the same VLAN). That might be normal because the network 192.168.99.0/24 is locally connected on the USG, so it would forward it directly and not via 192.168.25.1, so if you've defined some policies...

Yes, it's a mainly blank config. I have to apologize, I hadn't noticed the behavior that @fohdeesha said, as every time I've reconfigured the switch I've assigned a static IP to a VE. Sorry :( I was thinking at the route-only interfaces as the only way a port could have a directly assigned IP...

Please post a "show run" output, but to me there's something strange on your configuration... Have you issued a "route-only" on ethe 1/1/1? In case, yes, in can't be tagged or untagged, as it will work as a pure layer3 only interface, no switching operations can be done. But it may cause havoc...

Please check if you have already a VE defined on this VLAN, and it should, as you said that it took an IP address. Yes, but you have to enable "dual mode" on an interface to make it accept both tagged and untagged frames. It is written on the documentation that @fohdeesha made available on the...

You have to enable on a router interface, not on a port (unless it is a pure layer 3 interface, ie. "no switchport"), and the interface tied to your DHCP server must be an untagged member of the same VLAN that contains the router interface. Please, start from the first message of this thread...

Not only that, but they tend to flood the network with a lot of multicast/broadcast traffic (as for example, every discovery that runs on top of mDNS, such as Chromecast and Bonjour, to name a few). Usually, multicast flows are being sent to the switch CPU for IGMP Snooping and flow control, so...