Am I missing some obvious crucial piece to getting this working as I had expected?
You musn't confuse the latency of traffic destined to the switch with the latency through the switch.
When you ping a VLAN interface on a switch, you are quite often hitting the CPU/Control plane, which in the case of most enterprise-grade switches, is not a very powerful ...
I was able to resolve the issue. On the Kemp (with HA pair) you have the option of using a "Virtual MAC Address". If this box isn't checked, then the MAC of a load balancer VIP is that of the physical interface of the active Kemp unit. If this box is checked, then the MAC address of the VIP is a VRRP MAC. As you mentioned above the VRRP RFC states that the ...
The main part about this is the switch IDs for the devices. If you have two switch stacks which BOTH have units 1 and 2 your interfaces are named 1/g1, 1/g2, 2/g1 etc. When they are combined into one stack the configuration of at least two will change.
Do backups of the configuration
Get a service window :-)
Shutdown two units, and join them to the ...
This can be done, see the page 15 of the Dell white paper on the subject here:
Specifically it says:
Merging Two Operational Stacks
The recommended procedure for merging two operational stacks is as
Always power off all units in one stack before ...
(converted from comments)
The "Total Power" figure should show what the PSU can deliver, regardless of what's currently in use. The "0 W" pretty clearly shows there's something wrong.
Possibly, the internal PoE PSU has died or is disconnected/removed. Also, there may be an external PoE PSU connected that isn't powered or has died.
There's no default gw defined by default on Powerconnect 5500 series switches. Use no ip default-gateway command to remove or ip default-gateway <gw address> to change. The CLI manual is here. Sounds like it would be a good thing to read up on.
When testing networking connections, don't use windows machines.
My firewall was set to allow ICMP traffic from any subnet on any domain profile yet it was still blocking the packets.
Turning the firewall off completely allowed the traffic through, so the routing is working.
Also, pings probably aren't the best way to test network connectivity.
The multicast address you're looking for is 18.104.22.168 [mac: 01005e.000012]. That is the control channel for all VRRP nodes.  Unless KEMP changed the code, CARP (UCARP) originates traffic using the VRRP unicast MAC [00005e.0001xx] -- that's where a switch would naturally learn it.
If you don't have a querier on the network (presumably in every ...
You're (192.168.0.164 ) directly connected to the switch (10.168.0.106) you're SSH'in into and you get dup ACK and retransmit... There is something not right , seems that the Network Gremlins are hungry.
What does the switches error counters say?
Also note that some devices puts traffic to/from the control plane at a lower priority than the data plane. ...
Sean, your setup seems correct if you're making it from one VLAN to the next; which you can see when you traceroute from one switch IP to the next. If you aren't very familiar with networking, try making your life easier by simplifying your setup. Give this setup a go:
Switchport - Gig1/0/10
IP Address - 10.1.10.100/24
VLAN - 10
Never having worked on one, I took a look at the documentation and would have to say that yes it can, at least in some limited fashion.
Based on the spec sheet for this product line, it would seem to indicate it can as it supports static routes, dynamic routes, and specifies "Line-rate Layer 3 routing" as well as the number of RIP and VLAN routing ...
QoS mechanisms only come into effect when there is congestion on the link. If you have a 20M circuit but connected to a 1G interface, your device will never recognize the congestion because the traffic never reaches 1G.
You need to implement inbound policing and outbound traffic shaping at your CIR (commited information rate) of your circuit, which would ...
You will have difficulties towards configuring dhcp on the dell 5524 which is a layer 2 switch. A good switch in my experience, but it isn't a layer 3 switch.
You should use a layer 3 switch that provides the wanted dhcp options and/or relay the dhcp packets from your 5524 to a dedicated dhcp server (*nix dhcpd or window$ dhcp).
See this link for some more ...
According to this, the P means PoE
You could also search support.dell.com with the serial number on the switch and it should tell you exactly what model it is.
Setting the subnet to a /16 might cause some issues with broadcasts. Remember that your broadcast traffic is always the last address (the .255). I'm not sure what else might happen. Haven't tried it.
If traffic needs to travel between VLANs, you need to route between the VLANs. The configuration of each VLAN's addressing should match the devices on the ...
The only thing that I have spotted at the moment is that you have no default route. Currently you have traffic only destined to x.x.8.164/30 routed out of VLAN 4010.
If this interface goes to the internet I would expect something like the following to be added to tell it that anything not found in the routing table (ie. Internet), send out out the vlan that ...
I was able to solve this as the host I was connected to was also connected to a second port on the switch via a different subnet. I used a backgrounded screen session to keep the connection open and keep delivering commands even when my own connection disappeared. It also allowed me to script a reboot command in case the update failed and I couldn't get in.
I posted this on the other thread but I resolved the problem:
I was able to resolve the issue. On the Kemp (with HA pair) you have the option of using a "Virtual MAC Address". If this box isn't checked, then the MAC of a load balancer VIP is that of the physical interface of the active Kemp unit. If this box is checked, then the MAC address of the VIP is a ...
The answer is yes. This white paper describes how to use ACLs and routing maps handle inter-VLAN traffic in a more secure way.
Set the Dell switch to 'managed mode' and create an external vlan for all devices outside your NAT router (in your case 45-48 for the two servers, internet and NAT router's outside interface).
If you want to get further into the networking part, then move the rest of your ports off of vlan 1 to something else, but for home use you would be OK.
I would ...
The first thing I'd verify is that the phone is actually tagging frames with that VLAN ID, perhaps with a network tap or port mirror (which might not quite work right on this switch)
If you manually had configured the phone to do that and you know it's working, this is probably a bug in the software.
If not, manually set it on the phone or configure LLDP-...