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

Reply via email to