DHCP Not Passed through :(
DHCP Not Passed through :(
Problem
I know there is an earlier thread with this name. However even with significant knowledge an many hours spend, I did not manage the pfSense IPV4-DHCP-server to hand out an address to a PC connected to the SX3008. Strange enough IPv6 seems to work.
I describe the relevant part of the set-up below, complete with pictures. Things like local DHCP-server functions are disabled.
IMHO it should just work, but it does not !!!! (at least using e.g. using Mikrotik switches there is no issue at all)
The PC tries:
- to identify the vlan gate way, but does not get the related arp responses
- sends DNCP-discover frames (which are not answered / the answer is not arriving the PC
- the PC broadcasts ARP Who Has messages
- the PC in the end generate an "Automatic Private IP (169.254.0.0/16)" and keeps trying but never receives an address
If I assing an IP-address manually to the PC I can communicate over the network as expected.
But, getting an IP-address via the DHCP-server NO WAY !!
Really no Idea how to get this working !!
Louis
Situation
I am using pfSense firewall & router in combination with th SX3008F switch. The switch is connected to pfSense with a lagg containing many vlan's. The oter SX3008 porst are connected to other devices mostly via trunks containing multiple vlan's. The vlan-interfaces/gateways and the dhcp servers are situated on pfSense.
One of the vlan's in the pfSense trunk, is the management vlan. I manage the device remotely via that vlan (vlan10) .
One of the interfaces is directly connected with a PC. The PC is not aware of vlan's. So the related vlan is setup like this.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
There is more which is not OK and that could be related. Here more starting with an outline from the situation.
The picture shows the router.firewall pfSense attached to a 1G-network below a Zyxel GS1920 switch and a 10G-network below a TL-SX3008F switch. Below those switches all kind of clients.
However there is something going terrrible wrong in, according my actual impression the communication between pfSense and teh SX3008. For absolutely unkown reasons, communication towards some clients are OK, where communication towards other clients (bizar even in the same subnet) are not OK.
Here some Behavoir examples. All connections are using vlans.
- vlan-Y client-C (PC), can access Clients A & B, however only
if you manually assign client-C with an IP
- Client A can be accessed via Client D
- Client B on the same vlan(!) can not be reached not pinged.
- client-C does can not connect with DHCP-server on pfSense
It seems that in comming packages can in certain situation,
not be delivered to the 10G clients.
Reason and conditions unkown !!!!
Note that comparable connections from pfSense to the Zyxel switch or a Mikrotik switch (and smaller netgear switches) are working based on the same principels without any issue.
Note that I spend many many hours trying to understand what what is happening and why it is not working as expected. Trying different settings, tools like wireshark etc.
- Copy Link
- Report Inappropriate Content
“The oter SX3008 porst are connected to other devices mostly via trunks containing multiple vlan's.”
That’s strange since trunks are meant to be used with VLAN-aware devices. Usually, the majority of devices are VLAN-unaware.
“The PC is not aware of vlan's.”
Is that PC connected to a trunk port? VLAN-unaware devices should be connected to access ports in port-based VLANs.
It is also strange that you haven’t mentioned PVIDs in your description at all, but PVIDs are extremely important in port-based VLANs. So, how did you set up those PVIDs?
- Copy Link
- Report Inappropriate Content
Yep PIVD are essential to define the vlan for untagged devices. The default is one for each port and all devices are interconnected. Exactly what I do not want. I am not using "vlan-1".
So the port to which the PC is connected has as PIVD the number ot the ^PC-vlan^. And in the vlan setup screen I defined the PC-connection as a untagged interface like this
Port-6 is the PC-connection. And as you can see I am using dummy vlans 100x to make sure that ports can not interconnect via vlan-1.
So, thanks for the replay but I think that I did set-up the PIVD's in a correct way.
Louis
- Copy Link
- Report Inappropriate Content
Okay, the Port 6 configuration looks fine to me, too. However, the LAG configuration looks strange. The first screenshot show LAG1 and Ports 1 and 2 in it. I assume it is that LAG1 you use to connect to the pfSense box. If so, why isn’t it a member of VLAN 17? Instead, the second screenshot shows LAG6 as untagged member of VLAN 17. What do you need that LAG6 for? .
Edit.
I might’ve misread the second screenshot. I haven't had my morning coffee, yet. However then, I’d like to see the VLAN configuration for LAG1.
- Copy Link
- Report Inappropriate Content
Yep there is one lagg containing multiple vlan's towards pfSense (ports 1 &2). One of those vlans (vlan17) is the vlan related to the PC.
And the picture in my post above related to vlan17 shows that UNIT-6 is untaged member of that vlan and LAG-1 is a tagged member of the VLAN.
so if I do not mis interpreted the gui, that seems to be correct.
Given the combination of the issues described in my second post, I verdict the LAG-communication. For that reason I just made a wireshark capure of the lagg towards the GS1920 and the lagg towards the SX3008. One thing hits me. The GS1920 is sending LLDP- and LACP-messages, the SX3008 is only sending LACP-messages. So I will have a look at the LLDP section of the SX3008
If that solves the problems, I will report here
- Copy Link
- Report Inappropriate Content
LLDP is a device discovery protocol. Some devices support it, some not. Even if it is supported, it may be disabled and that's fine. I don't think it plays any role here. One thing you may like to do is to check the port and LAG status. If that's okay, the switch configuration is probably fine so you may like to double check the configuration on the other side of the link. Good luck!
- Copy Link
- Report Inappropriate Content
I agree, I had a look at it dis some trails and I think it is just info for a management system.
I turned it off again
- Copy Link
- Report Inappropriate Content
I did some further testing using the pfSense package capture function
Related to the pinging the clients in VlanX. Wireshark shows that:
- the pings arriving from client D, are leaving pfSense via the VLAN-X gateway
- there are responses from client A but not from client B
- also not via the mngt vlan or so ( I did want to be sure there is not routed wrong)
Related to the PC not getting an address from the dhcp server
- on the pfSense PC-vlan interface is no IPv4 traffic at all, so also not from the DHCP-server
- there is IPv6
Traffic on the PC-vlan if the PC has a manual configured IPV4-address
- the PC has connectivity to internet etc
- and the traffic is passing via the pfSense PC-lan gateway, so it takes the correct path
These "measurements" are hopefully helping to understand the problem, but for the moment I am completely lost
- Copy Link
- Report Inappropriate Content
Been there, done that, feel the pain. When I find myself in a situation like that, I concentrate on the most fundamental issue, scale down and simplify. Get that DHCP issue resolved first. Don’t chase other issues before you resolve it. Disconnect any irrelevant devices. Remove that LAG. You can add them later. Stay focused. Forget about IPv6 and Internet.
You are setting a router-on-a-stick configuration. So, if a DHCP server is configured and active in the VLAN, a DHCP issue is cased by some VLAN misconfiguration. That is usually easy to resolve if the environment is simple. In your case, the switch part is simple, but the pfSense part can be complicated if you set it up yourself and perhaps run it in a VM. Maybe some pfSense community can be more helpful. I currently do not have pfSense in my environment so my knowledge of it is rusty.
- Copy Link
- Report Inappropriate Content
I understand what you are saying, hower note that this is absolutelely not the first time I configure a setup like this. And IMHO it should be easy. However what I am seeing now is bizar !!
You also should be aware that I bought this switch at least as a temporarely replacement for a bigger Mikrotik Switch (CRS317), which is defect. To a large extend the SX3008 is a 1:1 replacement of eight of the sixteen CRS317 ports. And the pfSense configuration is hardly changed at all.
So my estimation was that I would have it up and running in one lets say two hours. I have been spending days allready and it is still not working !
I am really thinking that there is a bug in the switch software !
Note that I was in a hurry to have the defect switch repacement. So, when the unit arrived I noticed that it was version 1 hwardware not the intended actual 1.6 harware.
My initial thought was to return the device. However given the fact that a) I urgently needed a new switch anb b) the software releases for the 1.0 hardware release where much newer tan those for the newer 1.6 release(!), did me decide to keep the device. First thing I did is update the software.
Whats ever related to the problems:
- the not working DHCP (dhcp server is pfsense), I use that on all my switches and devices
- the fact that I have two devices in the same vlan one reachable the other not (when arriving via the pfsense lagg)..... bizar
- in fact both problems make me think in the same direction some issue retated to (outgoing?) messages towards pfSense
(the same lag two device problem does not occur if I test from another SX3008 vlan)
The switch is part of my network and I also need that network to do tests. What I am going to do next is replacing the lag with a single trunk. To do that I have to change pfSense and the switch. But to be honest, if I can not solve the problem today perhaps tomorrow, I am going to buy another switch and returning this one or throwing it in the wastebasket
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1321
Replies: 16
Voters 0
No one has voted for it yet.