@JasGot said in Need to better understand IP Helper for accessing Windows DHCP Server from VLAN.:

@Dashrender said in Need to better understand IP Helper for accessing Windows DHCP Server from VLAN.:

did you say you have Unifi APs? If so, what firmware?
https://community.ui.com/releases/UAP-USW-Firmware-4-0-69-10871/245e428c-d111-4b9d-a550-ec0cc86ef646?page=12

I saw that too, thanks. I have all Unifi Ap-AC-Pro with 4.0.66.10822 firmware. I have the same experience with all firmware versions. I went back about ten revisions.

I've been having some network performance issues at home since upgrading to 4.0.69.xxx - though I didn't put 2 and 2 together until I was researching fixing my Cloud Key and ran into that thread.

@Dashrender said in Cisco ASA:

@Jimmy9008 said in Cisco ASA:

A and B can also RDP/ping devices sitting on C.

If this is true, it's just a matter of rules/route allowing C back to A/B or a route specifically for C -> A/B.

172.16.0.0 vlan… switch IP = 172.16.0.1, ASA = N/A, gateway on the vlan is 172.16.0.1 (the switch)

this is legacy. What appears to happen is that the switch has 0.0.0.0 set to 192.168.50.10 (the ASA) on a vlan2. So, traffic from 172.16.0.0 hits the switch IP at 172.16.0.1, then hope out 0.0.0.0
^ I think its this that's causing the issue.

This should be fine, this is what allows the C network to get to the internet

so, when on the 172.16.0.0 network, the request goes to the switch's IP (172.16.0.1) which forwards it to 192.168.50.10 (the ASA), The ASA then doesn't have a rule allowing traffic from 172.16.0.0 to talk to 10.x, so it just dumps the traffic.

At least that's what it looks like to me at this time.

“C” network really?

Yes, if you are setting physical ports to a VLAN, then they are acting like a physically different switch on those ports. So attaching another physical switch to one of those ports would make it a switch on that VLAN.

Is there a limit to how many trunks you can use?

@Jimmy9008 said in VLAN on Dell N4064 Stacked:

Im guessing 'U' is fine. As I want vLAN2 to pass traffic where the device has already set vlan2 in its NIC. If the LAG is set to 'T', all traffic will be set to vlan2, right? Even when from vLan1/default...

I think it's better to tag every vlan in both ends. Then you can be certain traffic ends up on the same vlan on the other switch stack.

@scottalanmiller said in PVLAN (private VLAN) in the switch - are you using it?:

PVLAN, or Port Isolation as I think most of us know it, is one of the better uses of VLAN tech. The idea is for extreme environments (not really SMB generally) when normal security measures are not enough, that you make an individual VLAN for every single device on the network so that you control via central firewall a second layer of access for every single port that there is.

There are certainly legit cases for this. And I've worked for one of those places. But it's super rare. It is a lot of work, requires gear that supports it, and adds a lot of complication that you have to consider. It also adds a good deal of security.

In the SMB, most places have over the top security already and zero day threats rarely threaten OS level firewalls. So PVLAN, while legit, rarely has appreciable value to an SMB. But when you need that "second firewall per device", then yes, it's definitely the way to go.

Makes sense, but I'm thinking it doesn't have to be that much more work if you can apply automation to switch management as well.

I think you can do port isolation on the virtual switches in VM hosts in the same way as the physical ones. I understand that at least VMware has had it for a long time so assume other have it now as well.

Cisco is the king of Vlans

@dustinb3403 said in Confirming QoS for VOIP on Procurve 2848:

Ok cool.

Now looking at another switch 46 and 48 have a priority of 7, and 26 a priority of 4. (without an override).

Should I set everything to be like below?

46-7
48-6
26-4

Doesn't really matter. If you have no traffic on any other DSCP tags those priorities never apply.

Also does not matter much if you are not saturating the switch port in the first place.

@JaredBusch said in Unifi switch - tagged traffic issues:

@Dashrender said in Unifi switch - tagged traffic issues:

Found the problem - the uplink from my Unifi to my core switch, VLAN 2 wasn't allowed on the connection.

Enabled VLAN2, problem solved.

Aww the little things.

on which switch.

Also, reinforcing the issue with VLAN complicating things.

The core switch, in my case an HP 2824.

I don't disagree that VLANs can/do add complication. But in this case it was pre-existing complication that I had to work through, not remove at this point.

@Mike-Davis said in ubnt guest wireless or separate VLAN?:

My understanding of how Ubiquiti handles guest mode is that it drops packets destined for internal networks. What I don't know is like I think some others were getting at - what if the user tries to go to another local subnet outside the subnet their on. I guess I'll just keep the VLAN thing.

My understanding is that it totally drops those packets too. In some ways, that makes it more secure than a VLAN because just hijacking a physical switch is not enough to grab the packets.

Added: https://mangolassi.it/topic/9519/voip-pstn-gateways

@pchiodo said:

@scottalanmiller We were attempting "NSLOOKUP 172.16.2.110" and receiving the stated error. As per my previous response, I think we got it fixed by adding the reverse lookup zone, and allowing it time to propagate.

Interesting.. for some reason I thought you were trying to NSLOOKUP using the client as a DNS server, which of course would fail.

Sounds like you phone is not putting the PC poet on VLAN 1

@dengelhardt that's a good point that people often miss - there are cases where using VLANs unnecessarily can cause traffic to have to "loop" through a router to return to the same device. In the case of VoIP phones acting as small switches at the desk it's the switch inside the phone doing it.

I had to deal with a network just a few weeks ago that had five routers and three switches, one of which was still on FastEthernet (10/100.)
They managed to make nearly all traffic have to pass through the slow switch for nearly everything. And some things looped through routers that were attached on both ends to the same VLAN!! It was insane.

@slazer2au said in Does VTP update the Description of vlans?:

@Duffney
It takes the vlan database of the server switch with the highest revision and sends it to every other switch in the VTP domain.

Be careful though, VTP is a double edge sword.

As are VLANs themselves! 🙂

Tags added.