Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.




2776 posts

Uber Geek


# 142808 25-Mar-2014 12:33
Send private message

Hi

I have just had ultra fibre installed through Telecom. I am in Christchurch so it is Enable fibre.

Has anyone had success in connecting a Fortigate router connected directly to the ONT to handle the PPPoE?

The Telecom supplied modem works fine, but the Fortigate fails to connect.

Even if you don't have a Fortigate, any tricks learned from using other non ISP supplied routers would be helpful.

Thanks in advance.


Create new topic
21276 posts

Uber Geek

Trusted
Lifetime subscriber

  # 1012386 25-Mar-2014 12:38
Send private message

What model and OS Version?


3496 posts

Uber Geek

Trusted

  # 1012394 25-Mar-2014 12:53
Send private message

Does enable need vlan10?




Speedtest 2019-10-14


 
 
 
 


21276 posts

Uber Geek

Trusted
Lifetime subscriber

  # 1012395 25-Mar-2014 12:56
Send private message

Zeon: Does enable need vlan10?


Depends if tagging is enabled, it can be or not, it's at the RSP(or end user) request. 


719 posts

Ultimate Geek

Trusted
Spark NZ

  # 1012406 25-Mar-2014 13:02
One person supports this post
Send private message

Yes, you'll need to set the WAN frames to VLAN 10.




My views are my own, and may not necessarily represent those of my employer.




2776 posts

Uber Geek


  # 1012560 25-Mar-2014 16:41
Send private message

Thanks for the replies.

It's a FortiWiFi 60C running 5.0 patch 5

My reply is a bit late because Gen-i decided to cut off our ADSL before I had even got the Fibre on the Fortigate up or done any testing.

VLAN with ID 10 worked, so thanks for that.

I've been frantically reconfiguring the firewall to get us up and all our rules back in place on the newly configured interface. Not how I planned to spend the afternoon, the plan had been to leisurely test the fibre and cut over once everything was happy and preconfigured (but a mistake at Gen-i put an end to that idea).

Another question that someone here smarter than me can probably answer (and the main reason I wanted to thoroughly test the Fortigate before cutting over). It's a little long so I hope it makes sense:

Config settings from Gen-i say that any third party router "Must support MTU of 1500 bytes as per RFC4638. If RFC4638 is not supported then the modem must support MSS clamping to avoid any path mtu issues".

Fortinet's list of supported RFCs does not list 4638.

The response I got from Fortinet was "MTU size of all interfaces is 1500 by default. If the ISP device is set to allow 1500B frames or 1492 as in most PPPoE connections, it should be fine. If they have the MTU bigger that 1500, then you need to override and set the larger value."

I'm not 100% confident in the response as it seems to contradict some of their own documentation, and I have had some incorrect info from them before.

As it now stands it is up and appears to be running fine, is their a way I can test for MTU problems? Or does anyone know if I should be manually setting MTU to 1500?

Thanks

719 posts

Ultimate Geek

Trusted
Spark NZ

  # 1012633 25-Mar-2014 18:46
Send private message

MTU is a tricky topic.  I have no idea how familiar you are with MTU (layer 2 payload size) and it's relation to MSS (layer 4 (TCP) payload size).

Telecom will support either the 1492 or the 1500 byte PPP MTU.
If your device is negotiating a 1500 byte PPP MTU, then it need not support MSS clamping as it will support a full 1500 byte IP packet - which is what Ethernet will support by default.
It's only if your device wanted 1492 wherein it must support MSS clamping.  What MSS clamping does is to artifically force the negotiated Maximum (TCP) Segement Size (MSS) down to 1452 in order to fit within the 1492 PPP payload size (1452 + 20 byte TCP header + 20 byte IP header = 1492).  1492 + 8 byte PPP header = 1500 byte MTU, which Ethernet will support by default.
I would say it'd be very rare for a PPPoE device not to be able to support MSS clamping.


RFC4638 is a method for both ends of a PPPoE link to advise each other that they can support a full 1500 byte (in this case) PPP payload, which means a 1508 Ethernet MTU.
From what you're saying, your device may not support this. 
That is ok, but it will need to support MSS clamping, which it's almost unheard of for a device not to.

So to answer your question, if it's set to 1492 and there are some websites you cannot access, then more than likely your modem doesn't support MSS clamping. 
I'm not familiar off the top of my head which sites require a full 1500 byte MTU and which do not.  I know that about 5 years ago www.download.com would try and negotiate a 1500 byte MTU, but can't guarantee that is still the case.

There are a number of ways to be sure that your device supports MSS-camping, but none of them too straight forward.  E.g. mirror the WAN port to one of the Eth ports on the LAN interface, and compare traces (using wireshark) off your pc and the mirror port to see if the device is lowering the requested MSS values within the TCP headers.  No idea how technical you are though, so that may all be greek to you...




My views are my own, and may not necessarily represent those of my employer.


1948 posts

Uber Geek
Inactive user


  # 1012701 25-Mar-2014 20:20
Send private message

networkn:
Zeon: Does enable need vlan10?


Depends if tagging is enabled, it can be or not, it's at the RSP(or end user) request. 



Just a heads up on that.. all devices connected to Telecom Retail UFB you need PPPoE over vlan 10 tagging for it to work. This isn't optional or something that can changed on a per subscriber basis for any CPE that doesn't support vlan10 tagging over PPPoE.

I'm also 99.9% sure that also applies to Gen-I too..

 
 
 
 




2776 posts

Uber Geek


  # 1012916 26-Mar-2014 09:31
Send private message

cbrpilot: MTU is a tricky topic.  I have no idea how familiar you are with MTU (layer 2 payload size) and it's relation to MSS (layer 4 (TCP) payload size).

Telecom will support either the 1492 or the 1500 byte PPP MTU.
If your device is negotiating a 1500 byte PPP MTU, then it need not support MSS clamping as it will support a full 1500 byte IP packet - which is what Ethernet will support by default.
It's only if your device wanted 1492 wherein it must support MSS clamping.  What MSS clamping does is to artifically force the negotiated Maximum (TCP) Segement Size (MSS) down to 1452 in order to fit within the 1492 PPP payload size (1452 + 20 byte TCP header + 20 byte IP header = 1492).  1492 + 8 byte PPP header = 1500 byte MTU, which Ethernet will support by default.
I would say it'd be very rare for a PPPoE device not to be able to support MSS clamping.


RFC4638 is a method for both ends of a PPPoE link to advise each other that they can support a full 1500 byte (in this case) PPP payload, which means a 1508 Ethernet MTU.
From what you're saying, your device may not support this. 
That is ok, but it will need to support MSS clamping, which it's almost unheard of for a device not to.

So to answer your question, if it's set to 1492 and there are some websites you cannot access, then more than likely your modem doesn't support MSS clamping. 
I'm not familiar off the top of my head which sites require a full 1500 byte MTU and which do not.  I know that about 5 years ago www.download.com would try and negotiate a 1500 byte MTU, but can't guarantee that is still the case.

There are a number of ways to be sure that your device supports MSS-camping, but none of them too straight forward.  E.g. mirror the WAN port to one of the Eth ports on the LAN interface, and compare traces (using wireshark) off your pc and the mirror port to see if the device is lowering the requested MSS values within the TCP headers.  No idea how technical you are though, so that may all be greek to you...


I can follow a good portion of that.

You say "Telecom will support either the 1492 or the 1500 byte PPP MTU", wouldn't that mean the router doesn't need to support RFC4638?

My concern was the Fortinet guy might be talking about the Ethernet frame size being 1500 and not realizing about the 8 byte PPPoE overhead (which as you said makes 1508).

I tried download.com and it only half loaded the first time, but worked fine second try - so not sure if that means anything or not.

MSS clamping I admit I am not familiar with, is this generally something that happens automatically on the router or has to be configured?

We host an Exchange server, so my main concern right now is mail flow. This may be a dumb question, but could MTU problems cause mail loss (either incoming or outgoing) without an NDR?

719 posts

Ultimate Geek

Trusted
Spark NZ

  # 1012960 26-Mar-2014 10:03
One person supports this post
Send private message

The modem only needs to support RFC4638 in order to be able to run 1500 byte  PPP MTU.  What that does is to include an extra tag into the PPPoE Discovery packets called PPP-Max-Payload (off the top of my head) which tells the far end that it's ok to negotiate a 1500 byte PPP MTU, with the full knowledge that it will mean jumbo ethernet frames (i.e. >1500 bytes of payload).

I have no idea about download.com anymore, and don't currently have the tools to look into it.  If it loaded fully, then it's probably fine.

MSS clamping should be automatic.

Personally I'm not a mail expert, so I'm not sure I can accurately answer your question. I.e. please take what I say in regards to mail with a grain of salt.   What will generally happen if you're having an MTU issue will be that either the frames that are too big will arrive at the Broadband Network Gateway (BNG) (which is the router at the other end of the PPP link) and get fragmented there, and sent for delivery to your modem (and reassembled there).  No problems here.  The problems will occur if one or both ends set the "Do Not Fragment" bit in the IP header - which will cause oversize frames to be dropped instead of fragmented.  I think that's dependant on the OS and software at the far end. 

Given the packet loss and the fact that mail protocols use TCP, I can't imagine a world where you'd get a silent failure here.  I.e. you'll be getting error messages saying things like it lost communication with the mail server or similar. 

Hope that helps.




My views are my own, and may not necessarily represent those of my employer.




2776 posts

Uber Geek


  # 1012991 26-Mar-2014 10:29
Send private message

cbrpilot: The modem only needs to support RFC4638 in order to be able to run 1500 byte  PPP MTU.  What that does is to include an extra tag into the PPPoE Discovery packets called PPP-Max-Payload (off the top of my head) which tells the far end that it's ok to negotiate a 1500 byte PPP MTU, with the full knowledge that it will mean jumbo ethernet frames (i.e. >1500 bytes of payload).

I have no idea about download.com anymore, and don't currently have the tools to look into it.  If it loaded fully, then it's probably fine.

MSS clamping should be automatic.

Personally I'm not a mail expert, so I'm not sure I can accurately answer your question. I.e. please take what I say in regards to mail with a grain of salt.   What will generally happen if you're having an MTU issue will be that either the frames that are too big will arrive at the Broadband Network Gateway (BNG) (which is the router at the other end of the PPP link) and get fragmented there, and sent for delivery to your modem (and reassembled there).  No problems here.  The problems will occur if one or both ends set the "Do Not Fragment" bit in the IP header - which will cause oversize frames to be dropped instead of fragmented.  I think that's dependant on the OS and software at the far end. 

Given the packet loss and the fact that mail protocols use TCP, I can't imagine a world where you'd get a silent failure here.  I.e. you'll be getting error messages saying things like it lost communication with the mail server or similar. 

Hope that helps.


Thanks for all that.

I would have thought the same about the emails that a silent failure would be very unusual. I asked because I sent myself an email after our ADSL had been prematurely disconnected but before the fibre was up and running, and it still hasn't arrived and I haven't received an NDR as yet. And that was a good 18 hours ago.

719 posts

Ultimate Geek

Trusted
Spark NZ

  # 1013018 26-Mar-2014 10:59
Send private message

Little worrying that it hasn't arrived.  Have you tried sending a second?

I would be fairly confident that whatever the issue that has caused this, it is not an MTU issue. 

As I've said, I'm not a mail expert, so I'm not going to pretend to try and give you advice on how to proceed here! :)




My views are my own, and may not necessarily represent those of my employer.




2776 posts

Uber Geek


  # 1013065 26-Mar-2014 11:48
Send private message

cbrpilot: Little worrying that it hasn't arrived.  Have you tried sending a second?

I would be fairly confident that whatever the issue that has caused this, it is not an MTU issue. 

As I've said, I'm not a mail expert, so I'm not going to pretend to try and give you advice on how to proceed here! :)


When they were unable to reinstate our ADSL in a timely fashion I instead got them to move our old ADSL static IP onto the new Fibre connection and everything has been coming through since then (as far as I am aware).

As far as I'm aware if the listed MX is unavailable then the sending server should periodically retry. But the test was from a Yahoo Xtra account, so I can't see if it is stuck in an outgoing queue there, and that wouldn't help me for any other possible emails sent to us during that time frame anyway.

We shuffled some MX records as well while we were coming up with the best plan to get the mail flow back in the shortest time frame, but I can't see anything that would cause silent failures like this. I'm hopeful that it may still turn up or an NDR bounce back (along with any other emails that may have been affected).




2776 posts

Uber Geek


  # 1013238 26-Mar-2014 15:35
Send private message

Well, and NDR turned up exactly 24 hours after sending. It doesn't say why it failed, just "message expired".

Since everything is coming through correctly now I'm not going to worry too much. My concern about silent failures can be laid to rest. the failure is still unexplained, but as long as it was isolated to this short time period and that NDRs went back to senders I'm happy.

Create new topic



Twitter and LinkedIn »



Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

Logitech introduces new Made for Google keyboard and mouse devices
Posted 16-Oct-2019 13:36


MATTR launches to accelerate decentralised identity
Posted 16-Oct-2019 10:28


Vodafone X-Squad powers up for customers
Posted 16-Oct-2019 08:15


D Link ANZ launches EXO Smart Mesh Wi Fi Routers with McAfee protection
Posted 15-Oct-2019 11:31


Major Japanese retailer partners with smart New Zealand technology IMAGR
Posted 14-Oct-2019 10:29


Ola pioneers one-time passcode feature to fight rideshare fraud
Posted 14-Oct-2019 10:24


Spark Sport new home of NZC matches from 2020
Posted 10-Oct-2019 09:59


Meet Nola, Noel Leeming's new digital employee
Posted 4-Oct-2019 08:07


Registrations for Sprout Accelerator open for 2020 season
Posted 4-Oct-2019 08:02


Teletrac Navman welcomes AI tech leader Jens Meggers as new President
Posted 4-Oct-2019 07:41


Vodafone makes voice of 4G (VoLTE) official
Posted 4-Oct-2019 07:36


2degrees Reaches Milestone of 100,000 Broadband Customers
Posted 1-Oct-2019 09:17


Nokia 1 Plus available in New Zealand from 2nd October
Posted 30-Sep-2019 17:46


Ola integrates Apple Pay as payment method in New Zealand
Posted 25-Sep-2019 09:51


Facebook Portal to land in New Zealand
Posted 19-Sep-2019 18:35



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.


Support Geekzone »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.