samico
Goto Top

Bandbreite bei Download von Apache Webserver über externes Interface extrem eingeschränkt.

Moin,

unsere Unternehmenswebseite wird zur Zeit über einen Tomcat Webserver bereitgestellt. Dieser hängt, zusammen mit allen anderen Rechnern, im Netz 10.10.10.0 /24.
Der Tomcat läuft auf einem Debian Squeeze OS, welches als VM auf einem VMware ESX 4.2 läuft.
Als Router kommt ein Cisco 892 zum Einsatz.
Die Webseite ist von extern über eine FTTH Verbindung mit 50 Mbit/s synchron erreichbar.

Bei einem HTTP Download über eine interne Adresse werden sehr gute Geschwindigkeiten erreicht. Werden jedoch die selben Daten von extern geladen (HTTP Download über Browserfenster), werden maximal 500 kb/s erreicht.
Wird ein Downloadmanager benutzt, der mehrere Verbindungen für einen Download öffnet, können bis zu 5 Mb/s erreicht werden.

Bisweilen ist mir schleierhaft an welcher Stelle die Bandbreitenlimitierung stattfindet und wie ich sie aufheben kann. Und warum ist die Bandbreite nur "pro Verbindung" eingeschränkt?
Ich bitte um Hilfe.

Nachfolgen die Routerconfig:


version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname vpngate
!
boot-start-marker
boot-end-marker
!
!
logging buffered 51200 warnings
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication login ciscocp_vpn_xauth_ml_1 local
aaa authorization exec default local
aaa authorization network ciscocp_vpn_group_ml_1 local
!
!
!
!
!
aaa session-id common
!
crypto pki token default removal timeout 0
!
crypto pki trustpoint TP-self-signed-52048714
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-52048714
revocation-check none
!
!
crypto pki certificate chain TP-self-signed-52048714
certificate self-signed 01
3082024B 308201B4 A0030201 02020101 300D0609 2A860886 F70D0101 04050030
2F312D30 2B060355 04031324 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 35323034 38373134 301E170D 31323032 32333131 31393536
5A170D32 30303130 31303030 3030305A 302F312D 302B0603 55040313 24494F53
2D53656C 662D5369 676E6564 2D436572 74696669 63617465 2D353230 34383731
3430819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 8100E3E0
66E04BE0 B1F78597 B3CDAE5A D047206B 6604CB9E 1475B155 2C00563A 58E3A7EA
958E7ABB D05C8657 EAE1E02A 65474D44 CCCBF736 5EF327B8 75454E96 620AA229
F85EE2AE B9E55627 D8530F7E D764FD34 7DC3DDBA 24992828 C1EF2A89 A3FF634E
44FD871D C660588C D7C26207 0A3D91DB 17FD2796 D8FFDE21 51A927D0 C6C30203
010001A3 77307530 0F060355 1D130101 FF040530 030101FF 30220603 551D1104
1B301982 17796F75 726E616D 652E796F 7572646F 6D61696E 2E636F6D 301F0603
551D2304 18301680 14DE5BE5 1F7C432D 7A37110C 53EFD36C AE855FD2 2E301D06
03551D0E 04160414 DE5BE51F 7C432D7A 37110C53 EFD36CAE 855FD22E 300D0609
2A864886 F70D0101 04050003 81810029 68F44210 3C036C0B A4D63B2A 8875203F
82BA03FF 6DB9AA72 5F1E3928 F9B434FC 44AFFE42 096A4363 EB2E32CC 31CEDD03
5DA0CB6C 991BAEB5 3F2F401C 12311167 581B8BEA DBF27287 F648B48D DEFBE6B2
44A5293F F7CBCA94 BF334449 6DD447F2 AB3396B1 B8D06D85 5BFB64C3 F7AC48A8
B533FF7D E2975EFA C029A6E5 ED14E6
quit
ip source-route
!
!
!
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool ccp-pool
import all
network 10.10.10.0 255.255.255.248
default-router 10.10.10.1
lease 0 2
!
!
ip cef
ip domain name Domainname.de
ip name-server XXX.XXX.XXX.XXX
ip name-server XXX.XXX.XXX.XXX
no ipv6 cef
!
multilink bundle-name authenticated
license udi pid CISCO892-K9 sn XXX
!
!
username admin privilege 15 secret 5 ABCDEFG
!
!
!
!
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group admin
key HIJKLMN
dns XXX.XXX.XXX.XXX
pool SDM_POOL_1
acl 101
max-users 10
crypto isakmp profile ciscocp-ike-profile-1
match identity group admin
client authentication list ciscocp_vpn_xauth_ml_1
isakmp authorization list ciscocp_vpn_group_ml_1
client configuration address respond
virtual-template 1
!
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto ipsec profile CiscoCP_Profile1
set transform-set ESP-3DES-SHA
set isakmp-profile ciscocp-ike-profile-1
!
!
!
!
!
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
!
interface FastEthernet8
description $ES_WAN$
ip address XXX.XXX.XXX.XXX 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
!
interface Virtual-Template1 type tunnel
ip unnumbered FastEthernet8
tunnel mode ipsec ipv4
tunnel protection ipsec profile CiscoCP_Profile1
!
interface GigabitEthernet0
no ip address
shutdown
duplex auto
speed auto
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-FE 1$
ip address 10.10.10.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
ip local pool SDM_POOL_1 10.10.10.100 10.10.10.109
ip forward-protocol nd
!
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source list 100 interface FastEthernet8 overload
ip nat inside source static tcp 10.10.10.2 80 interface FastEthernet8 80
ip route 0.0.0.0 0.0.0.0 XXX.XXX.XXX.XXX
!
logging esm config
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 100 remark CCP_ACL Category=2
access-list 100 permit ip 10.10.10.0 0.0.0.7 any
access-list 101 remark CCP_ACL Category=4
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
no cdp run

!
!
!
!
!
!
!
control-plane
!
banner exec ^C
% Password expiration warning.

Cisco Configuration Professional (Cisco CP) is installed on this device
and it provides the default username "cisco" for one-time use. If you have
already used the username "cisco" to login to the router and your IOS image
supports the "one-time" user option, then this username has already expired.
You will not be able to login to the router with this username after you exit
this session.

It is strongly suggested that you create a new username with a privilege level
of 15 using the following command.

username <myuser> privilege 15 secret 0 <mypassword>

Replace <myuser> and <mypassword> with the username and password you want to
use.

^C
banner login ^C
Cisco Configuration Professional (Cisco CP) is installed on this device.
This feature requires the one-time use of the username "cisco" with the
password "cisco". These default credentials have a privilege level of 15.

YOU MUST USE CISCO CP or the CISCO IOS CLI TO CHANGE THESE PUBLICLY-KNOWN
CREDENTIALS

Here are the Cisco IOS commands.

username <myuser> privilege 15 secret 0 <mypassword>
no username cisco

Replace <myuser> and <mypassword> with the username and password you want
to use.

IF YOU DO NOT CHANGE THE PUBLICLY-KNOWN CREDENTIALS, YOU WILL NOT BE ABLE
TO LOG INTO THE DEVICE AGAIN AFTER YOU HAVE LOGGED OFF.

For more information about Cisco CP please follow the instructions in the
QUICK START GUIDE for your router or go to http://www.cisco.com/go/ciscocp
^C
!
line con 0
line aux 0
line vty 0 4
access-class 23 in
transport input telnet ssh
line vty 5 15
access-class 23 in
transport input telnet ssh
!
end

Content-Key: 181135

Url: https://administrator.de/contentid/181135

Printed on: April 23, 2024 at 19:04 o'clock

Member: aqui
aqui Feb 27, 2012 at 18:20:39 (UTC)
Goto Top
Ein Cisco 800er ist schon etwas an der Grenze mit 50 Mbit/s Daten Raten im IP Paket Forwwarding !! Dadurch das du intern eine RFC 1918 private IP nutzt musst du zudem noch NAT machen beim Zugriff von außen was die Paket Forwarding Rate weiter erheblich einschränkt. Allerdings auf 500 kbit/s darf das niemals absinken.
Es ist aber auch möglich das dein Router überlastet ist. Ein "sh proc cpu" zeigt dir das.
Da bei dir auch ein VPN Zugang mit IPsec konfiguriert ist stellt sich de Frage was du genau mit "von außen" meinst ??
Direkt aus dem Internet also einen freie IP und dann nur mit statischem NAT oder über den IPsec VPN Tunnel ?
Auch ist nicht klar welche FTTH Technik du nutzt also ob das ein transparenter Zugang ist mit dedizierter Leitung oder ein GPON Netzwerk was gemultiplext ist mit zig anderen Nutzern, wo du zwar 50 Mbit Anschlusswert hast aber die Faser mit zig anderen 50 Mbit Usern teilen musst.
So wie die letzte Meile bei Kabel Internet. Da liegen auf dem Draht auch noch zig tausend andere User die sich die 100 Mbit teilen.
Vorsicht also bei solchen Netzen.
Am besten du machst mit dem Cisco mal einen lokalen Aufbau und verifizierst mal was der wirklich Back zu Back durchschaufeln kann. 40 bis 50 Mbit sollte er schon schaffen und das auch mit NAT.
Member: samico
samico Feb 27, 2012 at 23:56:00 (UTC)
Goto Top
Hallo aqui,

vielen Dank für deine schnelle Antwort.

"Es ist aber auch möglich das dein Router überlastet ist. Ein "sh proc cpu" zeigt dir das."
Während des Downloads ist die CPU Auslastung bei 1-5%.

"Da bei dir auch ein VPN Zugang mit IPsec konfiguriert ist stellt sich de Frage was du genau mit "von außen" meinst ??"
Mit von außen meine ich wie du im nächsten Satz schreibst den Zugriff von einer freien IP. VPN ist auch zu langsam, das lasse ich aber mal außen vor. Vielleicht hat es ja die selbe Ursache.

"Auch ist nicht klar welche FTTH Technik du nutzt..."
Eine dedizierte Leitung mit zugesicherten 50Mbit/s synchron.

"Am besten du machst mit dem Cisco mal einen lokalen Aufbau und verifizierst mal was der wirklich Back zu Back durchschaufeln kann."
Gute Idee, das mache ich als Nächstes.

Hast du eine Idee warum mit mehreren Verbindungen bei einem Download eine höhere Geschwindigkeit erreicht wird? Das kann ja nichts mit dem Router zu tun haben, oder?
Member: aqui
aqui Mar 01, 2012 at 08:47:14 (UTC)
Goto Top
Nein, das kann dann nur was mit der MTU und oder Fragmentierung zu tun haben. Ggf. ist auch ein providerfehler möglich.
Dafür müsste man dann aber mal ins Eingemachte gehen und einen Testaufbau machen und mit NetIO oder IPerf und Sniffer mal messen.
http://www.nwlab.net/art/netio/netio.html
Member: samico
samico Mar 01, 2012 at 13:30:37 (UTC)
Goto Top
Mit der lokalen Konfiguration habe ich 10 - 12 MB/s erreichen können. Am Router scheint es tatsächlich nicht zu liegen.
Im unternehmen gibt es mehrere Router die verschiedene externe IP-Adressen bedienen. Diese hängen alle an einem Cisco Catalyst 2980G der wiederum an einem Port mit dem Provider verbunden ist.

Ich werde mir heute die Konfiguration des Switches anschauen, vielleicht stimmt etwas mit den Porteinstellungen nicht.
Member: aqui
aqui Mar 02, 2012 at 20:34:03 (UTC)
Goto Top
Das könnte auch sein. Achte auf Speed und Duplex Mismatches und MTU Einstellungen an den Switchports !
Wenn xDSL als Providerleitung verwendet wird (und auch nur dann) musst du in jedem Falle eine MTU und MSS Anpassung der Routerports vornehmen !!
interface Lokal
ip tcp adjust-mss 1452
!
interface Extern
ip mtu 1492

Letztere fehlt in deiner Konfig !

Besser noch du ermittelst die genauen max. MTU Einstellung auf deinem Providerlink !!
http://www.gschwarz.de/mtu-wert-ermitteln
Member: samico
samico Mar 20, 2012 at 13:28:43 (UTC)
Goto Top
Leider habe ich die Lösung noch nicht gefunden und habe gerade auch zu wenig Zeit um mich intensiv damit zu beschäftigen.
Sobald ich die Lösung gefunden habe, werde ich sie hier posten.
Member: aqui
aqui Mar 22, 2012 at 14:38:38 (UTC)
Goto Top
Das wäre sicher mal ganz spannend und hilfreich ! Wir sind dann weiter mal gespannt....
Member: delemming
delemming Mar 22, 2012 at 23:35:26 (UTC)
Goto Top
Wie sehn denn deine Sendbuffer aufm apache aus? Rennt der Flicken-Indianer auf linux oder windows? (oder noch was anderes)
Member: samico
samico Mar 23, 2012 at 09:57:03 (UTC)
Goto Top
Es wird ein Tomcat in der Version 6.0.29 genutzt.
Ich habe aber auch eine Test VM mit einem "normalen" Apache 2.4.1 aufgesetzt.
Beide Server laufen auf einem Debian Squeeze System.
Member: delemming
delemming Mar 23, 2012 at 21:35:30 (UTC)
Goto Top
Ich fisch zugegeben grad im Trüben, aber ist Sendfile in der Config an oder aus. Falls an, einfach mal ausmachen und dann nochmal testen.
Liefert wohl öfter mal checksummenfehler falls auf dem sys auch ipv6 rennt. tcp retransmits würd zu den kellerratios durchaus passen.
Member: samico
samico Apr 29, 2012 at 22:48:25 (UTC)
Goto Top
So, ich habe die Nacht und das Wochenende genutzt um ein paar Tests zu fahren.

Ich habe auf einem Laptop ein extrem schlankes Linux aufgesetzt und ihn direkt an das Kabel angeschlossen das vom Provider aus der Wand kommt.
MIt dieser Methode konnte ich alle Router, Switche und Software die in unserer Umgebung existieren von dem Test ausklammern.
Mit dem Tool Iperf (http://en.wikipedia.org/wiki/Iperf) habe ich dann verschiedene Verbindungseinstellungen mit einem externen Client/Server durchprobiert.

Für jeden parallelen Stream wurden maximal ~4 Mbit/s erreicht. Insgesamt konnten mit 13 parallelen Streams die 50 MBit/s, die unser Provider zur Verfügung stellt, ausgereizt werden.
Zur Erinnerung: Wir nutzen einen FTTH Anschluss mit 50 MBit/s Synchron.
An unserer IT liegt es also höchstwahrscheinlich nicht. Eine Lösung habe ich leider immer noch nicht gefunden.
Member: aqui
aqui May 01, 2012 at 09:54:19 (UTC)
Goto Top
Es liegt nicht an eurer Leitung !! Nur einzig DAS hast du damit bewiesen. Das es nicht an eurer gesamten IT liegt ist damit noch keinesfalls bewiesen !!
Vermutlich sind das also irgendwo falsche Einträge oder Stellschrauben in einem der beteiligten TCP Stacks der Endgeräte.
Provider und Leitung kann man ja nun sicher ausschliessen !!
Bei FTTH kannst du übrigens niemals MSS und MTU Probleme haben, da es im Gegensatz zu DSL hier niemals zum Enkapsulierungs Problematiken bei den Segment Sizes und Frame Sizes kommen kann.
Du hast bis zum Provider ja nur reines Ethernet. Das kann man also vollkommen ausschliessen und solche Einträge sollten dann auch sofort vom Router verschwinden und du immer mit den obligatorischen 1500 Byte arbeiten durchgängig !!!
Die Problematik ist vermutlich das Rate Limiting des Providers auf der FTTH Anbindung.
Bei 50 Mbit bekommst du vermutlich physisch immer einen 100 Mbit oder einen 1 GiG Ethernet Anschluss von einem Provider Switch oder Router bei dir.
Dieser hat aber dann ein internes Rate Limiting auf 50 Mbit.
Was nun passiert ist das Endgeräte immer auch von einer physischen 100 Mbit oder GiG Verbindung ausgehen wenn sie Autonegotiaten auf diese physischen Link Geschwindigkeiten und entsprechend ihre RWIN Windows anpassen.
Das diese dann auf 50 Mbit gedrosselt ist bekommen die nicht mit nur über den automatischen RWIN / Sliding Windows Mechanismus des TCP Stacks der Endgeräte was nicht gut ist sofern du das am Egress Router nicht gleich sauber anpasst !
Da du einen Cisco hast kannst du das entsprechend konfigurieren was du auch zwingend machen solltest mit den folgenden Kommandos:
!
policy-map 50M-shaping
class class-default
shape average 50000000
!
interface FastEthernet 8
description FTTH Standleitung zum Provider
bandwidth 50000
ip address 1.2.3.4 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
no cdp enable
service-policy output 50M-shaping
!

Damit passt du das dann sauber im Router an und alles sollte jedenfals aus Router Sicht und Leitungs Sicht dann klappen.
Zur Vergleichbarkeit machst du den iPerf test exakt nochmal nun aber mit dem Router dazwischen !
Damit kannst du dann den auch ausschliessen sollte der test erfolgreich sein was er sein wird...
Dann ist es wirklich nur noch Tuning der TCP Stacks der Endgeräte im lokalen LAN !!
Member: samico
samico Jun 24, 2012 updated at 22:17:26 (UTC)
Goto Top
Ich habe die o.g. Ergänzungen unserer Routerkonfiguration hinzugefügt, sie blieben aber leider ohne positiven Effekt.
Bemerkenswert ist jedoch ein iperf Bandbreitentest ausgefallen, den ich zwischen unserem Server und einer Gegenstelle beim Provider durchgeführt habe.
Hier konnten sowohl beim Upstream, als auch beim Downstream ca 50Mbit/s erreicht werden.

Die Ethernetverbindung zwischen unserem Router und dem Provider klappt also, wie bereits vermutet, ohne Probleme.
Irgendwas läuft trotzdem falsch und ich habe leider immer noch keinen blassen Schimmer was das sein könnte.
Member: aqui
aqui Jun 25, 2012 at 08:15:41 (UTC)
Goto Top
OK, das beweist dann relativ eindeutig das die Netzwerk Infrastruktur NICHT der böse Buhmann ist sondern das Problem eindeutig an den Endgeräten liegt.
Wenigstens kannst du so deine Suche etwas eingrenzen !