Good morning - I recently moved our facilities to a new Comcast Metro E buildout, utilizing Netvanta 3430 units for the interconnects. Two of the six locations have 50Mb pipes from Comcast, but Comcast is measuring throughput at the hand-off from the 3430 at 10Mb. Both ethernet ports are set at 100/full, and the bandwidth indicator in the system info screen of the GUI indicates 100Mb bandwidth. I have no bandwidth threshold or QoS maps in place.
Config:
!
!
! ADTRAN, Inc. OS version 17.09.01.00
! Boot ROM version 17.06.01.00
! Platform: NetVanta 3430, part number 1202820G1
! Serial number LBADTN1042AG680
!
!
hostname "StoneView3430"
enable password *********
!
clock timezone -6-Central-Time
!
ip subnet-zero
ip classless
ip routing
!
!
ip domain-name "cudomain.local"
ip domain-proxy
ip name-server 192.168.20.100 12.127.16.68
!
!
no auto-config
!
event-history on
no logging forwarding
logging forwarding priority-level info
no logging email
!
no service password-encryption
!
username "admin" password "**********"
!
!
!
no ip firewall alg msn
no ip firewall alg mszone
no ip firewall alg h323
!
!
!
!
!
!
!
no dot11ap access-point-control
!
!
probe SV-Memorial twamp
destination 10.1.1.4
source-address 10.1.1.1
size 512
shutdown
!
!
!
!
!
!
!
!
ip flow cache sample one-out-of 20 deterministic
ip flow cache timeout active 1
ip flow top-talkers
!
!
no ethernet cfm
!
interface eth 0/1
speed 100
ip address 192.168.20.65 255.255.255.192
no shutdown
!
!
interface eth 0/2
description StoneView Ext
speed 100
ip address 10.1.1.1 255.255.255.0
ip flow ingress
ip flow egress
no shutdown
!
!
!
!
!
!
!
!
!
!
!
ip route 0.0.0.0 0.0.0.0 10.1.1.4
ip route 192.168.20.0 255.255.255.192 10.1.1.4
ip route 192.168.20.128 255.255.255.248 10.1.1.6
ip route 192.168.20.144 255.255.255.240 10.1.1.3
ip route 192.168.20.160 255.255.255.240 10.1.1.2
ip route 192.168.20.192 255.255.255.192 10.1.1.5
!
no ip tftp server
no ip tftp server overwrite
ip http server
ip http secure-server
ip snmp agent
no ip ftp server
ip ftp server default-filesystem flash
no ip scp server
no ip sntp server
!
!
!
!
snmp-server community ********* RO
!
!
!
!
ip sip udp 5060
ip sip tcp 5060
!
!
!
!
!
!
!
!
!
!
!
!
!
!
line con 0
login
password *********
!
line telnet 0 4
login
password ***********
no shutdown
line ssh 0 4
login local-userlist
no shutdown
!
!
ntp peer 64.250.177.145 version 3
!
!
!
end
Anyone experienced this before? Comcast has assured me they have no throttling in place.
Thank you,
SShoemaker
There are many things that can influence throughput. If you are 100-full not seeing interface errors or runts, the actual carrier handoff is unlikely to be the issue. TCP window size may need to be adjusted, search "Long Fat Network" or LFN. If you get 10 Mbps on one stream and start another and that one also gets 10 for a total of 20, then the network is likely not at fault.
Tools such as iperf on a fast machine running at both ends connected to the carrier handoff directly may be needed to evaluate actual throughput.
Also, if copying files and timing the transfer, keep in mind that network speeds are almost always measured in bits per second and file sizes are expressed in bytes, so you will have to multiply or divide by eight as appropriate to convert. Overhead will cut down somewhat on actual data throughput but this should be less than 10% in most cases.
Thank you for asking this question in the Support Community, and for sending the configuration. When you get a chance, at the time of this post, I recommend you upgrade the firmware to R10.5.3. I also recommend you set the traffic-shape rate <value> command on the Internet interface to the amount of upload speed you have, and verify that the MTU has not been changed from the default (which it appears to be default in the configuration you sent, which is good). Also, the Troubleshooting Internet Test Speed Issues guide has several suggestions for Internet speed testing.
Levi
Thanks for the input - unfortunately, nothing changed after doing both the firmware update and setting the traffic shaping value. If there's nothing else to try, I suppose I'll beat on Comcast to make sure it's provisioned correctly, even though they have checked it several times and said it is.
You wrote that you locked the port down to 100/full -- has Comcast done the same, and what do the interface error counters report on both sides?
Yes, we are locked in at 100/full on all ports, confirmed. Auto neg was causing issues, so Comcast engineering suggested we force 100/full. My Comcast-facing ports are reporting zero errors - I will have to give them a shout to check their side, but original ticket technician stated they were not seeing errors, but rather that I was only handing them data at 10Mb.
There are many things that can influence throughput. If you are 100-full not seeing interface errors or runts, the actual carrier handoff is unlikely to be the issue. TCP window size may need to be adjusted, search "Long Fat Network" or LFN. If you get 10 Mbps on one stream and start another and that one also gets 10 for a total of 20, then the network is likely not at fault.
Tools such as iperf on a fast machine running at both ends connected to the carrier handoff directly may be needed to evaluate actual throughput.
Also, if copying files and timing the transfer, keep in mind that network speeds are almost always measured in bits per second and file sizes are expressed in bytes, so you will have to multiply or divide by eight as appropriate to convert. Overhead will cut down somewhat on actual data throughput but this should be less than 10% in most cases.
Thanks for the input. Never having had circuits larger than 10Mb to work with, I was quite unaware of the concepts referenced. I loaded iperf on either end and have tested out in the 25-30 Mb range during operating hours, which is better than the 10 Mb I thought I had, but not quite 50 either. We'll consider this answered and I'll take the rest up with Comcast.
Thank you again for your response and the valuable information.