Schlagwort-Archive: Cisco

Cisco Mobility Service Engine Version: 8.0.150.0 mit NMSP Problem

Beim Setup eines WLCs mit der TAC Version 8.3.141.5 und einer Cisco Mobility Service Engine (MSE) Version: 8.0.150.0 kam keine NMSP/SSL Tunnel nach dem Update der MSE auf Version 8.0.150.0 mehr zustande. NMSP, das Network Mobility Services Protocol, ist der das Kommunikationsprotokoll zwischen den MSE und den WLCs. Es transportiert Telemetrie, Warnungen sowie RSSI Informationen.

Tricks wie Rückfall auf SHA-1 oder neusetzen der Hashes waren erfolglos. Im Log des WLC war beim Debugging folgendes sichtbar:

(Cisco Controller) >debug nmsp all enable
*nmspRxServerTask: Aug 16 09:13:54.461: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:55.081: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:55.701: [PA] Polling nmsp connection at 0 index 0 (94). Handshake in progress
*nmspRxServerTask: Aug 16 09:13:56.005: [PA] ssl handshake timeouted for connection 0
*nmspRxServerTask: Aug 16 09:13:56.005: [PA]  freeing Nmsp Connection [0]
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] Accept succ for http socket addrtype=IPV4(0xf51410ac)
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] Allocated new NMSP connection 0
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit:  SSL_new() conn ssl 0x7f710c03af98
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit: SSL_do_handshake for conn ssl 0x7f710c03af98, conn state: INIT, SSL state: HANDSHAKING
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] — returns WANT_READ for conn ssl 0x7f710c03af98
*nmspRxServerTask: Aug 16 09:14:14.422: [PA] sslConnectionInit() success with Connection state: INIT, SSL state: HANDSHAKING
*nmspRxServerTask: Aug 16 09:14:15.053: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:15.685: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:16.317: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:16.949: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:17.581: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:18.213: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:18.845: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:19.477: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:20.109: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:20.741: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress
*nmspRxServerTask: Aug 16 09:14:21.373: [PA] Polling nmsp connection at 0 index 0 (92). Handshake in progress

Ursache hierfür ist Cisco Bug CSCvh24960. Die CiscoJ, eine Art Helper für die Kommunikation zwischen MSE und WLC, so der TAC ist ab Version  8.0.150.0 nach ausführen der setup.sh deaktiviert.

Damit der NMSP Tunnel wieder hoch kommt muss CiscoJ händisch auf der MSE aktiviert werden. Dies geht wie folgt:

root@mse1a:~[root@mse1a ~]# configureCiscoJ.sh status
CiscoJ is disabled.
root@ca-bbg1mse1a:~[root@mse1a ~]# configureCiscoJ.sh enable
CiscoJ is enabled.

Weiterführende Informationen unter https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh24960/.

Cisco IOS Router an Telekom Annex J ADSL BNG

Um einen Cisco IOS Router an einem Telekom Annex J ADSL im neuen BNG betreiben zu können ist ähnlich wie beim VDSL auf dem Ethernet auf dem ATM Interface ein entsprechender VLAN Tag nötig.

Die Konfiguration sieht wie folgt aus:

test-router#sh run int atm0/0/0
Building configuration…

Current configuration : 178 bytes
!
interface ATM0/0/0
description — WAN —
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
atm vc-per-vp 64
no atm ilmi-keepalive
end

test-router#sh run int atm0/0/0.7
Building configuration…

Current configuration : 114 bytes
!
interface ATM0/0/0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
End

Die Nutzung des ATM Sub-Interfaces ist zwingend erfoderlich, da der Befehl bridge-dot1q encap 7 im ATM Interface nach dem Reboot verschwindet. Erst im Subinterface ist er Rebootfest.

Getestet auf dem IOS 15.5(3)M6 und der Modemfirmware VA_A_39m_B_38h3_24h_o.bin.

test-router#sh ver | i IOS
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.5(3)M6, RELEASE SOFTWARE (fc2)
test-router#sh controllers vDSL 0/0/0
Controller VDSL 0/0/0 is UP

Daemon Status:           Up
[…]
Modem Status:            TC Sync (Showtime!)

DSL Config Mode:         AUTO
Trained Mode:   G.992.5 (ADSL2+) Annex J
TC Mode:                 ATM
Selftest Result:         0x00
DELT configuration:      disabled
DELT state:              not running

Full inits:             55
Failed full inits:      40
Short inits:            25
Failed short inits:     37

Firmware        Source          File Name
——–        ——          ———-
VDSL            user config     flash:VA_A_39m_B_38h3_24h_o.bin

Modem FW  Version:      150716_0926-4.02L.03.B2pvC038h3.d24h
Modem PHY Version:      B2pvC038h3.d24h
Trellis:                 ON                       ON
SRA:                     disabled                disabled
SRA count:              0                       0
Bit swap:                enabled                 enabled
Bit swap count:         112113                  1345
Line Attenuation:        52.0 dB                 36.0 dB
Signal Attenuation:      54.2 dB                 35.5 dB
Noise Margin:             5.7 dB                  5.9 dB
Attainable Rate:        10416 kbits/s            1951 kbits/s
Actual Power:            19.3 dBm                13.1 dBm
Total FECC:             21095028                         2384697
Total ES:               2877                     1184
Total SES:              1116                     3
Total LOSS:             85                       0
Total UAS:              113338                   113338
Total LPRS:             0                        0
Total LOFS:             442                      0
Total LOLS:             0                        0

DS Channel1     DS Channel0   US Channel1       US Channel0
Speed (kbps):             0             5624             0              2056
SRA Previous Speed:       0                0             0                 0
Previous Speed:           0             3452             0              1980
Total Cells:              0       3431086630             0        2825378336
User Cells:               0         69269238             0          21398987
Reed-Solomon EC:          0         14067201             0              9282
CRC Errors:               0            60804             0              1506
Header Errors:            0             1448             0                 2
Interleave (ms):       0.00             7.61          0.00              6.75
Actual INP:            0.00             6.62          0.00              1.13

Training Log :  Stopped
Training Log Filename : flash:vdsllog.bin

Inbetriebnahme AIR-AP1572EAC-E-K9

Bei der Inbetriebname eines AIR-AP1572EAC-E-K9 war in der Konsole folgende Fehlermeldung zu sehen:

*Jul 11 12:57:16.211: %CAPWAP-5-SENDJOIN: sending Join Request to 1.2.3.4
*Jul 11 12:57:16.211: %DTLS-5-ALERT: Received WARNING : Close notify alert from 1.2.3.4
*Jul 11 12:57:16.211: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 1.2.3.4:5246
*Jul 11 12:57:26.211: AP has SHA2 MIC certificate – Using SHA2 MIC certificate fS.

Im Log des WLC erscheinte das Gerät mit der Meldung

AAA Authentication Failure for UserName:234567890 User Type: WLAN USER

Bei Check der Konsole fiel auf, dass das Gerät im „Bridge“ Modus läuft:

AP234567890#show capwap client config | i Mode
Mode                  Bridge

Mit dem Befehl capwap ap mode local konnte der Modus via CLI umgehoben werden. Danach bootete der Accesspoint einmal durch und jointe wie gewohnt zum WLC.

Getestet mit c1570-k9w8-mx.153-3.JBB6.

PPPoE Connection schlägt mit C886VAJ-K9 und IOS 15.4(3)M2 fehl

Beim heutigen testen eines neuen C886VAJ-K9 mit IOS 15.4(3)M2 stieß ich auf ein Problem bei der Zuweisung der öffentlichen IP Adresse während der ADSL/VDSL Einwahl. Im Log war ersichtlich, dass der Dialer up war und ca. 30 Sekunden später wieder abfiehl.

000213: *Mar 15 09:24:52: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
000217: *Mar 15 09:24:52: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
000213: *Mar 15 09:24:52: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
000219: *Mar 15 09:24:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up000223: *Mar 15 09:25:23: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
000225: *Mar 15 09:25:23: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
000226: *Mar 15 09:25:23: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down

Die IP Interface Brief-Summary zeigte, dass zwar Status und Protocol up waren, aber die IP-Adresse war noch unassigned:

router1#sh ip int brief | i Di
Dialer1                    unassigned   YES IPCP   up                    up

Um CRC oder Header Fehler auf dem VDSL auszuschließen kontrollierte ich die entsprechenden Counter:

router1#sh controllers vdsL 0 | i Err
CRC Errors:               0                0             0                 0
Header Errors:            0                0             0                 0

Bisherige Tests im Labor mit einem C1921-SEC-K9 und dem IOS 15.2(4)M7 verliefen ohne Probleme. Insofern entschied ich mich den Router zuerst auf 15.3(3)M5 zuheben. Auch hier die Einwahl ohne Probleme. Das Upgrade auf 15.4(3)M1 auf dem C1921-SEC-K9 klappte auch, allerdings zeigte dieser dann die identischen Probleme bei der Zuweisung der öffentlichen IP am Dialer-Interface.

Das auf dem C1921-SEC-K9 mit IOS 15.4(3)M1 durchgeführte Debugging der PPP-Negotiation zeigte die Ursache:

[…]
000158: *Mar 15 10:23:42: Vi2 CHAP: I SUCCESS id 1 len 42 msg is „CHAP authentication success, unit 8114“
000159: *Mar 15 10:23:42: Vi2 PPP: Phase is FORWARDING, Attempting Forward
000160: *Mar 15 10:23:42: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
000161: *Mar 15 10:23:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
000162: *Mar 15 10:23:42: Vi2 PPP: No AAA accounting method list
000163: *Mar 15 10:23:42: Vi2 PPP: Phase is UP
000164: *Mar 15 10:23:42: Vi2 IPCP: Protocol configured, start CP. state[Initial]
000165: *Mar 15 10:23:42: Vi2 IPCP: Event[OPEN] State[Initial to Starting]
000166: *Mar 15 10:23:42: Vi2 IPCP: O CONFREQ [Starting] id 1 len 10
000167: *Mar 15 10:23:42: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
000168: *Mar 15 10:23:42: Vi2 IPCP: Event[UP] State[Starting to REQsent]
000169: *Mar 15 10:23:42: Vi2 PPP: Control packet rate limit 10 reached
000170: *Mar 15 10:23:42: Vi2 PPP: Entering block state for 30 seconds
000171: *Mar 15 10:23:42: Vi2 PPP: Packet throttled, Dropping packet
000172: *Mar 15 10:23:42: Vi2 PPP: Packet throttled, Dropping packet
000173: *Mar 15 10:23:45: Vi2 PPP: Packet throttled, Dropping packet

Es verdichtete sich die Vermutung, dass sich die Default-Parameter zw. IOS 15.2(4)M7 und IOS 15.4(3)M2 auf dem C1921-SEC-K9  geändert haben, wodurch sich ggf. auch das Problem auf dem C886VAJ-K9 erklären könnte. Dieser zeigte im PPP-Debugugging die gleichen Throtteling-Meldungen.

Insofern verglich ich mit dem Befehl show running-config all | i ppp zw. den beiden IOS 15.2(4)M7 und IOS 15.4(3)M1 und es fiel der neue PPP Default-Parameter ppp packet throttle 10 1 30 auf. In der Tat zeigte sich das Blocking auch mit dem Kommando:

router1#sh ppp throttled
Ingress Port         Uniq ID          Remaining Block Time
———————————————————-
Virtual-Access2         5                  27 Seconds

Da ich weder in den Release-Notes noch in den Whitepapers zu den jeweilgen IOS Versionen fündig wurde, versuchte ich mit  ppp packet throttle 20 1 30 einen Schuss ins Blaue um so die neuen Default-Werte etwas zu enthärten – erfolgreich. Letztendlich erlaubte ich pro Sekunde 10 weitere Control-Pakete was die Policy etwas abschwächte und nun die Zuweisung der IP Adresse via IPCP auf dem Dialer-Interface gelang:

[…]
000141: *Mar 15 10:51:50: Vi2 CHAP: I SUCCESS id 1 len 43 msg is „CHAP authentication success, unit 13163“
000142: *Mar 15 10:51:50: Vi2 PPP: Phase is FORWARDING, Attempting Forward
000143: *Mar 15 10:51:50: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
000144: *Mar 15 10:51:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
000145: *Mar 15 10:51:50: Vi2 PPP: No AAA accounting method list
000146: *Mar 15 10:51:50: Vi2 PPP: Phase is UP
000147: *Mar 15 10:51:50: Vi2 IPCP: Protocol configured, start CP. state[Initial]
000148: *Mar 15 10:51:50: Vi2 IPCP: Event[OPEN] State[Initial to Starting]
000149: *Mar 15 10:51:50: Vi2 IPCP: O CONFREQ [Starting] id 1 len 10
000150: *Mar 15 10:51:50: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
000151: *Mar 15 10:51:50: Vi2 IPCP: Event[UP] State[Starting to REQsent]
000152: *Mar 15 10:51:50: Vi2 IPCP: I CONFREQ [REQsent] id 162 len 10
000153: *Mar 15 10:51:50: Vi2 IPCP:    Address a.a.a.a (0x030657BAE067)
000154: *Mar 15 10:51:50: Vi2 IPCP: O CONFACK [REQsent] id 162 len 10
000155: *Mar 15 10:51:50: Vi2 IPCP:    Address a.a.a.a  (0x030657BAE067)
000156: *Mar 15 10:51:50: Vi2 IPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
000157: *Mar 15 10:51:50: Vi2 IPCP: I CONFNAK [ACKsent] id 1 len 10
000158: *Mar 15 10:51:50: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000159: *Mar 15 10:51:50: Vi2 IPCP: O CONFREQ [ACKsent] id 2 len 10
000160: *Mar 15 10:51:50: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000161: *Mar 15 10:51:50: Vi2 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
000162: *Mar 15 10:51:51: Vi2 IPCP: I CONFACK [ACKsent] id 2 len 10
000163: *Mar 15 10:51:51: Vi2 IPCP:    Address b.b.b.b (0x03065DC67EC5)
000164: *Mar 15 10:51:51: Vi2 IPCP: Event[Receive ConfAck] State[ACKsent to Open]
000165: *Mar 15 10:51:51: Vi2 IPCP: State is Open
000166: *Mar 15 10:51:51: Di1 IPCP: Install negotiated IP interface address b.b.b.b

Die IP Interface Brief-Summary nun auch die erfolgreiche Zuweisung der öffentlichen IP adresse:

asl1#sh ip int brief | i Di
Dialer1                    a.a.a.aYES IPCP   up                    up

 

 

Troubleshooting Cisco Aironet Client Disconnectes

Gestern hatte ich Gelegenheit ein WLAN-Problem zu entstören, bei dem ca. 50% der angebundenen Clients sofort nach der erfolgreichen Assoziierung sich wieder getrennt haben.

Auf dem Access Point wurde z. B. folgendes gelogged (man achte auf dem Timecode!):

Jan 28 13:30:57.230: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   aaaa.bbbb.cccc Associated KEY_MGMT[WPAv2 PSK]
Jan 28 13:30:57.294: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station aaaa.bbbb.cccc Reason: Sending station has left the BSS
Jan 28 13:30:57.294: Dot11Radio0: Going to delete client aaaa.bbbb.cccc Reason: request

Um sich dem Thema zu nähern habe ich erstmal geprüft, ob ggf. ein Störer existiert:

AP# debug dot11 dot11Radio 0 carrier busy
Jan 28 12:53:28.577: **disc_send_reset_event, event=1
Jan 28 12:53:28.581: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
Jan 28 12:53:28.589: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
Jan 28 12:53:29.581: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Jan 28 12:53:29.585: DOT11 EVENT:disc_config: root set device to 9E
Frequency  Carrier Busy %
———  ————–
2412         18
2417         18
2422          4
2427          7
2432         16
2437          7
2442          9
2447          7
2452         13
2457          7
2462         58
2467         11
2472         43
dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:53:44.673: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:53:49.461: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
Jan 28 12:53:50.461: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Zu beachten ist hier, dass das Radio-Interface für den Zeitraum in einen Reset-Status geht. Auch der aktuell ausgewählte Kanal kann abgerufen werden:

AP# show controllers do 0
!
interface Dot11Radio0
Radio Ibiza 2.4, Base Address cccc.dddd.ffff, BBlock version 0.00, Software version 4.18.1
Serial number: FOCxxxxxxxx
Unused dynamic SQRAM memory: 0x0000C8F0 (50 KB)
Unused dynamic SDRAM memory: 0x00089264 (548 KB)
Spectrum FW version: 1.15.0
Number of supported simultaneous BSSID on Dot11Radio0: 16
Carrier Set: EMEA (EU) (-E)
Uniform Spreading Required: No
Configured Frequency: 2447 MHz  Channel 8 

Notfalls, kann man bei Bedarf den automatisch gewählten Kanal auch nochmals automatisch suchen lassen oder den Access-Point in einen Kanal zwingen:

AP(config)# interface Do0
AP(config-if)# channel least-congested
Jan 28 12:51:14.680: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
Jan 28 12:51:14.688: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
Jan 28 12:51:15.680: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Jan 28 12:51:15.684: DOT11 EVENT:disc_config: root set device to 9E
Jan 28 12:51:15.688: %DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 13 seconds
Jan 28 12:51:28.955: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:51:33.147: %DOT11-6-FREQ_USED: Interface Dot11Radio0, frequency 2447 selected
Jan 28 12:51:33.147: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:51:38.039: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
Jan 28 12:51:39.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Nun zurück zum Problem, dem sofortigen Trennen der Verbindung. Das Standardlog impliziert, dass der PC die Trennung forciert hat. Mit ein paar Debug-Befehlen kann man dies untermauern:

AP#deb dot11 mgmt interface
AP#deb dot11 mgmt msg
AP#deb dot11 mgmt ssid
AP#deb dot11 mgmt state-machine
AP#deb dot11 mgmt station
Jan 28 13:30:57.214: Dot11Radio0: Tx AssocResp client aaaa.bbbb.cccc
Jan 28 13:30:57.214: dot11_mgmt: dot11_mgmt_sta_deref (ref=3, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.230: dot11_mgmt: recv AAA Auth resp for aaaa.bbbb.cccc, vlan name , id 10 and wnid 0
Jan 28 13:30:57.230: dot11_mgmt: same VLAN return from AAA
Jan 28 13:30:57.230: dot11_mgmt: dot11_mgmt_sta_ref (ref=2, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.230: SM: —Open Authentication 0x734648C: AAA Auth OK (5)
Jan 28 13:30:57.230: SM:    AAA_Auth (6) –> Assoc (2)
Jan 28 13:30:57.230: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   aaaa.bbbb.cccc Associated KEY_MGMT[WPAv2 PSK]
Jan 28 13:30:57.230: dot11_mgmt:aaaa.bbbb.cccc bss client assoc/reassoc updated stats curr_assoc 2 cur_bss_assoc 2 cur_rptrs 0 cur_bss_rptrs 0lwapp_session_timeout not starting for aaaa.bbbb.cccc
Jan 28 13:30:57.230: dot11_mgmt: dot11_mgmt_sta_deref (ref=3, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.294: Dot11Radio0: Rx DisAssoc client aaaa.bbbb.cccc
Jan 28 13:30:57.294: dot11_mgmt:receive disassoc from aaaa.bbbb.cccc
Jan 28 13:30:57.294: Dot11Radio0: Tx Deauth client aaaa.bbbb.cccc
Jan 28 13:30:57.294:  dot11_mgmt: de-auth msg sent with reason = 2

Hier ist klar erkennbar, dass nach der erfolgreichen Assoziation zum WLAN sofort ein DisAssoc vom Client zum Access Point gesendet wird. Ab diesem Punkt habe ich dann gemeinsam mit dem x86-Plattformkollegen den Client „zerlegt“. Letztendlich konnte es auf ein fehlerhaftes verhalten des Virenscanners zurückgeführt werden bei dem eine Policy die Nutzung des WLANs versehentlicherweise geblockt hat.

Cisco NAT / PAT und ACL mit LOG

Möchte man, dass mehrere Nutzer eines internen Subnetzes z.B. das Internet über eine öffentliche IP nutzen möchten so kommt bekannterweise NAT/PAT zum Einsatz.

Beim folgenden Beispiel ist der Dialer1 das „überladene“ Interface Richtung Internet welches geshared werden soll.

ip nat inside source list 101 interface Dialer1 overload
access-list 101 permit ip 10.11.12.0 0.0.0.255 any

Möchte man sich die Treffer der Access-List ins Log schreiben lassen ergänzt man das access-list statement bekanntermaßen um ein „log“

access-list 101 permit ip 10.11.12.0 0.0.0.255 any log

Nicht so beim NAT. Nutzt man access-listen für das NATting so ist hier der Zusatz „log“ nicht supported. Das NATting wird mit dem Zusatz „log“ nicht funktionieren.

Das Thema ist auch offiziell seitens Cisco dokumentiert in Dokument 26704 vom 26.04.2013 auf cisco.com.

 

 

Cisco CLI mit Befehls-Alias

Wer häufig bestimmte komplexere Befehle auf Cisco Routern nutzt dem werden Aliase sehr gefallen.

Wer Linux kennt wird ab und zu auch mal den Befehl „top“ verwenden welcher die Top CPU Prozesse auflistet. Auf Cisco Routern und Switchen kann man sich mit dem befehl

router1#show processes cpu

Die CPU Prozesse incl. deren Last ausgeben lassen. Aufgelistet werden hier jedoch alle unabhängig ob sie Last verursachen oder nicht. So könnte man mit
einem gepipeden Exclude von „0.00% 0.00% 0.00%“ sich die ausgabe etwas zurecht filtern.

router1#show processes cpu | e 0.00% 0.00% 0.00%
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 1%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
5 3953752 496538 7962 0.00% 0.11% 0.11% 0 Check heaps
12 3719304 48936 76003 0.00% 0.07% 0.10% 0 Licensing Auto U
13 2449332 2936043 834 0.00% 0.06% 0.05% 0 Environmental mo

Auf Dauer geht es einfacher gehts mit dem Befehls-Alias:

router1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router1(config)#alias exec top show processes cpu | e 0.00% 0.00% 0.00%
router1(config)#exit
router1#top
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 1%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
2 352 587977 0 0.00% 0.01% 0.00% 0 Load Meter
5 3953912 496558 7962 0.00% 0.13% 0.11% 0 Check heaps
12 3719380 48937 76003 0.00% 0.07% 0.10% 0 Licensing Auto U
13 2449408 2936157 834 0.00% 0.07% 0.05% 0 Environmental mo
58 836 1138 734 0.23% 0.11% 0.03% 132 SSH Process
84 1268 587995 2 0.00% 0.01% 0.00% 0 Compute load avg

Kabelfehler via Zeitbereichsreflektometrie erkennen

Hallo zusammen,

ein sehr interessantes Feature auf vielen Catalyst Switchen von Cisco ist der Bereich „cable-diagnostics“.

Über Zeitbereichsreflektometrie (Time Domain Reflectometry, kurz TDR) können mittels Impulse Längen und Fehler am Kabel erkannt werden.

Nun kurz Anbei kurz skizziert, wie das Verfahren beispielsweise auf einem WS-C2960-48TC-L angewendet wird.

hydra#sh int description | include host
Fa0/5                          up             up       host#pub1
hydra#test cable-diagnostics tdr int fa 0/3
hydra#show cable-diagnostics tdr int fa 0/1
TDR test last run on: March 21 05:05:22

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Fa0/1     100M  Pair A     8    +/- 15 meters Pair A      Normal
Pair B     8    +/- 15 meters Pair B      Normal
Pair C     N/A                Pair C      Not Supported
Pair D     N/A                Pair D      Not Supported

Der 2960er, auf dem ich getestet habe supportet TDR auch auf den Fa’s, testet dort natürlich nur die A und B Pärrchen.

Hier noch ein Beispiel von einem Gi, wo aktuell kein Kabel aufgesteckt ist:

hydra#test cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface
Use ’show cable-diagnostics tdr‘ to read the TDR results.
hydra#show cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test last run on: March 21 05:31:34

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi0/1     auto  Pair A     0    +/- 2  meters N/A         Open
Pair B     0    +/- 2  meters N/A         Open
Pair C     0    +/- 2  meters N/A         Open
Pair D     0    +/- 2  meters N/A         Open

Was bedeutet nun Open, Normal und Not Supported?

  • Normal – alles ok (bei Fa nur A/B bei Gi A/B/C/D)
  • Open – mindestens ein Pin hat keinen Kontakt
  • Short – Kurzschuss
  • Impenance Mismatched – Schlechtes Kabel, „das Signal schafft es nicht“

Abschließend ein prima weiterführender Link aus dem Cisco Forum.

Fortsetzung folgt… es gibt auch eine Möglichkeit über Intel PROSet seitens Client/Server. Hierzu später mehr.

Access-Listen und DHCPOFFER

Vorgestern hatte ich ein interessantes Thema, bei dem ein Access-Point mit einer input-address-list und output-address-list auf dem Dot11Radio-Interface bei dem ein Windows Server mit DHCP-Rolle keine IP Adressen an Clients im WLAN verteilt hat.

Der Grund war, dass auf dem Dot11Radio-Interface die identische Access-Liste gebunden, welche keine Broadcasts durchließ. Warum? Der Grund liegt hinter der Idee von den entsprechenden ACL’s. Diese stellen nicht die Richtung dar sondern ob source (input) oder destination (output) Address.

Die Lösung letztendlich war denkbar übersichtlich, zwei verschiedene Access-Listen zu erstellen.

interface Dot11Radio0
! […]
bridge-group 1 input-address-list 700
bridge-group 1 output-address-list 701
! […]
access-list 700 permit 6067.20aa.1234 0000.0000.0000
access-list 700 deny 0000.0000.0000 ffff.ffff.ffff
access-list 701 permit 6067.20aa.1234 0000.0000.0000
access-list 701 permit 0000.0000.0000 0000.0000.0000
access-list 701 permit ffff.ffff.ffff 0000.0000.0000
access-list 701 deny 0000.0000.0000 ffff.ffff.ffff

Übrigens in einer Laborumgebung habe ich das nochmal mit einem Cisco Router als DHCP-Server getestet. Hier hat es auch ohne Broadcastadresse in der zweiten ACL Funktioniert.

Der Grund liegt in der Verteilung des DHCPOFFERS vom DHCP-Server. Windows Server nutzen hier abhängig vom Broadcast Bit im DHCPDISCOBVER Broadcast zur Verteilung, siehe KB169289 (http://support.microsoft.com/kb/169289/en-us).

Da obiges Beispiel im Layer 2 spielt ist die Broadcast- oder Unicast-Implementierung abhängig vom Hersteller.

Weiterführende Infos: http://www.ietf.org/rfc/rfc2131.txt

IPSec VPN mit dynamischen IPs

Es ist nicht das Gelbe vom Ei aber auch mit zwei ADSL Anschlüssen und dynamischen IPs kann man ein nutzbares und verfügbares IPSec VPN aufbauen.

Ich habe es mit einer Mischung aus DynDNS, crypto dynamic-map und event manager applet’s gelöst.

Bei zwei Standorten sieht das wie folgt aus. Beide Router nutzen DynDNS. Der Router am ersten Standort bekommt eine ganz normale crypto map und einen Eintrag im event manager. Über einen Cronjob möchte ich die Tunnel nach einer eventuellen Trennung wieder vom Standort 1 aus zum Leben erwecken. Die folgende Konfig zeigt nur die relevanten Ausschnitte:

! Router 1
ip ddns update method dyndns
HTTP
add http://username:kennwort@<s>/nic/update?system=dyndns&hostname=&myip=<a>
interval maximum 0 1 0 0
!
! […]
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key !geheimgeheimgeheim! address 0.0.0.0 0.0.0.0 no-xauth
crypto isakmp identity hostname
crypto isakmp keepalive 20
!
!
crypto ipsec transform-set TRANSSECUR esp-3des esp-sha-hmac
!
crypto map Foo 20 ipsec-isakmp
set peer standort2.dyndns.org dynamic
set security-association lifetime seconds 28800
set transform-set TRANSSECUR
set pfs group2
match address 130
! […]
interface Dialer1
! […]
ip ddns update hostname standort1.dyndns.org
ip ddns update dyndns host members.dyndns.org
crypto map Foo
![…]
!
access-list 130 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
! […]
event manager applet pingpeers
event timer cron name „pingpeers-schedule“ cron-entry „*/1 * * * *“
action 01.0 cli command „ping 192.168.1.1 source vlan 1“
![…]

Der zweite Standort bekommt die Dynamic Map.

! Router 2
ip ddns update method dyndns
HTTP
add http://username:kennwort@<s>/nic/update?system=dyndns&hostname=&myip=<a>
interval maximum 0 1 0 0
!
! […]
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key !geheimgeheimgeheim! address 0.0.0.0 0.0.0.0 no-xauth
crypto isakmp identity hostname
crypto isakmp keepalive 20
!
!
crypto ipsec transform-set TRANSSECUR esp-3des esp-sha-hmac
!
crypto dynamic-map Foo-dynamic 10
set security-association lifetime seconds 28800
set transform-set TRANSSECUR
set pfs group2
match address 130
!
crypto map Foo 30 ipsec-isakmp dynamic Foo-dynamic
! […]
interface Dialer1
! […]
ip ddns update hostname standort2.dyndns.org
ip ddns update dyndns host members.dyndns.org
crypto map Foo
!
![…]
access-list 130 permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255
![…]