Using a LAN port on SG-3100 for WAN interface to Frontier ONT
-
@stephenw10 said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:
Yeah, with Frontier is seems like the only issue is that they are sending DHCP replies priority tagged (vlan0) so if you strip those it will work fine.
In the 3100 that's easily achievable because of the built in switch. There's no need to setup two ports as a separate switch. Just separate one port as a new interface and use that as the WAN. The traffic traffic coming into the switch will be tagged with the internal VLAN and passed as expected.
So exactly like the guide you linked to here: https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/switch-overview.html
But at step 8 instead of assigning the VLAN as a new interface, assign WAN to use 'VLAN 4084 on mvneta1'.Now you also have the WAN port (mvneta2) free to assign and use if you want.
Steve
Steve,
I'm curious, and may try this before you reply, as to why you can't just add the vlan to the wan port then assign that vlan as the wan?
What would be the difference? -
@cmccolgan You're setting a new port as the WAN so you will have to do 9-14 for sure. Can't say anything about after that since I don't have a Netgate appliance.
-
@stephenw10 Just tried it, wouldn't work.
Added vlan 4094 to em0 (my WAN port), tried to assign the vlan as WAN and every time I clicked save it would revert back to em0.
Is this because I have rules setup on it maybe? -
@jarhead said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:
I'm curious, and may try this before you reply, as to why you can't just add the vlan to the wan port then assign that vlan as the wan?
That won't work, as you found, because it doesn't go through the switch. It needs to go through the switch in order to strip the VLAN0 tag so the NIC/driver will accept it. In this example we are also retagging it 4084.
-
@cmccolgan At step 8 assign the WAN to the new VLAN like this:
That should be all that's required.
Steve
-
@stephenw10
Thanks @stephenw10 . So decided to try this on my existing Spectrum Cable connection just to test out making the interface changes. I have no issue using the WAN port in a default config on the SG-3100 with Spectrum so figured if I made the WAN port as described above the LAN 4 port it should work fine.Changes in the interface went fine but when I switched from being plugged into the WAN port to being plugged into LAN 4 I was unable to get an IP address via DHCP. See:
May 29 09:03:08 pfSense dhclient: PREINIT May 29 09:03:08 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 1 May 29 09:03:09 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 1 May 29 09:03:10 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 2 May 29 09:03:12 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 2 May 29 09:03:14 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 4 May 29 09:03:18 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 9 May 29 09:03:27 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 8 May 29 09:03:35 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 19 May 29 09:03:54 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 11 May 29 09:04:05 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 4 May 29 09:04:09 pfSense dhclient[86217]: No DHCPOFFERS received. May 29 09:04:09 pfSense dhclient[86217]: No working leases in persistent database - sleeping. May 29 09:04:09 pfSense dhclient: FAIL
With the idea that this might be that Spectrum was expecting the MAC address of my old interface I also tried it where the mvneta1.4084 interface was spoofing the mvneta2 MAC address. Dhclient showed the same behavior. When I switched my WAN interface back to mvneta2 I was able to get an IP again:
May 29 09:20:15 pfSense dhclient: PREINIT May 29 09:20:15 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67 May 29 09:20:17 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67 May 29 09:20:21 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67 May 29 09:20:26 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 1 May 29 09:20:27 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2 May 29 09:20:29 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2 May 29 09:20:31 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 3 May 29 09:20:34 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7 May 29 09:20:41 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 9 May 29 09:20:50 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 14 May 29 09:21:04 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 10 May 29 09:21:14 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 13 May 29 09:21:14 pfSense dhclient[50719]: DHCPOFFER from XXX.XXX.XXX.XXX May 29 09:21:14 pfSense dhclient: ARPSEND May 29 09:21:16 pfSense dhclient: ARPCHECK May 29 09:21:16 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67 May 29 09:21:16 pfSense dhclient[50719]: DHCPACK from XXX.XXX.XXX.XXX May 29 09:21:16 pfSense dhclient: BOUND May 29 09:21:16 pfSense dhclient: Starting add_new_address() May 29 09:21:16 pfSense dhclient: ifconfig mvneta2 inet XXX.XXX.XXX.XXX netmask 255.255.224.0 broadcast 255.255.255.255 May 29 09:21:16 pfSense dhclient: New IP Address (mvneta2): XXX.XXX.XXX.XXX May 29 09:21:16 pfSense dhclient: New Subnet Mask (mvneta2): 255.255.224.0 May 29 09:21:16 pfSense dhclient: New Broadcast Address (mvneta2): 255.255.255.255 May 29 09:21:16 pfSense dhclient: New Routers (mvneta2): XXX.XXX.XXX.XXX May 29 09:21:16 pfSense dhclient: Adding new routes to interface: mvneta2 May 29 09:21:16 pfSense dhclient: /sbin/route add default XXX.XXX.XXX.XXX May 29 09:21:16 pfSense dhclient: Creating resolv.conf May 29 09:21:16 pfSense dhclient[50719]: bound to XXX.XXX.XXX.XXX -- renewal in 9152 seconds.
Just to note that after switching interfaces both times I power cycled the cable modem. If I don't do this then while I see DHCP activity from Spectrum in my default config, never saw any DHCP activity from Spectrum in the mvneta1.4084 config, the interface never properly binds (seems like a timing issue).
I didn't try manually assigning the IP I normally get assigned from Spectrum and then seeing if I could ping the Spectrum gateway when I had mvneta1.4084 as the WAN interface but when I was using mvneta1.4084 as WAN I wasn't seeing any DHCP offers from Spectrum which I always see even if they don't bind in my default config.
Any thoughts here? This is just trying out the config you suggested on a known good internet connection with the thought that if it won't work with this it most likely won't work with Frontier.
-
Urgh, sorry I'm not sure what happened yesterday. Clearly not enough coffee when I read that switch doc!
You still need to complete steps 15-26 there to setup the switch.If you see no replies it sounds like you may not have set the PVID on the switch port?
Steve
-
@stephenw10
Yep that did it. The native WAN port and ETH 4 now both work as uplink ports depending on if I have them assigned to the WAN interface. I'll update this thread after Thursday on my experience with Frontier and if I can use the native WAN interface or need to use the procedure that was defined here.Thanks for the all the help. Appreciate it!
-
So an update.
Got Frontier Fiber installed at home today. Several interesting findings.
-
I'm getting both phone and internet service via Frontier. Frontier provisioned my phone on to their Arris router. I asked the tech to have frontier provision the phone to the ONT but he said it would cause a cancellation of the service appointment but I could do that with a call later. As a note the Frontier tech on site (David) was awesome.
-
The ONT provided was not the FOX222 but the FRX523 which is a brand new ONT that Frontier is using for this new deployment in Santa Monica / Pacific Palisades.
As such config was ONT->Arris->SG-3100
Did speed test from Arris was getting 940 Mbit Symmetric. Didn't like having the Arris in front so changed config to be:
ONT->SG-3100(Lan Port 4)->Arris
In this config best I got was 729 Mbit Down / 802 Mbit Up. Good but not line speed. In this config I was able to maintain phone service however by having the phone line plugged into the Arris that was getting connectivity from the SG-3100.
As it turns out Frontier isn't doing the VLAN 0 tagging for DHCP in this area's deployment so I was able to change the config to be:
ONT->SG-3100(Native WAN Port)->Arris
With this config I was able to get 940 Mbit Symmetric. In reading various posts it seems that there are ineffeciencies in using a LAN port at these speeds and I was getting a perf hit by using LAN 4 as my WAN port. Fortunately for me I didn't need to use LAN 4 as discussed earlier in this post and was able to use the native WAN port.
One thing I did need to do to get linespeed on the install was disable ntopng. I like running ntopng but it is a CPU hog and with this running I was not able to get line speed. Guess I'm in the market now to get a 6100?
Anyways that's the update. Thanks everyone for their help and if anyone want pictures of the FRX523 I can post them here. Seems like such a new ONT I can find very little about it on the Internet.
-
-
@cmccolgan said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:
In reading various posts it seems that there are ineffeciencies in using a LAN port at these speeds and I was getting a perf hit by using LAN 4 as my WAN port.
What you were probably hitting there was the shared link between the LAN4 and one of the other LAN ports if that's where you were testing from. In that config both ports are sharing a single NIC. The NIC can send and receive at 1G simultaneously so if you have a udp stream you should see very close to line rate. However for TCP tests the reply traffic moving the other way decreases the available bandwidth. When the path uses two NICs that isn't an issue. So, if you are using a LAN port as the WAN, testing from a client on OPT will likely show the same results you see using the WAN port.
Steve