(fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

[Jirka]

Hallo,

ich habe hier einen 7100+ der nicht jeden Tag, aber regelmäßig 100 % CPU-Last hat, obwohl (fast) nichts zu tun ist.

Kurz zur Konfig:
- zwei lokale Netze
- Content-Filter
- 9 VPN-Verbindungen (IKEv1)
- Load-Balancer

Firmware: 9.24.0334-SU9 (die Probleme traten aber auch schon vorher auf)

Probleme:
- gelegentlich (ca. alle 5 Tage) nach der der 24-h-Zwangstrennung zuvorkommenden Verbindungstrennung 100 % CPU-Last; nach genau 32 Min. erledigt sich das Problem von selbst, die CPU-Last geht dann wieder auf für die Uhrzeit normale Werte von 0 bis 1 % zurück
- gelegentlich (ca. alle 14 Tage) wird eine der beiden Gegenstellen (T-DSLBIZ und T-DSLBIZ-ADSL) nach der der 24-h-Zwangstrennung zuvorkommenden Verbindungstrennung einfach nicht wieder aufgebaut; das Gerät macht keinerlei Aufbauversuche, nur ein Neustart führt wieder in einen normalen Zustand

So sieht das mit der CPU-Last aus:

2017-11-29 07_26_07-PRTG Network Monitor (SERVER) _ Details des Sensors.png

Nun habe ich gedacht, mach mal bei den 100 % CPU-Last ein 'show jobs', damit man weiß, wo die 100 % verpulvert werden. Demnach scheint es irgendwie im VPN zu hakeln:

Code: Alles auswählen

|--------|----------------------------------|--------|----------|-----------|--------|--------|------------|
|        |                                  | [%]    | [us]     |           | Prio,  | Stack  |            |
| PID    | Name                             | Load   | Latency  | State     | Flags  | size   | Address    |
|--------|----------------------------------|--------|----------|-----------|--------|--------|------------|
|      1 | Idle                             |   0    |    54580 |  RUNNING  | U-15   |  16000 | 0004016160 | 
|      3 | Hardware Watchdog                |   0    |        0 | WAITTIME  | U-00 T |   1000 | 0067200768 | 
|      4 | Message-Watchdog                 |   0    |        0 | WAITTIME  | U-05 T |   1000 | 0067206048 | 
|      5 | LW                               |   0    |        5 |  WAITEXE  | U-08W  |   1000 | 0002191fb0 | 
|      6 | B2-V110                          |   0    |        2 |  WAITMSG  | U-06W  |   1000 | 000218cd08 | 
|      7 | Heap-Check                       |   0    |       40 |  WAITMSG  | U-08W  |   1000 | 000a520fe0 | 
|      8 | 1TR6                             |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000a425880 | 
|      9 | ISDN-D3                          |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000a423440 | 
|     10 | DF                               |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000218ca80 | 
|     11 | D2                               |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000218c860 | 
|     12 | DM                               |   0    |        7 |  WAITMSG  | U-07W  |   1000 | 000218c660 | 
|     13 | Sip Alg                          |   0    |       10 |  WAITMSG  | U-08W  |   4000 | 000a41c360 | 
|     14 | VX                               |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000218aaf8 | 
|     15 | MyVPN                            |   0    |        3 |  WAITMSG  | U-08W  |   1000 | 000a4410a0 | 
|     16 | Notifier-Filesystem              |   0    |        0 |  WAITMSG  | U-08 T |   4000 | 0009fc8240 | 
|     17 | IPV6                             |   0    |        1 |  WAITMSG  | U-08W  |   2000 | 0009fcc520 | 
|     19 | GY                               |   0    |        4 |  WAITMSG  | U-08W  |   2000 | 0002189a08 | 
|     20 | GX                               |   0    |        4 |  WAITMSG  | U-08W  |   2000 | 0002189778 | 
|     23 | PPPoE-Server                     |   0    |       17 |  WAITMSG  | U-08W  |   2000 | 000a447a40 | 
|     25 | WP                               |   0    |        4 |  WAITMSG  | U-08W  |   1000 | 0002187218 | 
|     26 | Net-Trace                        |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000a44a7c0 | 
|     27 | GD                               |   0    |      114 |  WAITMSG  | U-08W  |   3000 | 0002186538 | 
|     28 | CO                               |   0    |       17 |  WAITMSG  | U-08W  |   1000 | 0002185380 | 
|     29 | RC                               |   0    |    15286 |  WAITMSG  | U-08W  |   2000 | 0002185018 | 
|     30 | LL                               |   0    |      248 |  WAITMSG  | U-08W  |   1000 | 000216bf08 | 
|     31 | ES                               |   0    |       30 |  WAITMSG  | U-08W  |   4000 | 000216b4d0 | 
|     32 | Iperf-Manager                    |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 00129166e0 | 
|     33 | Tacacs+-Client                   |   0    |        8 |  WAITMSG  | U-08W  |   2000 | 0012919940 | 
|     34 | Orange-Filter-Client             |   0    |        0 |  WAITMSG  | U-08 T |  14000 | 000b090900 | 
|     35 | IT                               |   0.03 |        0 |  WAITEXE  | U-05   |   1000 | 000213acb0 | 
|     36 | ECC-Log                          |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000a40e120 | 
|     37 | IM                               |   0    |        0 |  WAITEXE  | U-00 T |  10000 | 0002124888 | 
|     38 | Reset-Button                     |   0    |       10 |  WAITMSG  | U-01W  |   1000 | 000a40f940 | 
|     39 | Busy-Block-Device                |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000a413140 | 
|     40 | GH                               |   0    |        3 |  WAITMSG  | U-08W  |   3000 | 0002123e88 | 
|     41 | CCont                            |   0    |      413 |  WAITMSG  | U-08W  |   1000 | 0002122a18 | 
|     42 | IS                               |   0    |       28 |  WAITMSG  | U-08W  |   2000 | 0002122868 | 
|     43 | B3                               |   0    |        7 |  WAITMSG  | U-08W  |   1000 | 0002121088 | 
|     44 | B2                               |   0    |        5 |  WAITMSG  | U-08W  |   1000 | 000211eb60 | 
|     45 | B1-Serial                        |   0    |        8 |  WAITMSG  | U-06W  |   1000 | 000211ce50 | 
|     46 | BP                               |   0    |        9 |  WAITEXE  | U-08W  |   1000 | 000211dbe8 | 
|     47 | B2-PPPOE                         |   0    |       85 |  WAITMSG  | U-08W  |   1000 | 000211cb30 | 
|     48 | KF                               |   0    |      112 |  WAITMSG  | U-08W  |   1000 | 000211c660 | 
|     49 | KT                               |   0    |        9 |  WAITMSG  | U-08W  |   1000 | 000211c270 | 
|     50 | YF                               |   0    |        8 |  WAITMSG  | U-08W  |   1100 | 0002116590 | 
|     51 | CRL-Client                       |   0    |        0 |  WAITMSG  | U-08 T |   4000 | 000a431580 | 
|     52 | VE                               |  18.47 |       57 |  RUNNING  | U-08W  |  10000 | 0002113778 | 
|     53 | UA                               |   0    |       26 |  WAITMSG  | U-08W  |   1000 | 0002110378 | 
|     54 | VPN-Ifc                          |   0    |      381 |  WAITMSG  | U-08W  |   2000 | 000a435860 | 
|     55 | Fat-Filesystem                   |   0    |        0 |  WAITMSG  | U-06 T |   2000 | 000a437b40 | 
|     56 | BlkDev-Mounter                   |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000a439e20 | 
|     57 | Auto-Load                        |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000a43cf00 | 
|     59 | IPV6-Firewall-Config             |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000a49aa20 | 
|     60 | AC                               |   0    |      288 |  WAITMSG  | U-08W  |   1000 | 000210a730 | 
|     61 | Serial-Trace                     |   0    |       18 |  WAITMSG  | U-08W  |   1000 | 000a4ae640 | 
|     62 | License-Management               |   0    |       24 |  WAITMSG  | U-08W  |   1000 | 000a4afec0 | 
|     63 | Pc                               |   0    |        3 |  WAITMSG  | U-08W  |   1000 | 00021061a0 | 
|     64 | LZ                               |   0    |        8 |  WAITMSG  | U-08W  |   2000 | 0002105e48 | 
|     65 | Yf                               |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 0002105c48 | 
|     66 | Yb                               |   0    |   230094 |  WAITMSG  | U-10W  |   4000 | 0002105a78 | 
|     67 | YS                               |   0    |      414 |  WAITMSG  | U-08W  |   1000 | 00021057d0 | 
|     68 | HTTP-Server                      |   0    |     8339 |  WAITMSG  | U-08W  |   4000 | 000a4b2800 | 
|     69 | HttpClientAuth Revocation        |   0    |        0 | WAITTIME  | U-08 T |   1000 | 0172727776 | 
|     70 | hT                               |   0    |       10 |  WAITMSG  | U-08W  |   1000 | 00021003f0 | 
|     71 | GC                               |   0    |        0 |  WAITMSG  | U-08W  |   2000 | 00020fae40 | 
|     72 | RB                               |   0    |        3 |  WAITMSG  | U-08W  |   3000 | 00020f9658 | 
|     73 | TCP                              |   0    |     1520 |  RUNNING  | U-08W  |   2000 | 000a4c4dc0 | 
|     74 | TF                               |   0    |      544 |  WAITMSG  | U-08W  |   2000 | 00020f4a78 | 
|     75 | IPV4                             |  64.54 |     3703 |  RUNNING  | U-08W  |   4000 | 000a4c7a60 | 
|     76 | Domain Name System               |   0    |      897 |  WAITMSG  | U-08W  |   2000 | 000a4d0860 | 
|     77 | Load-Balancer                    |   0    |      136 |  WAITMSG  | U-08W  |   2000 | 000a4d3d40 | 
|     78 | PPTP                             |   0    |       16 |  WAITMSG  | U-08W  |   2000 | 000a4d6200 | 
|     79 | VR                               |   0    |       12 |  WAITMSG  | U-08W  |   2000 | 00020f12f0 | 
|     80 | MI                               |  16.68 |      131 |  RUNNING  | U-08W  |   2000 | 00020f0d90 | 
|     81 | SV                               |   0    |      237 |  WAITMSG  | U-08W  |   1000 | 00020f0a90 | 
|     82 | DS                               |   0    |     1768 |  WAITMSG  | U-08W  |   2000 | 00020efc50 | 
|     83 | DC                               |   0    |        1 |  WAITMSG  | U-08W  |   1000 | 00020ef860 | 
|     84 | IP-RIP                           |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000a4d91c0 | 
|     85 | SF                               |   0.01 |     5943 |  WAITMSG  | U-08W  |   3000 | 00020ea5c8 | 
|     86 | NB                               |   0    |        8 |  WAITMSG  | U-08W  |   2000 | 00020e9e60 | 
|     87 | NC                               |   0    |       97 |  WAITMSG  | U-08W  |   2000 | 00020e9b50 | 
|     88 | MQ                               |   0    |       13 |  WAITMSG  | U-08W  |   4000 | 00020e9668 | 
|     89 | MA                               |   0    |     4750 |  RUNNING  | U-09W  |   1000 | 00020e9800 | 
|     90 | PS                               |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 00020e8b80 | 
|     91 | YCON                             |   0    |      213 |  WAITMSG  | U-08W  |   2000 | 00020e8498 | 
|     92 | TL                               |   0    |     4170 |  WAITMSG  | U-08W  |   4000 | 00020e82b8 | 
|     93 | TS                               |   0    |       87 |  WAITMSG  | U-08W  |   1000 | 00020e7ff8 | 
|     94 | CH                               |   0    |       12 |  WAITMSG  | U-08W  |   2000 | 00020e1fd0 | 
|     95 | AH                               |   0    |     2602 |  WAITMSG  | U-08W  |   2000 | 00020e1dc0 | 
|     96 | PPP                              |   0    |      195 |  WAITMSG  | U-08W  |   2000 | 000a4dda20 | 
|     97 | ICMP-Polling                     |   0    |       24 |  WAITMSG  | U-08W  |   1000 | 00020e1330 | 
|     98 | Connection-Control               |   0    |      170 |  WAITMSG  | U-08W  |   2000 | 000b2ce620 | 
|     99 | I2C-Irq-Cntr                     |   0.01 |        9 |  WAITMSG  | U-05W  |   1000 | 000b2d16e0 | 
|    100 | B1-xDSL                          |   0    |       26 |  WAITMSG  | U-08W  |   1000 | 000b32c380 | 
|    101 | ETH-1-Driver                     |   0.04 |     3114 |  WAITMSG  | U-08W  |   3000 | 000b32e2c0 | 
|    102 | ETH-2-Driver                     |   0.04 |     3095 |  WAITMSG  | U-08W  |   3000 | 000b446940 | 
|    103 | ETH-3-Driver                     |   0.04 |     3093 |  WAITMSG  | U-08W  |   3000 | 000b55ee60 | 
|    104 | ETH-4-Driver                     |   0.04 |     3095 |  WAITMSG  | U-08W  |   3000 | 000a5ab480 | 
|    105 | DSL-1-Driver                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000a6c38e0 | 
|    106 | DSL-2-Driver                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000a6c5a60 | 
|    107 | DSL-3-Driver                     |   0    |        3 |  WAITMSG  | U-08W  |   1000 | 000a6c7be0 | 
|    108 | DSL-4-Driver                     |   0    |        1 |  WAITMSG  | U-08W  |   1000 | 000a6c9d60 | 
|    109 | xhfc_d1_task                     |   0    |        4 |  WAITMSG  | U-01W  |   1000 | 000a6cd620 | 
|    110 | Interface-observer               |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000a6d3e60 | 
|    111 | Cron                             |   0    |       21 |  WAITMSG  | U-08W  |   3000 | 000a6d9100 | 
|    112 | Backup                           |   0    |        0 |  WAITMSG  | U-08W  |   2000 | 000a6ea2a0 | 
|    113 | Cont                             |   0    |     1500 |  WAITMSG  | U-08W  |   2000 | 000a6f2240 | 
|    114 | IPv4-Config                      |   0    |      296 |  WAITMSG  | U-08W  |   5000 | 000cb687a0 | 
|    115 | RADIUS-Client                    |   0    |        0 |  WAITMSG  | U-08W  |   4000 | 000cc0fac0 | 
|    116 | RADIUS-Server                    |   0    |        9 |  WAITMSG  | U-08W  |   4000 | 000cc177c0 | 
|    117 | EAP-TLS                          |   0    |     2385 |  WAITMSG  | U-08W  |   4000 | 000cc22500 | 
|    118 | LAN-1-Driver                     |   0    |        9 |  WAITMSG  | U-08W  |   1000 | 000cc31380 | 
|    119 | LAN-2-Driver                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000cc33700 | 
|    120 | LAN-3-Driver                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000cc35980 | 
|    121 | LAN-4-Driver                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000cc37c00 | 
|    122 | Lan-Auth                         |   0    |       17 |  WAITMSG  | U-08W  |   5000 | 000cc39ea0 | 
|    123 | VLAN                             |   0    |       23 |  WAITMSG  | U-08W  |   1000 | 000cc4ed00 | 
|    124 | WAN-LSL                          |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000cc56c80 | 
|    125 | LED-Control                      |   0    |       18 |  WAITMSG  | U-07W  |   1000 | 000d843aa0 | 
|    126 | SMTP-Client                      |   0    |       19 |  WAITMSG  | U-08W  |   2000 | 000d84c800 | 
|    127 | RGW-Cache                        |   0    |       97 |  WAITMSG  | U-08W  |   2000 | 000d86fa00 | 
|    128 | DHCP-RADIUS-Accounting           |   0    |        5 |  WAITMSG  | U-08W  |   2000 | 000db0aa00 | 
|    129 | SSL-KeyGen                       |   0    |    34332 |  WAITMSG  | U-10W  |   4000 | 000db4fa60 | 
|    130 | SSL-KeyGen                       |   0    |    12341 |  WAITMSG  | U-10W  |   4000 | 000db53f20 | 
|    131 | SSL/TLS                          |   0    |      359 |  WAITMSG  | U-08W  |   1000 | 000db5a180 | 
|    132 | Ipsec-Encaps                     |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000db66b20 | 
|    133 | VPN-Catcher                      |   0    |      156 |  WAITMSG  | U-08W  |   2000 | 000db68040 | 
|    134 | VPN-IKE                          |   0    |        0 |  WAITMSG  | U-08 T |  3c000 | 000dc20360 | 
|    135 | SNMP-Server                      |   0    |        0 |  WAITMSG  | U-08   |   2000 | 000dc6f2e0 | 
|    136 | SNMP-LANMonitor-Notification     |   0    |      277 |  WAITMSG  | U-08W  |   1000 | 000dc72180 | 
|    137 | X.25-Bridge                      |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000dc80a60 | 
|    138 | OCSP-Client                      |   0    |        7 |  WAITMSG  | U-08W  |   1000 | 000dc83400 | 
|    139 | GRE-Protocol                     |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000dc890c0 | 
|    140 | GRE-IP-Tunnel                    |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000dc8ac00 | 
|    141 | SCEP-CA                          |   0    |        0 |  WAITMSG  | U-08 T |   8000 | 000dc8e020 | 
|    142 | Syslog                           |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000dc9a0c0 | 
|    143 | Volume-Budgets                   |   0    |    11265 |  WAITMSG  | U-08W  |   1000 | 000dca2a00 | 
|    144 | Radius-Login                     |   0    |        5 |  WAITMSG  | U-08W  |   1000 | 000dca5000 | 
|    145 | IPv6-Tunnels                     |   0    |        4 |  WAITMSG  | U-08W  |   2000 | 000dd422e0 | 
|    146 | DHCPv6-Server-and-Relay          |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000dd4e7c0 | 
|    147 | SLA-Monitor                      |   0    |       11 |  WAITMSG  | U-08W  |   1000 | 000dd54f20 | 
|    148 | HTTP-Main                        |   0    |      487 |  WAITMSG  | U-08W  |   2000 | 000dd5d380 | 
|    149 | ARP                              |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000e080600 | 
|    150 | TFTP-Scan                        |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000e085240 | 
|    151 | NTP-Server                       |   0    |     1026 |  WAITMSG  | U-08W  |   2000 | 000e087e60 | 
|    152 | IGMP                             |   0    |       11 |  WAITMSG  | U-08W  |   2000 | 000e09d980 | 
|    153 | ICMP                             |   0    |       34 |  WAITMSG  | U-08W  |   2000 | 000e09fe00 | 
|    154 | free-pb-status                   |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e0c5480 | 
|    155 | Performance-Monitor              |   0    |        2 |  WAITMSG  | U-08W  |   1000 | 000e0c95e0 | 
|    157 | Echo-Server                      |   0    |       24 |  WAITMSG  | U-07W  |   1000 | 000e0cbfe0 | 
|    158 | Printer-Control                  |   0    |        0 |  WAITMSG  | U-08W  |   8000 | 000e0cd840 | 
|    159 | Tcp-Listener                     |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000e1335a0 | 
|    160 | R1                               |   0    |        0 |  WAITEXE  | U-08W  |   3000 | 000e162620 | 
|    163 | kt                               |   0    |      172 |  WAITMSG  | U-00W  |   1000 | 000e1b1740 | 
|    164 | USB-TTY                          |   0    |        0 |  WAITMSG  | U-06W  |   3000 | 000e1b29e0 | 
|    165 | USB-Control                      |   0    |       42 |  WAITMSG  | U-06W  |   1000 | 000e1b0280 | 
|    166 | USB-Softint                      |   0    |        0 |  WAITMSG  | U-06W  |   2000 | 000e1b5ec0 | 
|    167 | USB-Timer                        |   0    |        6 |  WAITMSG  | U-06W  |   1000 | 000e1b83e0 | 
|    168 | HTTP-Worker                      |   0    |        0 |  WAITMSG  | U-08 T |   5000 | 000e1bf1a0 | 
|    169 | HTTP-Worker                      |   0    |        0 |  WAITMSG  | U-08 T |   5000 | 000e1c4480 | 
|    170 | HTTP-Worker                      |   0    |        0 |  WAITMSG  | U-08 T |   5000 | 000e1c9ac0 | 
|    171 | HTTP-Worker                      |   0    |        0 |  WAITMSG  | U-08 T |   5000 | 000e1cf360 | 
|    172 | HTTP-Worker                      |   0    |        0 |  WAITMSG  | U-08 T |   5000 | 000e1d4c00 | 
|    174 | SEC2/3-Controller                |   0    |     1081 |  WAITMSG  | U-08W  |   1000 | 000e20a060 | 
|    175 | Diffie-Hellman-Precalc           |   0    |        0 | WAITTIME  | U-14 T |   2000 | 0237025376 | 
|    176 | VPN-Config                       |   0    |        0 |    WAIT   | U-08 T |   2000 | 0237034048 | 
|    177 | ErrorAging                       |   0    |       95 |  WAITMSG  | U-10W  |   3000 | 000e211340 | 
|    178 | Outband-Read                     |   0    |        0 | WAITTIME  | U-08 T |   1000 | 0237092160 | 
|    179 | Job-Mgt-Super                    |   0    |       15 |  WAITMSG  | U-05W  |   1000 | 000e21cf20 | 
|    180 | SNMP-Notification-Server         |   0    |     1895 |  WAITMSG  | U-08W  |   1000 | 000e222080 | 
|    181 | Iperf-UDP-Reporter               |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e227900 | 
|    182 | Iperf-UDP-Server                 |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e228be0 | 
|    183 | Iperf-TCP-Reporter               |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e229ec0 | 
|    184 | Iperf-TCP-Server                 |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e22b1a0 | 
|    185 | Route-Monitor                    |   0    |       13 |  WAITMSG  | U-08W  |   1000 | 000e22d0a0 | 
|    186 | BGP-Master-Control               |   0    |        0 |    WAIT   | U-08 T |   1000 | 0237168640 | 
|    187 | BGP                              |   0    |        0 |  WAITMSG  | U-08W  |   1000 | 000e22fb60 | 
|    188 | IPV6-Config                      |   0    |        0 |  WAITMSG  | U-08 T |   3000 | 000e241a00 | 
|    189 | L2TP                             |   0    |       21 |  WAITMSG  | U-08W  |   2000 | 000e244ce0 | 
|    190 | Transport store                  |   0    |       90 |  WAITMSG  | U-08W  |   1000 | 000e247060 | 
|    191 | Scep-Clients-Manager             |   0    |        0 |  WAITMSG  | U-08 T |   2000 | 000e24e240 | 
|    192 | DS-Lite                          |   0    |        5 |  WAITMSG  | U-08W  |   2000 | 000e250e20 | 
|    193 | DHCPv6-Management                |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000e259da0 | 
|    194 | IPv4-WAN-Status                  |   0    |       14 |  WAITMSG  | U-08W  |   2000 | 000edbe080 | 
|    195 | IPv6-WAN-Status                  |   0    |        0 |  WAITMSG  | U-08W  |   2000 | 000edc0360 | 
|    196 | IPV4-Config                      |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 000edc2720 | 
|    197 | RolloutAgent                     |   0    |        0 |  WAITMSG  | U-08W  |   2000 | 000edc4000 | 
|    199 | PbSpot-XML                       |   0    |        0 |  WAITMSG  | U-08W  |   4000 | 000ee05020 | 
|    200 | HttpClientTask                   |   0    |        0 |  WAITMSG  | U-08W  |   2000 | 000ee11260 | 
|    201 | CF-Proxy-Mgmt                    |   0    |      493 |  WAITMSG  | U-08W  |   1000 | 000ee187a0 | 
|    203 | USB-Device                       |   0    |       34 |  WAITEXE  | U-06W  |   2000 | 00021b48e0 | 
|    204 | USB-HC                           |   0    |        0 |  WAITEXE  | U-06W  |   2000 | 00021b6f00 | 
|    205 | USB-DR                           |   0    |        0 |  WAITEXE  | U-06W  |   2000 | 00021b9520 | 
|    207 | USB-Device                       |   0    |       44 |  WAITEXE  | U-06W  |   2000 | 000ee726c0 | 
|    208 | Memory-Watch                     |   0    |        8 |  WAITMSG  | U-08W  |   1000 | 000ee933e0 | 
|    209 | WAN-Observer                     |   0    |       15 |  WAITMSG  | U-08W  |   2000 | 000ef0b200 | 
|  22330 | challenge-manager                |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 0011e8af40 | 
|  93956 | CF-Proxy-Conn                    |   0    |      209 |  WAITEXE  | U-08W  |   8000 | 0010dc5660 | 
| 269839 | CF-Proxy-Conn                    |   0    |      225 |  WAITEXE  | U-08W  |   8000 | 00050dd4e0 | 
| 682619 | Smartticket                      |   0    |        6 |  WAITMSG  | U-08W  |   1000 | 0011769e80 | 
| 682620 | pb-capacity-monitor              |   0    |        0 |  WAITMSG  | U-08 T |   1000 | 0011333120 | 
| 685581 | CF-Proxy-Conn                    |   0    |      288 |  WAITEXE  | U-08W  |   8000 | 0010767b40 | 
| 905926 | R3                               |   0    |     1388 |  RUNNING  | U-08   |   3000 | 00071b8980 | 
| 905930 | CF-Proxy-Conn                    |   0    |      244 |  WAITEXE  | U-08W  |   8000 | 000efa6f60 | 
|--------|----------------------------------|--------|----------|-----------|--------|--------|------------|
|        |                                  | 100.00 |          |           |        | 216100 |            |
|--------|----------------------------------|--------|----------|-----------|--------|--------|------------|

Was treibt der LANCOM da jetzt mit den VPNs, die nach den Trennungen alle wieder ordentlich aufgebaut werden, dass da diese CPU-Last zu Stande kommt? RAM ist während der Zeit unauffällig und ohne zusätzlichen Verbrauch. Traffic ins Internet ist auch nicht wirklich in messbaren Größen um die Uhrzeit, also irgendwas unter 40 kbit/s.

Was kann ich jetzt tun, um die Probleme weiter einzugrenzen? Welcher Trace wäre evt. sinnvoll?

Vielen Dank und viele Grüße,
Jirka

[COMCARGRU]

Ein ähnlich merkwürdiges Last-Verhalten hatte ich hier ja auch schon mal mit einer 8011 bzw 9100er erwähnt. Weil die Box dann gar nicht mehr reagiert und nur Steckerziehen half, war da auch nichts mehr mit Traces etc. zu machen.

Mit der 9er Firmware ist es besser geworden, vmtl. weil der IP-Stack dann mit der Last besser zurecht kommt. Und mittlerweile mit der 9100+ hat die Kiste genug Power um wenigstens weiter zu reagieren. Da war dann zu ermitteln, das es reproduzierbar an einem eingewählten Advanced Client lag. Schoß man den raus, ging die CPU Last schlagartig zurück.

Um es noch besser zu machen - das Problem mit diesem bestimmten Client tritt nur auf, wenn dieser in bestimmten Netzen unterwegs ist und nicht grundsätzlich. Weiter habe ich das aber nicht verfolgt, weil der betroffene Client nur selten in einem dieser Problemnetze ist und dann dort ja nicht zum Spaß um VPN Fehler zu finden. Insofern hat der Anwender die Anweisung sich aus diesen Netzen heraus nicht einzuwählen, was zum Glück in diesem Fall kein Problem darstellt. Wenn mal Zeit ist, versuche ich mal zu ergründen was der Client in so einer Situation wirklich treibt...

Aber auch hier: VPN tötet CPU per 100% Last!

[Jirka]

Hallo,

Was kann ich jetzt tun, um die Probleme weiter einzugrenzen? Welcher Trace wäre evt. sinnvoll?

ich hatte hier eigentlich eine Antwort erwartet...

Ich habe jetzt, nachdem ich mit dem 'show job' auf VPN geschlossen hatte, mal einen VPN-Status-Trace gemacht.

In der halben Stunde, wo das Gerät auf 100 % CPU-Last hängt, kommt ständig die Ausschrift:

Code: Alles auswählen

[VPN-Status] 2017/12/03 04:02:21,179  Devicetime: 2017/12/03 04:02:20,460
IKE info: Delete Notification for Phase-2 SA spi [0x67155885] could not be sent: no phase-1 sa exists to peer 80.147.108.100

Was bedeutet das? Sind die Trace-Ausgaben vor dieser Meldung relevant?

Code: Alles auswählen

[VPN-Status] 2017/12/03 04:30:34,489  Devicetime: 2017/12/03 04:30:33,736
IKE info: system load [9]. maximal number of concurrent negotiations reached [1]

[VPN-Status] 2017/12/03 04:30:34,489  Devicetime: 2017/12/03 04:30:33,736
IKE info: The remote server 80.147.105.100:500 was rejected due to system overload

Das hört sich ja eindeutig nicht gut an...

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

ich würde im Fehlerfall einen IP-Router Trace anwerfen, immerhin schlägt der IPV4 Job extrem an in Kombination mit VPN Prozessen, d.h. der interne Router muss Pumpen aus welchem Grund auch immer, vielleicht kreisende Pakete? Wenn dann nichts ungewöhnliches zu sehen ist, würde ich versuchen, die LAN Schnittstelle mittels Pa(c)ket Capturing mitzuschneiden und schauen, ob irgendwas aus dm LAN den Router zum Einsturz bringt (schleife etc). Kann leider viele Ursachen haben

Gruß Dr.Einstein

[MariusP]

Hi,
Die zweite Trace Ausschnitt bedeutet lediglich, das Aufgrund der hohen CPU Last auf dem Gerät die Anzahl der aufzubauenden Verbindungen zu abzubremsen um nicht noch mehr Last auf das Gerät zu legen. Ist also unter dem Zustand der unnormalen IPv4-Last ein "normales" Verhalten.

Vielleicht kann Backslash einen Hinweis geben, was auf dem IPv4-Job zu der Last führen kann.

@Jirka kannst du bitte kurz sagen in welchem Abstand die erste Meldung kommt. Eigentlich müsste er nach einer kurzen Zeit erkennen, das der ohne Phase 1 die Meldung nicht mehr rausbekommen wird.
Gruß

[Jirka]

Hallo Dr. Einstein,

vielen Dank für Deine Hinweise. Zum LAN: Ich vermute hier keine Probleme aus dem LAN, sondern Probleme beim Aufbau der VPNs nach Verbindungstrennung. Denn nur dann tritt das Problem auf.

Hallo Marius,

Die zweite Trace Ausschnitt bedeutet lediglich, das Aufgrund der hohen CPU Last auf dem Gerät die Anzahl der aufzubauenden Verbindungen zu abzubremsen um nicht noch mehr Last auf das Gerät zu legen. Ist also unter dem Zustand der unnormalen IPv4-Last ein "normales" Verhalten.

ja, so habe ich das auch interpretiert.

Kannst du bitte kurz sagen in welchem Abstand die erste Meldung kommt. Eigentlich müsste er nach einer kurzen Zeit erkennen, das der ohne Phase 1 die Meldung nicht mehr rausbekommen wird.

Genau alle 6 Sekunden. Eine halbe Stunde lang.

Vielen Dank und viele Grüße,
Jirka

[MariusP]

Hi,
kleines Update: Die Meldung passiert, wenn ein ESP Packet ankommt zudem es keine SA gibt.
Also versucht das IKE der Gegenseite mitzuteilen, dass es doch bitte seine Phase 2 abzubauen habe.
Wenn die Delete Notification dann abgeschickt werden soll gibt es natürlich keine Phase 1 über die es die Notification abschicken kann.
Das probiert LCOS alles 5 Sekunden.

Warum also schickt die Gegenseite weiter ESP-Pakete?
Gruß

[Jirka]

Hallo Marius,

kleines Update: Die Meldung passiert, wenn ein ESP Packet ankommt zudem es keine SA gibt.

aha.
Die VPN-Verbindung zur Gegenseite steht aber längst wieder. Und da gehen auch Daten rüber.

Also versucht das IKE der Gegenseite mitzuteilen, dass es doch bitte seine Phase 2 abzubauen habe.
Wenn die Delete Notification dann abgeschickt werden soll gibt es natürlich keine Phase 1 über die es die Notification abschicken kann.
Das probiert LCOS alles 5 Sekunden.

Vermutlich mit einer Sekunde Timeout, womit wir dann bei 6 Sekunden wären.
Ok.
Aber das kann ja dann noch kein Grund für 100 % CPU-Last sein, oder?

Warum also schickt die Gegenseite weiter ESP-Pakete?

Gute Frage. Die Gegenseite ist (wie die anderen Gegenseiten auch) ein LANCOM-Router.
Ich habe da den Verdacht, dass der LANCOM durcheinanderkommt. Daher kurz zur Konfig:

lokal: Entferntes Gateway: feste IP-Adresse der Gegenseite, kein dyn. VPN, Main Mode, Haltezeit 0

Gegenseite: Entferntes Gateway: feste IP-Adresse der 1. WAN-Verb. der Gegenseite (also des Geräts mit 100 % CPU-Last), kein dyn. VPN, Main Mode, Haltezeit 9.999 - und jetzt kommt es - unter "Weitere entfernte Gateways": Anfangen mit: Erstem, Gateway 2: feste IP-Adresse der 2. WAN-Verb. der Gegenseite (also des Geräts mit 100 % CPU-Last)

Es scheint also die Gegenseite an beide WAN-Verbindungen Pakete zu schicken und damit die Zentrale so durcheinander zu bringen, dass 100 % CPU-Last entstehen? Meiner Meinung nach sind hier zwei Probleme: das ursächlich auslösende Problem und das Problem, dass die Zentrale mit einem (bzw. mehreren) herrenlosen ESP-Packet(en) nicht richtig umgeht und damit voll beschäftigt ist (100 % CPU-Last).

Viele Grüße,
Jirka

[Dr.Einstein]

Ich glaub eher, du kannst die ESP Meldung / P1 Meldung ignorieren. Die ganzen VPN Statustracemeldungen haben meiner Erfahrung nach bei 100% eh keine Aussagekraft, da der Router so mit sich beschäftigt ist, dass alle möglichen Berechnung für neue VPN Verbindungen fehlschlagen / zu spät fertig sind / was auch immer.

Ich bleibe dabei, dass irgendwas aus dem LAN/WAN den Router stört. Wenn die Zwangstrennung ist, dann fliegen auch alle UDP/TCP Verbindungen runter. Die Anwendungen machen einen neuen Verbindungsaufbau und da wird etwa dabei sein, was schädlich ist.

Wäre es ein VPN LCOS Thema, probiere mal die 9.24Rel, 9.24RU6 und 9.24SU9 aus. In jedem dieser genannten Release habe ich dein beschriebenes Szenario (2.x WAN, entferntes GW, zufälliges /der Reihe) ohne Probleme am Laufen gehabt.

Gruß Dr.Einstein

[MariusP]

Hi,
Du kannst das ganze ja mit den SPIs überprüfen zu welcher Verbindung welches Paket gehören soll.

Baut die Gegenseite, denn in dem Fall auf dem zweiten Entfernten Gateway eine Verbindung überhaupt auf? Und was ist dann die SPI davon?

Die "herrenlosen" ESP-Pakete sollten aber nicht eine solche CPU-Last erfordern.

Aber den IPv4 Job mir näher anzuschauen wird wohl diese Woche nichts.
Ist auch nicht mein Bereich. *Hust* Backslash *Hust*.
Gruß

[GrandDixence]

Code: Alles auswählen

[VPN-Status] 2017/12/03 04:02:21,179  Devicetime: 2017/12/03 04:02:20,460
IKE info: Delete Notification for Phase-2 SA spi [0x67155885] could not be sent: no phase-1 sa exists to peer 80.147.108.100

Für den ESP-Datenkanal (Phase-2, CHILD_SA) des VPN-Tunnels zum VPN-Endpunkt 80.147.108.100 möchte das LANCOM-Gerät ein IKE-Telegramm mit dem Inhalt "Delete" (VPN-Tunnel trennen/löschen) senden. Jedoch fehlt dem LANCOM-Gerät der IKE-Steuerkanal (Phase-1) des VPN-Tunnels zum VPN-Endpunkt 80.147.108.100. Fazit: Aus Sicht des LANCOM-Geräts können noch Daten (zum Beispiel IP-Pakete) durch den Datenkanal (ESP) des VPN-Tunnel zum VPN-Endpunkt 80.147.108.100 übertragen werden, jedoch fehlt der Steuerkanal (IKE) zur Steuerung und Überwachung und (Neu-)verhandlung des Schlüsselmaterials ((Re-)negotiation/Rekeying) des VPN-Tunnels. Dieses Fehlverhalten sollte sehr gut in:

Code: Alles auswählen

/Status/VPN/IKE
/Status/VPN/ESP
/Status/VPN/Verbindungen

ersichtlich sein. Auch die entsprechenden VPN-Traces werden meine Aussagen bestätigen:

Code: Alles auswählen

trace + vpn
trace + vpn-debug

Beim Aufbau des VPN-Tunnels wird zuerst das Schlüsselmaterial für die Verschlüsselung des Steuerkanals (IKE) ausgehandelt und berechnet (Phase 1, IKE-SA). Sobald die VPN-Endpunkte authentifiziert wurden (der andere VPN-Endpunkt muss sich ausweisen, ob er wirklich der korrekte Kommunikationspartner ist), wird das Schlüsselmaterial für die Verschlüsselung des Datenkanals (ESP) ausgehandelt und berechnet (Phase 2, Child-SA, IPSEC-SA). Danach wird der Datenkanal aufgebaut und die Daten können durch den VPN-Tunnel fliessen.

Das Schlüsselmaterials des Steuerkanal (IKE) UND des Datenkanals (ESP) haben eine beschränkte Gültigkeit (max. Datenmenge oder max. Zeitdauer, es gilt die zuerst erreichte Grenze). Die Gültigkeit des IKE-Steuerkanals und des ESP-Datenkanals ist unter /Setup/VPN konfigurierbar. Bitte die Unterschiede in der Gültigkeits-Aushandlung zwischen IKEv1 und IKEv2 beachten:

https://wiki.strongswan.org/projects/st ... xpiryRekey

und die Empfehlungen der Gültigkeitsdauer in BSI TR-02102-3, Kapitel 3.4 befolgen:

https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Die Gültigkeitkeitsdauer des Schlüsselmaterial des Datenkanals (ESP) ist vollständig unabhängig von der Gültigkeitsdauer des Schlüsselmaterials des Steuerkanals (IKE). Jedoch kann das neue Schlüsselmaterial für den Datenkanal (ESP) nur über den Steuerkanal (IKE) ausgehandelt werden. Ist das Schlüsselmaterial des Steuerkanal (IKE) nahe am Ablaufdatum (Spalte: "Alter" > "Soft-Sek" in /Status/VPN/IKE), wird neues Schlüsselmaterial für den Steuerkanal (IKE) berechnet und ausgehandelt.

Ist das Schlüsselmaterial des Datenkanal (ESP) nahe am Ablaufdatum (Spalte: "Alter" > "Soft-Sek" in /Status/VPN/ESP), wird neues Schlüsselmaterial für den Datenkanal berechnet und ausgehandelt. Ist zu diesem Zeitpunkt der Steuerkanal (IKE) bereits über dem Verfallsdatum (Spalte: "Alter" > "Max-Sek" in /Status/VPN/IKE), kann kein neues Schlüsselmaterial für den Datenkanal (ESP) berechnet und ausgehandelt werden, da der Steuerkanal (IKE) entweder als "ungültig" erachtet wird oder der Steuerkanal (IKE) aus Sicherheitsgründen (zwangs-)getrennt wurde.

Code: Alles auswählen

[VPN-Status] 2017/12/03 04:30:34,489  Devicetime: 2017/12/03 04:30:33,736
IKE info: system load [9]. maximal number of concurrent negotiations reached [1]

Um 04:30 Uhr wurde die rechenintensive Berechnungen und Aushandlungen (negotiations) des Schlüsselmaterials für den Steuerkanal (IKE) UND/ODER den Datenkanal (ESP) für zahlreiche VPN-Tunnels durchgeführt. Wie diese rechenintensive Berechnungen und Aushandlungen des Schlüsselmaterials (ohne Sicherheitsverluste) optimiert werden können, wurde ausführlich unter:

http://www.lancom-forum.de/fragen-zum-t ... 16174.html

http://www.lancom-forum.de/aktuelle-lan ... 15398.html

besprochen.

Sehr vereinfacht ausgedrückt:

- Verschlüsselung mit asymmetrischen Verfahren (Public-Key-Verfahren; zum Beispiel: Diffie-Hellman DH/EDH) sind sehr langsam (und rechenintensiv). Deshalb wird nach Möglichkeit sofort auf ein schnelles symmetrisches Verfahren (zum Beispiel AES) für die Verschlüsselung des Steuer- und Datenkanals (IKE/ESP) gewechselt.

- Beim VPN-Tunnelaufbau und bei der Neuverhandung des Schlüsselmaterials (Renegotiaon/Rekeying) wird der Schlüssel für die symmetrische AES-Verschlüsselung mit einer asymmetrischen Verschlüsselung (Diffie-Hellman) zwischen den beiden VPN-Endpunkte übertragen.

Das symmetrische und asymmetrische Verschlüsselungsverfahren werden auf verständliche Weise auf den folgenden Webseiten erklärt:

https://wiki.kairaven.de/open/krypto/gpg/gpg2

Diffie-Hellman-Schlüsselaustausch: https://www.jackpair.com/default/img/Wh ... Secure.gif

Code: Alles auswählen

[VPN-Status] 2017/12/03 04:30:34,489  Devicetime: 2017/12/03 04:30:33,736
IKE info: The remote server 80.147.105.100:500 was rejected due to system overload

Weshalb auf einen Schlag das Schlüsselmaterial von so vielen VPN-Tunnels neu berechnet und ausgehandelt werden muss, sollte untersucht werden.

https://www.heise.de/security/artikel/V ... 70796.html

https://www.heise.de/security/artikel/E ... 70056.html

[GrandDixence]

Warum also schickt die Gegenseite weiter ESP-Pakete?

Weil die Gegenseite (der andere VPN-Endpunkt) wegen fehlerhaften oder falsch konfigurieren "Dead Peer Detection" (DPD) nicht merkt, dass der VPN-Tunnel "tot" ist. Man beachte die Spalte "Alter" des in Zeile 3 und 4 abgebildeten, schon tagelang getrennten VPN-Tunnels. Der VPN-Tunnel wurde durch eine "Zwangstrennung" (Wechsel der IP-Adresse des EuroDOCSIS-Kabelmodems für den Internetzugang) getrennt.

Screenshot_IKEv2_ESP.png

Das abgebildete Fehlverhalten wird verursacht durch LCOS-Softwarefehlern in der DPD-Funktion von IKEv2 (und sehr wahrscheinlich auch in IKEv1):
http://www.lancom-forum.de/fragen-zum-t ... 16420.html

Ich bin der Meinung, dass LANCOM in LCOS die Dead Peer Detection nicht konform zur RFC 3706 realisiert hat:

Code: Alles auswählen

<< A peer MUST keep track of the state of a given DPD exchange. That
is, once it has sent an R-U-THERE query, it expects an ACK in
response within some implementation-defined period of time. An
implementation SHOULD retransmit R-U-THERE queries when it fails to
receive an ACK. 

After some number of retransmitted messages, an
implementation SHOULD assume its peer to be unreachable and delete
IPSec and IKE SAs to the peer. >>

https://tools.ietf.org/html/rfc3706

Anmerkung: Aus Sicherheitsgründen sollte IKEv1 durch IKEv2 ersetzt werden:
http://www.lancom-forum.de/fragen-zum-t ... tml#p91068

[Jirka]

Hallo Dr. Einstein,

Ich glaub eher, du kannst die ESP Meldung / P1 Meldung ignorieren.

zumindest ist sie nicht ursächlich für die CPU-Last.

Ich bleibe dabei, dass irgendwas aus dem LAN/WAN den Router stört.

Ich schließe mich Deiner Meinung jetzt an - das hat mich überzeugt. Da ist irgendwas aus dem LAN (WAN schließe ich aus, weil kein nennenswerter Traffic), was nach der Verbindungstrennung dem LANCOM-Router Schwierigkeiten bereitet und zu einem hohen ein- und ausgehenden Traffic auf einem logischen LAN- und damit einem physikalischen Ethernet-Port führt.

Mal sehen, was ich so rausbekomme, ich melde mich in einer Woche.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo zusammen,

so, ich weiß nicht mehr weiter und habe keinen weiteren Ansatz mehr. Ich habe in der (vorletzten) Nacht einen Trace mitlaufen lassen (Komplett-Trace über WEBconfig -> Extras -> Packet-Capturing -> Schnittstellen-Auswahl: LAN-1), um 2:23 Uhr Uhr angestellt, bis 4:23 Uhr mitlaufen lassen. Ab 4:02 Uhr mit 100 % CPU-Last. Dann habe ich mir den Trace von vorne bis hinten (manuell) angeschaut, jede irgendwie brauchbare Statistik durchgeschaut, mir den Graph angeschaut usw. und unterm Strich nichts gefunden, was irgendwie auffällig sein könnte. Kein höherer Traffic, kein ungewöhnliches Verhalten, es ist wie gesagt nichts zu sehen und auch auf WAN-Seite ist der Traffic so gering, dass das niemals die Ursache für 100 % CPU-Last sein kann. Der Router muss sich also an irgendwas verhakeln und dann drehen sich die Pakete innerhalb des Routers, landen aber nicht auf WAN- oder LAN-Seite. Heute Nacht traten die 100 % CPU-Last übrigens von 4:32 Uhr an auf, ich hatte vor einiger Zeit mal die der der 24-h-Zwangstrennung zuvorkommende Verbindungstrennung der zweiten WAN-Verbindung von 4:01 Uhr auf 4:30 Uhr gelegt. Irgendwas muss demnach ja in einer der beiden WAN-Verbindungen hängen bleiben, werde noch mal einen IP-Router-Trace machen und die (IP-Router-)Connection-List beobachten, mehr fällt mir echt nicht ein.

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

schade, dass der Ansatz beim 1. Versuch nicht geklappt hat.

Weiterer Vorschlag meinerseits: Du kannst den Fehler ja scheinbar provozieren mittels Trennung der WAN Verbindung / Zwangstrennung. Du hast zwei WAN Verbindungen. Du könntest ja im Fehlerfall einzelne Schnittstellen deaktivieren, (wenn du nicht vor Ort bist) erst über WAN 2 die WAN 1 Verbindung, dann über WAN 1 die WAN 2 Verbindung, LAN ETH-Ports ausschalten. Vielleicht kannst du dadurch mehr eingrenzen?

Gruß Dr.Einstein