Hallo,
habe hier einen 7100 und darauf 8.82 RC2 laufen.
Ab und zu funktioniert die Internet Verbindung von meinen Notbook nicht mehr, nach 7100 Restart wieder okay.
Anbei ein Trace, was bedeutet "Filter (limited, dropped)" und was kann ich dagegen tun?
Nach dem Reboot ist das "dropped" verschwunden, ich hatte auch einen Firewall Trace an, da kam aber nichts.
Der 7100 konnte die IP-Adresse pingen.
Mit der 8.80 ist mir so etwas noch nicht aufgefallen.
Vielen Dank und viele Grüße
Henri
> ping 173.194.112.120
[IP-Router] 2013/07/06 09:48:47,872
IP-Router Rx (intern, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.0.5, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000e, seq: 0x0000
Route: WAN Tx (INTERNET)
56 Byte Packet from 173.194.112.120 seq.no=0 time=12.220 ms
[IP-Router] 2013/07/06 09:48:48,872
IP-Router Rx (intern, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.0.5, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000e, seq: 0x0001
Route: WAN Tx (INTERNET)
56 Byte Packet from 173.194.112.120 seq.no=1 time=12.119 ms
[IP-Router] 2013/07/06 09:48:49,872
IP-Router Rx (intern, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.0.5, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x000e, seq: 0x0002
Route: WAN Tx (INTERNET)
56 Byte Packet from 173.194.112.120 seq.no=2 time=11.953 ms
---173.194.112.120 ping statistic---
56 Bytes Data, 3 Packets transmitted, 3 Packets received, 0% loss
henri@Router:/
> tr - all
[IP-Router] 2013/07/06 09:48:58,725
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0000
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:48:58,738
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0000
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:48:59,726
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0001
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:48:59,740
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0001
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:49:00,729
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0002
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:49:00,743
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0002
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:49:01,730
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0003
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:49:01,741
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0003
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:49:02,728
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0004
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:49:02,740
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0004
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:49:03,728
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0005
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:49:03,740
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0005
Filter (limited, dropped)
[IP-Router] 2013/07/06 09:49:04,732
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0xc05b, seq: 0x0006
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:49:04,745
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0xc05b, seq: 0x0006
Filter (limited, dropped)
Nach Reboot des 7100:
[IP-Router] 2013/07/06 09:56:15,683
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x215c, seq: 0x0000
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:56:15,697
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x215c, seq: 0x0000
Filter (limited)
[IP-Router] 2013/07/06 09:56:15,697
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x215c, seq: 0x0000
Route: LAN-1 Tx (INTRANET):
[IP-Router] 2013/07/06 09:56:16,681
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 173.194.112.120, SrcIP: 172.20.1.179, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x215c, seq: 0x0001
Route: WAN Tx (INTERNET)
[IP-Router] 2013/07/06 09:56:16,695
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 172.20.1.179, SrcIP: 173.194.112.120, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo reply, id: 0x215c, seq: 0x0001
Filter (limited)
PING 173.194.112.120 (173.194.112.120): 56 data bytes
64 bytes from 173.194.112.120: icmp_seq=0 ttl=56 time=14.092 ms
64 bytes from 173.194.112.120: icmp_seq=1 ttl=56 time=18.658 ms
64 bytes from 173.194.112.120: icmp_seq=2 ttl=56 time=13.828 ms
^C
--- 173.194.112.120 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
8.82.0067RC2 & Filter (limited, dropped)
Moderator: Lancom-Systems Moderatoren
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hi Henri,
"Limited" kommt, wenn entweder eine explizite Limitierung für die Session, zu der das Paket gehört, konfiguriert wurde (Maximal-Bandbreite), oder wenn für eine andere Session eine Mindestbandbreite aktiv ist. Das LANCOM benutzt maximal die Hälfte der Blöcke im WAN-Heap für Limitierungen. Oder genauer: Wenn der WAN-Heap weniger als die Hälfte seiner ursprünglichen Pakete hat, werden keine Blöcke mehr für die Limitierung verwendet. Im Trace erscheint dann "Limited, dropped", weil Limitiert werden sollte, aber kein Block mehr zum Speichern bereit stand.
Die Frage ist nun, warum der WAN-Heap so schrumpft. Entweder das Gerät wird mit viel mehr Daten geflutet als laut Bandbreitenreservierung für unpreviligierte Daten noch zur Verfügung steht - und das über eine extrem lange Zeit, denn ein 7100 hat viele Blöcke im WAN-Heap (1000), oder die Blöcke gehen anderweitig verloren.
Gruß
Backslash
"Limited" kommt, wenn entweder eine explizite Limitierung für die Session, zu der das Paket gehört, konfiguriert wurde (Maximal-Bandbreite), oder wenn für eine andere Session eine Mindestbandbreite aktiv ist. Das LANCOM benutzt maximal die Hälfte der Blöcke im WAN-Heap für Limitierungen. Oder genauer: Wenn der WAN-Heap weniger als die Hälfte seiner ursprünglichen Pakete hat, werden keine Blöcke mehr für die Limitierung verwendet. Im Trace erscheint dann "Limited, dropped", weil Limitiert werden sollte, aber kein Block mehr zum Speichern bereit stand.
Die Frage ist nun, warum der WAN-Heap so schrumpft. Entweder das Gerät wird mit viel mehr Daten geflutet als laut Bandbreitenreservierung für unpreviligierte Daten noch zur Verfügung steht - und das über eine extrem lange Zeit, denn ein 7100 hat viele Blöcke im WAN-Heap (1000), oder die Blöcke gehen anderweitig verloren.
Gruß
Backslash
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo \,
habe einmal ein Ticket gegen die 8.80 aufgemacht, #1307.1016.3604.SGÜß .
Es sind 13MB Show Heap, scheint also recht voll zu sein.
Vielen Dank und viele Grüße
Henri
habe einmal ein Ticket gegen die 8.80 aufgemacht, #1307.1016.3604.SGÜß .
Es sind 13MB Show Heap, scheint also recht voll zu sein.
Vielen Dank und viele Grüße
Henri
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo,
ich habe eine FW Rule mit Drop bei 60% Global für die Synchronisation der Backup Server via VPN definiert.
GGf. verursacht diese Rule das Problem.
Der 1781VAW verhält sich problemloser auf der anderen Seite.
sh heap:
| 0x0a89bf20 | 000001a0 | OC | 61 64 2e 64 65 2e 64 6f 75 62 6c 65 63 6c 69 63 |
| 0x0a89c0e0 | 000001a0 | OC | 0a 88 26 48 69 76 77 62 6f 78 2e 64 65 2f 63 67 |
| 0x0a89c2a0 | 00010020 | Yz | 73 68 20 68 65 61 70 0d 20 32 30 30 20 4f 4b 0d |
| 0x0a8ac2e0 | 00010020 | Yz | 30 61 20 36 30 20 32 65 20 37 63 20 30 61 20 36 |
| 0x0a8bc320 | 15743ca0 | -- | load/store protected memory !!! |
|------------|----------|-------|-------------------------------------------------|
103097 | 1e7908a0
Viele Grüße
Henri
ich habe eine FW Rule mit Drop bei 60% Global für die Synchronisation der Backup Server via VPN definiert.
GGf. verursacht diese Rule das Problem.
Der 1781VAW verhält sich problemloser auf der anderen Seite.
sh heap:
| 0x0a89bf20 | 000001a0 | OC | 61 64 2e 64 65 2e 64 6f 75 62 6c 65 63 6c 69 63 |
| 0x0a89c0e0 | 000001a0 | OC | 0a 88 26 48 69 76 77 62 6f 78 2e 64 65 2f 63 67 |
| 0x0a89c2a0 | 00010020 | Yz | 73 68 20 68 65 61 70 0d 20 32 30 30 20 4f 4b 0d |
| 0x0a8ac2e0 | 00010020 | Yz | 30 61 20 36 30 20 32 65 20 37 63 20 30 61 20 36 |
| 0x0a8bc320 | 15743ca0 | -- | load/store protected memory !!! |
|------------|----------|-------|-------------------------------------------------|
103097 | 1e7908a0
Viele Grüße
Henri
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hi Henri,
Gruß
Backslash
mit Heap, meinte ich nicht den Speicher, sondern den LAN- bzw. WAN-Heap (zu finden unter /status/LAN, bzw. Status/WAN). Wenn die Werte, die dort stehen dauerhaft kleiner als die Hälfte ihres Wertes nach einem Boot sind, gibt es ein Problem.Es sind 13MB Show Heap, scheint also recht voll zu sein.
das könnte schonmal ein Ansatz sein... Da hältst du 40% Bandbreite frei, die schnell mit irgendwelchen anderen Paketen geflutet werden können - und dann wird halt irgendwann nicht mehr gepuffert, sondern hart verworfen. Daher solltest du z.B. pings ganz von derartigen Limitierungen ausnehmenich habe eine FW Rule mit Drop bei 60% Global für die Synchronisation der Backup Server via VPN definiert.
GGf. verursacht diese Rule das Problem.
Gruß
Backslash
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo \,
die Rule bezieht sich nur auf Port 14433 für eine spezifische Verbindung, Pings in die weite Welt sind nicht betroffen.
Anbei die Werte, kaum Abweichungen zum Zustand nach dem Booten, allerdings mit 8.80. Sobald ich wieder etwas Zeit habe,
versuche ich es wieder mit der 8.82RC2.
Vielen Dank und viele Grüße
Henri
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 4992
WAN-Queue-Packets INFO: 9
WAN-Queue-Errors INFO: 0
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
LAN-Heap-Packets INFO: 14982
Delete-Values ACTION:
LAN-Queue-Mgt-Drop INFO: 0
Interfaces TABINFO: 4 x [Ifc,Queue-Packets,Link-Active]
Byte-Transport TABINFO: 4 x [Ifc,Tx-Bytes,Rx-Bytes,Throughput,..]
Packet-Transport TABINFO: 4 x [Ifc,Rx-Packets,Tx-Packets,Rx-Broadcasts,..]
Errors TABINFO: 4 x [Ifc,Rx-Errors,Tx-Errors,NIC-Errors,..]
die Rule bezieht sich nur auf Port 14433 für eine spezifische Verbindung, Pings in die weite Welt sind nicht betroffen.
Anbei die Werte, kaum Abweichungen zum Zustand nach dem Booten, allerdings mit 8.80. Sobald ich wieder etwas Zeit habe,
versuche ich es wieder mit der 8.82RC2.
Vielen Dank und viele Grüße
Henri
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 4992
WAN-Queue-Packets INFO: 9
WAN-Queue-Errors INFO: 0
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
LAN-Heap-Packets INFO: 14982
Delete-Values ACTION:
LAN-Queue-Mgt-Drop INFO: 0
Interfaces TABINFO: 4 x [Ifc,Queue-Packets,Link-Active]
Byte-Transport TABINFO: 4 x [Ifc,Tx-Bytes,Rx-Bytes,Throughput,..]
Packet-Transport TABINFO: 4 x [Ifc,Rx-Packets,Tx-Packets,Rx-Broadcasts,..]
Errors TABINFO: 4 x [Ifc,Rx-Errors,Tx-Errors,NIC-Errors,..]
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo \,
ich habe seit einer Woche ein Ticket bei KabelBW eröffnet (garantierte Entstörung in 12h), der Downstream schafft zwischen 2,5 und 35 Mbit bei vertraglich garantierten >90 Mbit.
Vermutlich bringt dieses Verhalten den Heap zum Überlaufen (wenn QOS genutzt wird) besonders bei Drops (für unsere Offsite SAN Replikation).
Ich habe hier einige Monate mit Problemen laboriert, die Effekte sind je nach Traffic sehr interessant.
Keine Ahnung ob so etwas geht, aber irgendein Hinweis auf so ein Problem in einem zukünftigen LCOS wäre sehr hilfreich.
Es ist halt auch nicht immer praktikabel, die Macs der statischen IPs auf ein Notebook zu definieren nur um Messungen der Bandbreite durchzuführen.
Vielen Dank und viele Grüße
Henri
ich habe seit einer Woche ein Ticket bei KabelBW eröffnet (garantierte Entstörung in 12h), der Downstream schafft zwischen 2,5 und 35 Mbit bei vertraglich garantierten >90 Mbit.
Vermutlich bringt dieses Verhalten den Heap zum Überlaufen (wenn QOS genutzt wird) besonders bei Drops (für unsere Offsite SAN Replikation).
Ich habe hier einige Monate mit Problemen laboriert, die Effekte sind je nach Traffic sehr interessant.
Keine Ahnung ob so etwas geht, aber irgendein Hinweis auf so ein Problem in einem zukünftigen LCOS wäre sehr hilfreich.
Es ist halt auch nicht immer praktikabel, die Macs der statischen IPs auf ein Notebook zu definieren nur um Messungen der Bandbreite durchzuführen.
Vielen Dank und viele Grüße
Henri
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo,
funktioniert noch immer nicht, ich habe ein neues Ticket aufgemacht, 1307.2615.3845.SGÜß.
Die KabelBW Verbindung funktioniert jetzt ohne mein Zutun korrekt, habe wieder 100Mbit.
Anbei die Heaps vor und nach Reboot.
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 1384
WAN-Queue-Packets INFO: 0
WAN-Queue-Errors INFO: 104270
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
Nach Boot:
root@Router:/Status/WAN
> dir
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 4992
WAN-Queue-Packets INFO: 0
WAN-Queue-Errors INFO: 0
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
Danke
Henri
funktioniert noch immer nicht, ich habe ein neues Ticket aufgemacht, 1307.2615.3845.SGÜß.
Die KabelBW Verbindung funktioniert jetzt ohne mein Zutun korrekt, habe wieder 100Mbit.
Anbei die Heaps vor und nach Reboot.
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 1384
WAN-Queue-Packets INFO: 0
WAN-Queue-Errors INFO: 104270
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
Nach Boot:
root@Router:/Status/WAN
> dir
Byte-Transport TABINFO: 11 x [Ifc,CRx-Bytes,Rx-Bytes,Tx-Bytes,..]
Packet-Transport TABINFO: 11 x [Ifc,Rx,Tx-total,Tx-normal,Tx-reliable,..]
Errors TABINFO: 11 x [Ifc,Rx-l1-Error,Rx-l2-Error,..]
WAN-Tx-Discarded INFO: 0
WAN-Heap-Packets INFO: 4992
WAN-Queue-Packets INFO: 0
WAN-Queue-Errors INFO: 0
WAN-Queue-Mgt-Drop INFO: 0
Throughput TABINFO: 11 x [Ifc,Rx/s,Tx/s,Rx/s,Tx/s]
Delete-Values ACTION:
Connections INFO: 3
MTU TABINFO: 16 x [Peer,MTU]
Encrypted-Connections INFO: 1
Actions MENU:
Danke
Henri
Re: 8.82.0067RC2 & Filter (limited, dropped)
Hallo \,
sorry dass ich trotz Ticket auf diesem Weg nachfrage, aber das Ticket ist schon seit 2 Monaten offen.
Gibt es eine Möglichkeit den Inhalt des WAN-Heaps anzuzeigen?
Sobald ich auf eine FW > 8.80 gehe ist nach ca. 4 Stunden der WAN-Heap bei 2-100 von 4600 nach dem Booten.
Habe schon jede Menge QOS ausgeschaltet, aber bisher ohne Änderung des Verhaltens des Gerätes.
Vielen Dank
Henri
sorry dass ich trotz Ticket auf diesem Weg nachfrage, aber das Ticket ist schon seit 2 Monaten offen.
Gibt es eine Möglichkeit den Inhalt des WAN-Heaps anzuzeigen?
Sobald ich auf eine FW > 8.80 gehe ist nach ca. 4 Stunden der WAN-Heap bei 2-100 von 4600 nach dem Booten.
Habe schon jede Menge QOS ausgeschaltet, aber bisher ohne Änderung des Verhaltens des Gerätes.
Vielen Dank
Henri