Cisco Router - Trage upload op een nieuw ip blok

[Nano2009]

Een goedemorgen mede tweakers,

Wij hebben een vreemd probleem wat wij helaas niet opgelost krijgen, ik hoop dat iemand hier ons verder zou kunnen helpen.

WIj hebben een Cisco 881 router met daarop twee ip blocken die beide over dezelfde glasverbinding naar buiten gaan.

Nu heeft het eerste ip block (VLAN1) een perfecte upload maar het tweede ip block (VLAN2) maar een upload van maximaal 40kbit/sec.

Nog even kort samengevat het probleem :
- Download/upload snelheid vlan 1 : 20mbit/16mbit
- Download/upload snelheid vlan 2 : 20bmit/0.04mbit

Heeft iemand hier enig idee waarom het tweede ip block zon trage upload heeft?

Alvast bedankt.

Config :

Current configuration : 5515 bytes
!
!
version 15.0
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname xxxxx
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 51200
logging console critical
enable secret 5 xxxxx.
!
no aaa new-model
memory-size iomem 10
clock timezone PCTime 1
!
crypto pki trustpoint TP-self-signed-980756133
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-980756133
revocation-check none
rsakeypair TP-self-signed-980756133
!
!
crypto pki certificate chain TP-self-signed-980756133
certificate self-signed 01
3082023F 308201A8 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 39383037 35363133 33301E17 0D313330 31303831 33353833
345A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F
532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3938 30373536
31333330 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100
A3CA0F96 7526B42E F4F4D385 8FE0A3A6 70A27E7A 412E850D E8AE7E67 AC0327E2
F13CC36E 1DA92003 EE6D8480 EB941BF8 DC26F0B0 9F82D7D6 01C2911E 9EBF1928
630CB00E AB984661 CA0E3367 06964249 C0999FC3 CF436A9D 87E0350B 44CDF629
F1140694 95F1956F A3A3FD6F C5538D58 F7F569E9 448C1E0F 07304E92 30A91113
02030100 01A36930 67300F06 03551D13 0101FF04 05300301 01FF3014 0603551D
11040D30 0B820943 525F494E 54484552 301F0603 551D2304 18301680 142BD0CB
2B4B6AC8 4436F803 A73C1D6C 61C9628E B1301D06 03551D0E 04160414 2BD0CB2B
4B6AC844 36F803A7 3C1D6C61 C9628EB1 300D0609 2A864886 F70D0101 04050003
8181000A 4A3939E0 AC39E203 8E986342 5BAB46F2 61ED6AC2 BEAFADAF 4A738C6B
CCC6EC8F 9AA853D7 5FD93814 08B0FB92 68DB37F3 ED47A33B 294F9E43 59A3B69E
43B4FCF4 F96FCFA8 EB538309 15E3FCA8 A6F3C8CB 69E5713B 78678C38 EDC40146
4F929D55 D8258CA6 5BC954C0 EDBE185B CF4C84E5 E6F39519 C50EA981 581B6E6C 17412B
quit
no ip source-route
!
!
!
!
ip cef
no ip bootp server
ip name-server x.x.x.x
ip name-server x.x.x.x
no ipv6 cef
!
!
license udi pid CISCO881-K9 sn xxxxxxxx
!
!
username xxxxxxx privilege 15 secret 5 xxxxxxx
!
!
ip tcp synwait-time 10
ip ssh time-out 60
ip ssh authentication-retries 2
!
policy-map custom-shaper-20Mbps
class class-default
shape average 18800000
!
!
!
!
!
!
!
!
interface FastEthernet0
switchport access vlan 2
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
switchport access vlan 2
!
interface FastEthernet4
description $FW_OUTSIDE$$ES_WAN$$ETH-WAN$
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip virtual-reassembly
duplex auto
speed auto
pppoe-client dial-pool-number 1
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$$ES_LAN$$FW_INSIDE$
ip address x.x.x.x 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
interface Vlan2
ip address x.x.x.x 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast reverse-path
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
interface Dialer0
ip unnumbered Vlan1
ip mtu 1452
ip nat outside

[jvanhambelgium]

Hmm, mischien toch eens naar die "ip verify unicast reverse-path" kijken ?
Dat is alvast het enige verschil VLAN1 <-> VLAN2

[Anoniem: 130989]

Ik zie niet de gehele config, zo mis ik o.a de NAT rules. Zou je de rest van de config ook kunnen plaatsen?

edit: Ik zie dat je ip-unnumberd vlan1 gebruikt, is dit dan een public ip range? Wellicht zou je in de config de ip-adressen kunnen laten staan of je verandert een octet (niet de laatste).

[ Voor 48% gewijzigd door Anoniem: 130989 op 14-01-2013 10:35 ]

[jvanhambelgium]

http://www.cisco.com/en/U...uration/guide/scfrpf.html

Mischien toch eens kijken naar die RPF check, die zou je niet op de interne interfaces mogen zetten.
In jullie geval is dit wel degelijk. VLAN2 is een interne ethernet-poort.

Hoe zit het inderdaad met NAT en routing entries ?

[Kabouterplop01]

En hoe zit het met een sh int fa 3? zie je daar errors?

[Nano2009]

Ten eerste wil ik jullie bedanken voor jullie reactie(s)

Misschien ook verstandig om de rol van deze router in het netwerk uit te leggen;
Deze router dient als gateway voor de verschillende routers van verschillende bedrijven in een bedrijfsverzamelpand waarin elke huurder dus een publiek ip adres krijgt.

@ jvanhambelgium
Ik had de reverse path optie aangezet als test omdat dit ook terugkwam in de orginele configuratie die de provider mij heeft toegestuurd. Toen wij zagen dat dit het probleem niet oploste hebben wij dit ook meteen weer uit de configuratie gehaald.


De gehele configuratie:

Building configuration...

Current configuration : 5547 bytes
!
! Last configuration change at 13:10:36 PCTime Mon Jan 14 2013 by xxxxx
!
version 15.0
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname xxxxx
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 51200
logging console critical
enable secret 5 $1$w5wS$7l0MInzadY8pBaUpk7d3j.
!
no aaa new-model
memory-size iomem 10
clock timezone PCTime 1
!
crypto pki trustpoint TP-self-signed-980756133
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-980756133
revocation-check none
rsakeypair TP-self-signed-980756133
!
!
crypto pki certificate chain TP-self-signed-980756133
certificate self-signed 01
3082023F 308201A8 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 39383037 35363133 33301E17 0D313330 31303831 33353833
345A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F
532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3938 30373536
31333330 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100
A3CA0F96 7526B42E F4F4D385 8FE0A3A6 70A27E7A 412E850D E8AE7E67 AC0327E2
F13CC36E 1DA92003 EE6D8480 EB941BF8 DC26F0B0 9F82D7D6 01C2911E 9EBF1928
630CB00E AB984661 CA0E3367 06964249 C0999FC3 CF436A9D 87E0350B 44CDF629
F1140694 95F1956F A3A3FD6F C5538D58 F7F569E9 448C1E0F 07304E92 30A91113
02030100 01A36930 67300F06 03551D13 0101FF04 05300301 01FF3014 0603551D
11040D30 0B820943 525F494E 54484552 301F0603 551D2304 18301680 142BD0CB
2B4B6AC8 4436F803 A73C1D6C 61C9628E B1301D06 03551D0E 04160414 2BD0CB2B
4B6AC844 36F803A7 3C1D6C61 C9628EB1 300D0609 2A864886 F70D0101 04050003
8181000A 4A3939E0 AC39E203 8E986342 5BAB46F2 61ED6AC2 BEAFADAF 4A738C6B
CCC6EC8F 9AA853D7 5FD93814 08B0FB92 68DB37F3 ED47A33B 294F9E43 59A3B69E
43B4FCF4 F96FCFA8 EB538309 15E3FCA8 A6F3C8CB 69E5713B 78678C38 EDC40146
4F929D55 D8258CA6 5BC954C0 EDBE185B CF4C84E5 E6F39519 C50EA981 581B6E6C 17412B
quit
no ip source-route
!
!
!
!
ip cef
no ip bootp server
ip name-server
ip name-server
no ipv6 cef
!
!
license udi pid CISCO881-K9 sn
!
!
username privilege 15 secret 5 $1$SpLa$pbDEE3DliU66LzUp3mpvy0
!
!
ip tcp synwait-time 10
ip ssh time-out 60
ip ssh authentication-retries 2
!
policy-map custom-shaper-20Mbps
class class-default
shape average 18800000
!
!
!
!
!
!
!
!
interface FastEthernet0
switchport access vlan 2
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
switchport access vlan 2
!
interface FastEthernet4
description $FW_OUTSIDE$$ES_WAN$$ETH-WAN$
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip virtual-reassembly
duplex auto
speed auto
pppoe-client dial-pool-number 1
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$$ES_LAN$$FW_INSIDE$
ip address 39.89.154.50 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast reverse-path
ip flow ingress
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
interface Vlan2
ip address 179.199.38.249 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
interface Dialer0
ip unnumbered Vlan1
ip mtu 1452
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname
ppp chap password
ppp pap sent-username
no cdp enable
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip route 0.0.0.0 0.0.0.0 Dialer0 39.89.154.50
!
ip access-list extended test
remark CCP_ACL Category=2
remark test
permit ip any any
!
logging trap debugging
dialer-list 1 protocol ip permit
no cdp run

!
!
!
!
!
control-plane
!
banner exec ^C

^C
banner login ^CAuthorized access only!
Disconnect IMMEDIATELY if you are not an authorized user!^C
!
line con 0
login local
no modem enable
transport output telnet
line aux 0
login local
transport output telnet
line vty 0 4
privilege level 15
login local
transport input telnet ssh
!
scheduler max-task-time 5000
scheduler allocate 4000 1000
scheduler interval 500
end

[Anoniem: 130989]

Ik zie dat je alleen ip nat inside en outside hebt geconfigureerd en geen rule die matched welke netwerken hierop van toepassing zijn.

Moet er wel ge-NAT worden? in princiepe heb je geen NAT nodig aangezien dit een router is die puur voor andere routers is. Indien dit het geval is gewoon de NAT regels weglaten.

Ook zal de ISP moeten adverteren dat "179.199.38.249 255.255.255.248" achter "39.89.154.50" leeft indien ze dit verkeer niet naar jouw toe routeren zal dit verkeer dus niet aankomen.

Een paar andere bevindingen:

policy-map custom-shaper-20Mbps
class class-default
shape average 18800000

Is niet ge-applyed? moet dit nog of gaat dit weg?

ip access-list extended test
remark CCP_ACL Category=2
remark test
permit ip any any

Wordt niet gebruikt? kan weg?

Je hebt niet vty 5-15 geconfigureerd, zet dit er snel in, indien je geen ongewenst toegang wil:
line vty 5 15
privilege level 15
login local
transport input telnet ssh

[Nano2009]

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 13:16:

Je hebt helemaal gelijk wat betreft de service/map policy, de access control list en de NAT policy's. Wat betreft de vty lines; we hebben er maar vijf waardoor we ons geen zorgen hoeven te maken om de rest

In ieder geval bedankt voor je reactie, het heeft ons zeker geholpen om de config wat op te schonen!

Zoals jullie waarschijnlijk zien is de configuratie een grote puinzooi. Dit komt omdat we van alles aan het proberen zijn om dit probleem op te lossen. Omdat deze verbinding twee weken vroeger is opgeleverd dan dat wij geplant hadden is deze verbinding nog niet in gebruik genomen. Dit geeft ons, gelukkig, ook de ruimte om dit probleem op te lossen.

Nog even kort samengevat het probleem :
- Download/upload snelheid vlan 1 : 20mbit/16mbit
- Download/upload snelheid vlan 2 : 20bmit/0.04mbit

[Anoniem: 130989]

En als je dit aanpast:

ip route 0.0.0.0 0.0.0.0 Dialer0 39.89.154.50

naar:

ip route 0.0.0.0 0.0.0.0 Dialer0

[Nano2009]

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 14:29:
En als je dit aanpast:

ip route 0.0.0.0 0.0.0.0 Dialer0 39.89.154.49

naar:

ip route 0.0.0.0 0.0.0.0 Dialer0

Ik zie nou dat ik een fout heb gemaakt in het wijzigen van de ip adressen om hier te kunnen posten. De route verwijst natuurlijk niet naar hetzelfde ip adres als bij vlan 1 is ingesteld.

Dit zou volgensmij zo moeten staan aangezien het ip adres 39.89.154.49 de "next hop" is en vlan 1 het ip adres deelt met dailer0 (39.89.154.50).

Of ben ik nou fout aan het denken?

[Anoniem: 130989]

Nano2009 schreef op maandag 14 januari 2013 @ 14:41:
[...]


Ik zie nou dat ik een fout heb gemaakt in het wijzigen van de ip adressen om hier te kunnen posten. De route verwijst natuurlijk niet naar hetzelfde ip adres als bij vlan 1 is ingesteld.

Dit zou volgensmij zo moeten staan aangezien 39.89.154.49 de "next hop" is en vlan 1 het ip adres deelt met dailer0.

Of ben ik nou fout aan het denken?

Meestal doe je OF ip route 0.0.0.0 0.0.0.0 [Gateway IP]
of ip route 0.0.0.0 0.0.0.0 [Outbound interface]

Optie 1 is beter. dus: ip route 0.0.0.0 0.0.0.0 39.89.154.49

In princiepe moet dit niet het probleem zijn. Post eens de output van "show interfaces" Misschien heb je een duplex mismatch?

edit: Post eens a.u.b de actuele config met wat er nu veranderd is.

[ Voor 4% gewijzigd door Anoniem: 130989 op 14-01-2013 14:48 ]

[jvanhambelgium]

Wat is de totale uplink-capaciteit eigenlijk ? Is het een 100megabits ethernet link naar je ISP ?
Je hebt wel 2 VLAN's maar gebruikt uiteindelijk dezelfde pijp naar je ISP toe, namelijk de

Welke "upload" server gebruik je om te testen waardoor je ziet dat de upload zo traag is ?
Heb je vb een FTP bij de ISP zodat je "dichtbij" de upload kan testen ipv een server op Internet?

Heb je ook al eens via een zogenaamd "bgp looking glass / traceroute" op Internet gekeken hoe de wereld de routering zie naar deze 2 subnetten ?

Gewoon om in kaart te brengen hoe je ISP omgaat met deze 2 subnetten en hoe het uiteindelijk tot bij jullie geraak.

[Nano2009]

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 14:44:
[...]


Meestal doe je OF ip route 0.0.0.0 0.0.0.0 [Gateway IP]
of ip route 0.0.0.0 0.0.0.0 [Outbound interface]

Optie 1 is beter. dus: ip route 0.0.0.0 0.0.0.0 39.89.154.49

In princiepe moet dit niet het probleem zijn. Post eens de output van "show interfaces" Misschien heb je een duplex mismatch?

Oke duidelijk maar zal de router dan niet proberen de pakketjes via vlan 1 naar buiten te sturen? Aangezien deze interface een ip adres heeft wat in hetzelfde subnet zit als de gateway?

Hier de export van de show interfaces;

Dialer0
Dialer0 is up, line protocol is up (spoofing)
Hardware is Unknown
Interface is unnumbered. Using address of Vlan1 (xx.xx.xx.xx)
MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 255/255, rxload 255/255
Encapsulation PPP, LCP Closed, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 1 seconds on reset
Interface is bound to Vi1
Last input never, output never, output hang never
Last clearing of "show interface" counters 6d01h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 17902
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 42 kilobits/sec
5 minute input rate 456000 bits/sec, 120 packets/sec
5 minute output rate 337000 bits/sec, 93 packets/sec
18543796 packets input, 2702871649 bytes
15293699 packets output, 16584554 bytes
Bound to:
Virtual-Access1 is up, line protocol is up

Fa0
FastEthernet0 is up, line protocol is up
Hardware is Fast Ethernet, address is 0007.7d8e.e894 (bia 0007.7d8e.e894)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
745189 packets input, 261111460 bytes, 0 no buffer
Received 8448 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
848128 packets output, 340022106 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Fa1
FastEthernet1 is up, line protocol is up
Hardware is Fast Ethernet, address is 0007.7d8e.e895 (bia 0007.7d8e.e895)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 251000 bits/sec, 59 packets/sec
5 minute output rate 217000 bits/sec, 60 packets/sec
5815749 packets input, 2232105329 bytes, 0 no buffer
Received 980 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
6839442 packets output, 3855411394 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Fa2
FastEthernet2 is up, line protocol is up
Hardware is Fast Ethernet, address is 0007.7d8e.e896 (bia 0007.7d8e.e896)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 59000 bits/sec, 26 packets/sec
5 minute output rate 149000 bits/sec, 27 packets/sec
8526066 packets input, 2103122881 bytes, 0 no buffer
Received 455 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
11861523 packets output, 3165658499 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Fa3
[DOWN]

Fa4
FastEthernet4 is up, line protocol is up
Hardware is PQII_PRO_UEC, address is 0007.7d8e.e898 (bia 0007.7d8e.e898)
Description: $FW_OUTSIDE$$ES_WAN$$ETH-WAN$
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 254/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 6d01h, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 383
Queueing strategy: fifo

[Nano2009]

jvanhambelgium schreef op maandag 14 januari 2013 @ 15:00:
Wat is de totale uplink-capaciteit eigenlijk ? Is het een 100megabits ethernet link naar je ISP ?
Je hebt wel 2 VLAN's maar gebruikt uiteindelijk dezelfde pijp naar je ISP toe, namelijk de

Het is inderdaad een 100mbit glaslijn maar er loopt een abonnement op van 20mbit/20mbit met een overboeking van 1:10.

jvanhambelgium schreef op maandag 14 januari 2013 @ 15:00:
Welke "upload" server gebruik je om te testen waardoor je ziet dat de upload zo traag is ?
Heb je vb een FTP bij de ISP zodat je "dichtbij" de upload kan testen ipv een server op Internet?

Ik heb onderstaande servers gebruikt om de verbinding mee te testen;
- www.speedtest.nl
- www.speedtest.net
- Onze eigen ftp server (staat ongeveer +- 20 km verderop met een glasverbinding van 50mbit/50mbit met een overboeking van 1:1, genoeg capiciteit dus)

jvanhambelgium schreef op maandag 14 januari 2013 @ 15:00:
Heb je ook al eens via een zogenaamd "bgp looking glass / traceroute" op Internet gekeken hoe de wereld de routering zie naar deze 2 subnetten ?

Gewoon om in kaart te brengen hoe je ISP omgaat met deze 2 subnetten en hoe het uiteindelijk tot bij jullie geraak.

De traceroute werkt prima, geen problemen van beide subnets. Ik kan dus ook in staat om over de twee subnets te internetten, alleen over vlan 2 is de upload dusdanig traag dat het laden van de internetpagina "iets" langer duurt

[Anoniem: 130989]

Fa4
Half-duplex, 100Mb/s, Total output drops: 383

Jouw kant staat auto-auto (Fa4) Het lijkt erop dat de provider kant 100 full staat.
Even navragen voor de zekerheid, maar ik neem aan dat de provider dat doet.

edit: Het gekke is sowiezo dat indien dit verkeerd staat ook een effect zou moeten hebben op Vlan1

Oke duidelijk maar zal de router dan niet proberen de pakketjes via vlan 1 naar buiten te sturen? Aangezien deze interface een ip adres heeft wat in hetzelfde subnet zit?

Je hebt gelijk.

[ Voor 53% gewijzigd door Anoniem: 130989 op 14-01-2013 15:14 ]

[jvanhambelgium]

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 15:10:
Fa4
Half-duplex, 100Mb/s, Total output drops: 383

Jouw kant staat auto-auto (Fa4) Het lijkt erop dat de provider kant 100 full staat.
Even navragen voor de zekerheid, maar ik neem aan dat de provider dat doet.

Indien dit slecht zou staan zou er impact zijn op beide verbindingen aangezien dit de fysische link betreft.
Nu "output" drop 383 zegt niet veel zonder de totaal-stats. Als die interface al een zillioen packets heeft geprocessed is 383 niet echt de moeite ;-)

[Anoniem: 130989]

jvanhambelgium schreef op maandag 14 januari 2013 @ 15:21:
[...]


Indien dit slecht zou staan zou er impact zijn op beide verbindingen aangezien dit de fysische link betreft.
Nu "output" drop 383 zegt niet veel zonder de totaal-stats. Als die interface al een zillioen packets heeft geprocessed is 383 niet echt de moeite ;-)

Klopt alles stats zijn relatief, maar aangezien er geen late-collision,runts e.d stats zijn(en output drops niet increment op deze waardes), is een duplex mismatch mogelijk

[Nano2009]

Ik heb de vraag van half-duplex nu ook bij onze provider neer gelegd maar wat jullie beiden al aangeven lijkt het mij ook onwaarschijnlijk gezien het verkeer over vlan 1 nergens last van heeft.

Ik wil nog wel even zeggen dat ik jullie reacties zeer waardeer, bedankt hiervoor!

Hierbij de volledige ouput van fa4

FastEthernet4 is up, line protocol is up
Hardware is PQII_PRO_UEC, address is 0007.7d8e.e898 (bia 0007.7d8e.e898)
Description: $FW_OUTSIDE$$ES_WAN$$ETH-WAN$
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 253/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 6d02h, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 383
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 301000 bits/sec, 155 packets/sec
5 minute output rate 806000 bits/sec, 229 packets/sec
19060606 packets input, 3239781913 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
25 input errors, 0 CRC, 0 frame, 0 overrun, 25 ignored
0 watchdog
0 input packets with dribble condition detected
15793231 packets output, 551525114 bytes, 0 underruns
194117 output errors, 132168 collisions, 22 interface resets
0 unknown protocol drops
0 babbles, 37199 late collision, 156881 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Er zijn wel behoorlijk wat output errors en collisions. Ik heb behalve de duplex mismatch geen idee waar deze vandaan zouden kunnen komen.

[ Voor 4% gewijzigd door Nano2009 op 14-01-2013 15:58 ]

[Anoniem: 130989]

37199 late collision, 194117 output errors, 132168 collisions = 100% zeker duplex mismatch. Dit kost je zeker performance. Of het je probleem oplost.... Ben benieuwd!

Zet je fa0/4 poort eens op speed 100, duplex full.

Indien het poortje down gaat controlleren of je een cross of straight kabel aangesloten hebt.

[ Voor 45% gewijzigd door Anoniem: 130989 op 14-01-2013 16:00 ]

[jvanhambelgium]

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 15:58:
37199 late collision, 194117 output errors, 132168 collisions = 100% zeker duplex mismatch. Dit kost je zeker performance. Of het je probleem oplost.... Ben benieuwd!

Zet je fa0/4 poort eens op speed 100, duplex full.

Indien het poortje down gaat controlleren of je een cross of straight kabel aangesloten hebt.

Dat is inderdaad veel te veel en zal zeker impact hebben.
Het is dan wel gek dat "uploaden via de andere VLAN" dan wel vlot gaat ? Uiteindelijk gaat alles door dezelfde "fa0/4" dus de fouten zijn voor iedereen ;-)

[Uberprutser]

De meeste glasvezelboeren leveren een koppelvlak van 100Mbit F/D.
9 Van de 10 performanceproblemen zijn hieraan gerelateerd, sowieso even aanpassen naar 100 FD (wat DaM-iGe zegt) want die coll. is zeker een duplex mismatch.

Kwaad kan het ieg niet.

[Vicarious]

Allright, in je dialer geef je het commando
ip unnumbered Vlan1

Als ik het goed begrijp geef je daarmee aan dat de dialer het IP-adres van interface VLAN1 moet gebruiken als next-hop adres naar buiten toe. Daardoor krijg je bij de weg terug een asynchrone routering wat het boeltje in de war kan schoppen. Je gaat immers het internet op met een ander IP-adres als waarop je het verkeer weer terug krijgt of moet krijgen.

Hoe je dit kunt oplossen weet ik eerlijk gezegd niet. Moet je niet gewoon per provider een andere dialer aanmaken? Of een aparte NAT configuratie per VLAN? Of iets met dialer mappings? Geen ervaring met dit type configuratie, maar ik vermoed dat het probleem met bovenstaand commando te maken heeft.

[ Voor 10% gewijzigd door Vicarious op 15-01-2013 14:59 ]

[Nano2009]

Vicarious schreef op dinsdag 15 januari 2013 @ 14:58:
Allright, in je dialer geef je het commando
ip unnumbered Vlan1

Hoi Vecarious,

Met deze command geef je aan dat het verkeer naar buiten moet gaan met hetzelfde ip adres als vlan 1.Oftewel, Dailer0 krijgt hetzelfde ip als VLAN1.

Voorbeeldje :

Router Huurder 1 IP; 37.89.168.71
VLAN 1 IP; 37.89.168.70
Dailer 0 IP; Hetzelfde ip als vlan 1
Gateway IP; 37.89.168.69

Router huurder 1 -> Gateway voor huurder 1 (VLAN1) -> Gateway voor Router

Er is helaas geen andere manier om dit op te lossen aangezien je niet het interne netwerk in hetzelfde subnet kunt plaatsen als je WAN interface/Gateway.

Ik hoop dat ik het zo goed heb verwoord aangezien het nogal lastig uit te leggen is.

Anoniem: 130989 schreef op maandag 14 januari 2013 @ 15:58:
37199 late collision, 194117 output errors, 132168 collisions = 100% zeker duplex mismatch. Dit kost je zeker performance. Of het je probleem oplost.... Ben benieuwd!

Zet je fa0/4 poort eens op speed 100, duplex full.

Indien het poortje down gaat controlleren of je een cross of straight kabel aangesloten hebt.

Ik heb geprobeerd de duplex handmatig op "Full" te zetten maar de poort gaat dan meteen down, ongeacht of ik een straight of cross kabel gebruik.

[Vicarious]

Mjah ik zat dus al aardig in de buurt. Maar dan ga je dus naar buiten via het IP-adres van VLAN 1, ook als je bij VLAN 2 vandaan komt. Daar zit nu juist het probleem volgens mij.

[CyBeR]

Nano2009 schreef op dinsdag 15 januari 2013 @ 15:19:
[...]

Ik heb geprobeerd de duplex handmatig op "Full" te zetten maar de poort gaat dan meteen down, ongeacht of ik een straight of cross kabel gebruik.

Ga dan even na bij je leverancier wat de fuck ze aan het doen zijn. Een grote hoeveelheid "late collisions" is nagenoeg altijd een duplex mismatch namelijk, en sowieso is half-duplex voor WAN-links nogal ongehoord.

(Overigens, op een half-duplex ethernetverbinding zijn normale collisions normaal en niks om je zorgen om te maken; late collisions echter zijn collisions die normaal gesproken niet voor mogen komen.)

[ Voor 17% gewijzigd door CyBeR op 15-01-2013 15:43 ]

[FatalError]

Ik heb ze weleens voorbij zien komen bij gare/te lange bekabeling.

[Nano2009]

Vicarious schreef op dinsdag 15 januari 2013 @ 15:29:
Mjah ik zat dus al aardig in de buurt. Maar dan ga je dus naar buiten via het IP-adres van VLAN 1, ook als je bij VLAN 2 vandaan komt. Daar zit nu juist het probleem volgens mij.

Dit zit net wat anders. VLAN 2 heeft ook een apart ip adres dat fungeert als het gateway adres voor alle routers die op VLAN 2 aangesloten worden, net als VLAN 1 IP fungeert als gateway adres van alle routers die op VLAN 1 aangesloten zitten. VLAN 2 verkeer heeft dus niks te maken met VLAN 1 verkeer behalve dat de uiteindelijke next hop van de router in het subnet van VLAN 1 zit

[jvanhambelgium]

Welke VLAN dan ook maakt allemaal niet uit. Zoals ik het zie gaat *iedereen* binnen/buiten over fysieke fastethernet4 (met daarboven een logische dialer interface)

Waarom heeft dan slechts 1 VLAN "last" van een gemeenschappelijke uplink met collisions en zijn er geen klachten van andere gebruikers op dat andere subnet, die ook fa4 in hun pad hebben zitten op weg van/naar Internet ?

[CyBeR]

FatalError schreef op dinsdag 15 januari 2013 @ 16:06:
Ik heb ze weleens voorbij zien komen bij gare/te lange bekabeling.

Klopt inderdaad, dat is eigenlijk de enige andere reden*: half-duplex werken op een kabel die langer is dan toegestaan. (En collision detection is derhalve ook de reden dat half-duplexverbindingen een lengtelimiet hebben, zelfs op glas.)

*) los van "de apparatuur is kapot" o.i.d.

[Nano2009]

Nu net een telefoontje gekregen van KPN; op de glasswitch staat de de poort op full duplex 100mbit dus het probleem ligt niet volgens de support desk niet bij KPN

Zodra ik op de router de poort handmatig op full duplex zet gaat de fa4 poort down, ongeacht of ik er een straight of croscable tussen heb liggen (voor de zekerheid ook meerdere kabels geprobeerd, allemaal zonder resultaat)

[ Voor 5% gewijzigd door Nano2009 op 16-01-2013 11:46 ]

[CyBeR]

Hm. Die "glasswitch" is dat zo'n blauwe WorldWidePackets LightningEdge? Daar heb ik ook wel 's mee gehad dat de link down bleef nadat ik 'm verplaatste, met een Cisco 1811 aan de andere kant van 't patchkabeltje. Na een paar keer proberen deed 'ie het opeens (en sindsdien is 't niet meer misgegaan gelukkig..)

[Anoniem: 130989]

Ik heb dit probleem ook wel eens gehad. Opgelost door 2 kanten auto duplex in te stellen(en auto mdix, wat default is). Wat je zou kunnen proberen om het op korte termijn op te lossen is om er een simpel layer 2 switch (of hub) tussen te zetten.

[CyBeR]

Het probleem is dat KPN de andere kant beheert en die om de een of andere reden weigeren autonegotiation aan te zetten.

Hub zou ik niet doen, die is per definitie half duplex, en een unmanaged switch ook niet want wat die doen bij het tegenkomen van een hard ingestelde andere kant is defaulten naar half duplex.

[ Voor 45% gewijzigd door CyBeR op 16-01-2013 12:22 ]

[Anoniem: 130989]

CyBeR schreef op woensdag 16 januari 2013 @ 12:22:
Hub zou ik niet doen, die is per definitie half duplex, en een unmanaged switch ook niet want wat die doen bij het tegenkomen van een hard ingestelde andere kant is defaulten naar half duplex.

Klopt ! Inderdaad in deze sitauatie inderdaad niet wenselijk.

edit: Conclusie, een managed switch, vast gezet op 100full is nodig om dit te testen.
Zou KPN misschien auto mdix uit hebben staan? Kijk eens naar de tabellen op deze link:
http://cciepursuit.wordpr...ch-cabling-and-auto-mdix/

Wellicht proberen met no auto mdix + 100full en dan een cross kabel indien de overkant een switchport is of een straight kabel als de overkant een routerport is(ik ga er vanuit dat de kabel nu in een switchmodule zit aangezien je svi gebruikt). Indien het dan nog niet werkt vind het maar een raar probleem. Wellicht een compatibility issue? (bug?)

edit2: Net geprobeerd op een router met switchmodule (2821) deze heeft helaas geen mdix functie...

[ Voor 52% gewijzigd door Anoniem: 130989 op 16-01-2013 13:08 ]

[Nano2009]

Anoniem: 130989 schreef op woensdag 16 januari 2013 @ 12:29:
[...]

CyBeR schreef op woensdag 16 januari 2013 @ 12:22:

Een compatibility issue of een bug zou het niet mogen zijn aangezien kpn de 881 ook aanbied als kooprouter richting zijn klanten.

Wel heb ik een configuratie kunnen verkrijgen die hun in de kooprouters schieten waarin het volgende is ingesteld op fa4

interface FastEthernet4
no ip address
load-interval 30
speed 100
duplex full
pppoe enable
pppoe-client dial-pool-number 1
no cdp enable
no shutdown

Hier zie je dat kpn ook handmatig de duplex instellingen op "full" zet wat het des te vreemder maakt dat het bij ons ervoor zorgt dat de poort down gaat.

[Anoniem: 130989]

Ga je toevallig over een patchpaneel? of patch je direct op beide apparaten?

[Nano2009]

Anoniem: 130989 schreef op woensdag 16 januari 2013 @ 13:11:
Ga je toevallig over een patchpaneel? of patch je direct op beide apparaten?

Ze zijn direct met elkaar verbonden zonder tussenkomst van een patchpaneel.

[ Voor 6% gewijzigd door Nano2009 op 16-01-2013 13:12 ]

[Anoniem: 130989]

Ander poortje geprobeerd? (FA3 bijvoorbeeld) beide apparaaten al ge-reboot? 100% zeker van de bekabeling? Kan je testen of de FA4 op komt als je hem ergens anders op aansluit(op 100full)? Gebruikt KPN een media converter, misschien zit daar een mismatch in? Indien alles klopt zit ik haast toch te denken dat KPN een issue heeft

[ Voor 6% gewijzigd door Anoniem: 130989 op 16-01-2013 13:31 ]

[mbaltus]

Als het een Lightning Edge switch is, heb ik dat ook al vaker gezien dat de poort down gaat zodra je het anders instelt. Wat bij mij meestal helpt is kabel eruit en na een seconde of 10 pas terugprikken.

[CyBeR]

Anoniem: 130989 schreef op woensdag 16 januari 2013 @ 13:29:
beide apparaaten al ge-reboot?

Doe dat niet tijdens kantooruren want die lightningedge bakken booten verdomd traag

[Anoniem: 130989]

CyBeR schreef op woensdag 16 januari 2013 @ 14:14:
[...]


Doe dat niet tijdens kantooruren want die lightningedge bakken booten verdomd traag

het was ook een vraag he

[Kabouterplop01]

Nog 1 puntje ( Behalve dan dat je inderdaad die link op 100 MB FD aan de gang moet zien te krijgen ) en dat is dat je de MTU van je dialer 0 op 1492 zet; het is ethernet en pppoe heeft "only" 8 bytes nodig.

bizar dat de link trouwens niet gelijk terugkomt. Lijkt me dan toch iets fysieks tussen switchport WWP kabel, switchport 881. Echt laag 1. (Kabeltje gaar/ports gaar? je hebt er al meerdere geprobeerd, dus dan moet het of de router of de WWP zijn!)
Misschien dat een reboot helpt, maar ik vind het vreemd, dat dat nodig moet zijn

[ Voor 8% gewijzigd door Kabouterplop01 op 17-01-2013 11:10 ]

[CyBeR]

En 1492 + 8 is hoeveel, precies?

[Kabouterplop01]

Ik snap je vlaams niet CyBeR. wat probeer je nou echt te zeggen?
1500 om antwoord te geven; in de laatste show run geeft de dialer 0 mtu 1452.

[CyBeR]

Ah, excuseer ik las iets anders dan je probeerde te zeggen.

Dat aanpassen naar 1492 is een goed idee ja.

[ Voor 102% gewijzigd door CyBeR op 17-01-2013 11:33 ]

[Kabouterplop01]

Tuurlijk het zal werken. Maar als je 1500 - 8 bytes van de pppoe sessie pakt houdt je 1492 over.

[CyBeR]

Het werkt ansich wel maar wellicht niet heel goed in combinatie met de ip tcp adjust-mss 1452.

[Kabouterplop01]

daarom, die is altijd 40 bytes lager dan je MTU (20 bytes voor tcp en 20 bytes voor ip overhead)

[jvanhambelgium]

Kabouterplop01 schreef op donderdag 17 januari 2013 @ 11:30:
Ik snap je vlaams niet CyBeR. wat probeer je nou echt te zeggen?
1500 om antwoord te geven; in de laatste show run geeft de dialer 0 mtu 1452.

Je zet dan de dialer naar 1492 om zeker te zijn dat je niet gaat fragmenteren als er nog 8 bytes van de PPoE overhead/header bijkomen. Dat past dan netjes in een 1500-bytes ethernetframe dan gaat dit niet fragmenteren.

[CyBeR]

Dat klopt, maar in de config is de mtu voor de dialer om de een of andere reden op 1452 gezet, wat de mss moet zijn.

Ik dacht dat Kabouterplop01 stelde dat de mtu in de config op 1492 ingesteld werd maar hij zei juist dat dat gedaan moest worden omdat er nu 1452 staat.

[Kabouterplop01]

Ah Nu snap ik het plaatje cool! Ik heb vast ergens gemist dat die zo aangepast was.!

[jvanhambelgium]

Ik blijf het nog steeds raar vinden, dat het "fenomeen" zich voordoet op het niveau van IP-ranges.
*iedereen* gebruikt de "Dialer" interface met de daaronder liggende Ethernet interface met discussie rond half-duplex (en de zichtbare errors)

In mijn ogen moet *IEDEREEN* last hebben van het fenomeen, nochtans zouden er "upload" testen gedaan zijn waarbij blijkt (en hopelijk repetitief getest) dat de upload van IP-block 1 significant trager is tov upload vian IP-block 2 ??

[Kabouterplop01]

@jvanhambelgium: We gaan er nu wel vanuit dat in deze case alles rechtstreeks op de router hangt; we weten niet of er nog een switch of firewall achterhangt en dáárachter nog IP devices hangen, waarbij er misschien dezelfde errors zijn. Dat zou wel het e.e.a verklaren. Zeker als er 2 devices achter hangen waarop de ip ranges gesplitst zijn: device A > ip reeks A en Device B > ip reeks B. En op bijv Device A eenzelfde soort errors.
(Maar dat is een aanname met in het achterhoofd houdende het spreekwoord over aannames)

[Nano2009]

Oke, nadat KPN heeft ingelogd op de Lighning Edge switch en heeft bevestigd dat de duplex instellingen gewoon op full staan kan ik plotseling wel mijn poort instellingen op full duplex zetten zonder dat de poort eruit knalt

[ Voor 34% gewijzigd door Nano2009 op 18-01-2013 10:11 ]

[jvanhambelgium]

Nano2009 schreef op vrijdag 18 januari 2013 @ 09:52:
Oke, nadat KPN heeft ingelogd op de Lighning Edge switch en heeft bevestigd dat de duplex instellingen gewoon op full staan kan ik plotseling wel mijn poort instellingen op full duplex zetten zonder dat de poort eruit knalt

Da's default policy ;-)
"Neen mijnheer, we hebben niets aangepast hoor ... probeer mischien nog even ?"

[Anoniem: 130989]

Nano2009 schreef op vrijdag 18 januari 2013 @ 09:52:
Oke, nadat KPN heeft ingelogd op de Lighning Edge switch en heeft bevestigd dat de duplex instellingen gewoon op full staan kan ik plotseling wel mijn poort instellingen op full duplex zetten zonder dat de poort eruit knalt

Tuuuuurrlijk

Is je probleem nu ook opgelost ?!