On 14-03-22 01:09 PM, Wade Blackwell wrote:
Good morning all from the very dry Central Coast of California,
So Still struggling with PF on esxi 5.1 and Charter DHCP
responses never being received. Mark I did confirm the cheap SMB
switch I have doesn't support DHCP snooping. Sean I did confirm that
CDP was disabled on the Charter side. I made 3 changes one at a time
and I was hoping that one of them would affect a change, no such luck.
Changes in order;
moved from a standard virtual switch (esxi 5.1) to a distributed
virtual switch
changed the interface type in PF to VMXnet2 from e1000
and finally
tried trunking all the way down to the OS creating vlan interfaces on
the PF (not sure why I thought more abstraction from the hardware
would be better)
So all that said I can still see allot of layer 2 activity on the
interface, Gratuitous arps and dhcp requests and offers being bandied
about but I never do see my responses come back. I see them head out
never to return. Anyone else seeing this (with any provider) issue
with PF in software? I'm fairly remote and ATT PPoE is fine for backup
but it's painfully slow for VOIP and every day use. Any suggestions
would be fabulous. Thanks all.
On Wed, Oct 30, 2013 at 4:54 PM, Sean Cavanaugh
<[email protected] <mailto:[email protected]>> wrote:
Make sure to set “no cdp enable” on the port that’s going to your
cable modem. A lot of cable companies will shut down connections
that broadcast those by default so as not to broadcast the
networks together.
I had same issue with my Comcast connection until I found out
about the CDP issue.
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Wade Blackwell
*Sent:* Saturday, October 26, 2013 4:00 PM
*To:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Subject:* [pfSense] 802.1q dhcp and pf 2.1 and esxi 5.0
I have *2.1-RELEASE *(amd64) running on esxi 5.0 with a
Cisco managed L2 switch (SG200-26) in between esxi and the charter
cable modem. I see my dhcp discovers go out (broadcast) I never
see any dhcp traffic come back. Charter's been out a few times,
they did determine that they see my discover and they respond
though I don't see the reply. With a dedicated interface they can
get an address off the modem. ASCII art below;
charter cable modem--g24 cisco vlan 5---esxi vlan5--pf em0.
I've tried this dedicating a vnic to a standalone vswitch with no
802.1q and I've tried 802.1q on the esxi side. The cable modem
port is always an access port in vlan 5. STP has been disabled on
the charter modem port. Every port has portfast enabled and the
mac timers have been cranked down to the minimum, 10 seconds I
believe. I've captured traffic from vlan 5 and g24 (cable modem
port) and seen the same thing, dhcp discovers go out, nothing
comes back. I'm thinking there has to be a handful of folks on
this list who have dealt with this and succeeded. Any advice would
be fabulous, I'd like to keep my L3 in software if I can. Thanks
so much.
Start over from first principles, then.
1. Plug a laptop or PC directly into the Charter modem. Verify that it
gets a DHCP-assigned IP.
2. Run the pfSense LiveCD or USB image on that same hardware. Verify
that it gets an DHCP-assigned IP.
3. Repeat with a different NIC (use another PC/laptop if necessary);
maybe Charter limits the # of distinct MAC addresses the modem will
learn (my local cableco does this). Rebooting the modem is usually
sufficient to clear that, but some carriers require a call to tech support.
4. Connect a dedicated pNIC on the ESXi box to the cable modem; create a
dedicated vSwitch and a dedicated vKernel port set to DHCP; verify it
gets a DHCP-assigned IP.
5. Remove the vKernel port and create a vNIC; assign that to the pfSense
VM. Verify it gets a DHCP-assigned IP.
6. You can also try hardcoding the MAC address of the vNIC to be the
same as one of the previously-functional NICs, if it's a
#-of-MAC-addresses problem.
7. Lastly, do all this again through the switch.
Yes, that's a fair bit of work, but it should show you 100% conclusively
where the problem lies. I'm betting the problem will either manifest at
step #2 or at step #7.
--
-Adam Thompson
[email protected]
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list