Problemen oplossen en controleren bij de eerste installatie van SD-Access Wireless
Inhoud
Inleiding
In dit artikel worden de basisstappen voor probleemoplossing beschreven om basisconnectiviteitsproblemen in draadloze SD-Access-instellingen te identificeren. Het beschrijft de items en opdrachten die moeten worden gecontroleerd om problemen in de oplossing met betrekking tot draadloze communicatie te isoleren.
Voorwaarden
Vereisten
Kennis van de SD-Access oplossing
Een reeds ingestelde SD-toegangstopologie
Gebruikte componenten
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt. Er zijn andere soorten apparaten die worden ondersteund voor draadloze SD-toegang, maar dit artikel richt zich op de apparaten die in deze sectie worden beschreven. Opdrachten kunnen variëren, afhankelijk van het platform en de softwareversie.
8.5.151 Draadloze controller
16.9.3 9300 switch als edge node
Topologie
Problemen oplossen en isoleren
Snelle verificaties
Er is een reeks vereisten in SD-toegangsscenario's die vaak een bron van fouten zijn, dus controleer eerst of aan deze vereisten is voldaan:
- Zorg ervoor dat u een specifieke route hebt (en niet de standaardroute gebruikt) die verwijst naar de WLC op de LISP-besturingsvlakknoop
- Zorg ervoor dat uw toegangspunten zich in de Infra VN bevinden, met behulp van de globale routeringstabel
- Zorg ervoor dat toegangspunten verbinding hebben met de WLC door de WLC vanaf het toegangspunt zelf te pingen
- Zorg ervoor dat de weefselstatus van het besturingsvlak op de WLC is ingesteld
- Zorg ervoor dat de toegangspunten in de status Fabric-enabled zijn
scenario 1. WLC-registratie verifiëren met het LISP/MAP-serverbesturingsvlak
Wanneer u de WLC toevoegt aan de structuur in DNA Center, worden opdrachten naar de controller geduwd om een verbinding tot stand te brengen met de node die is gedefinieerd als controlevlak in DNA-C. De eerste stap is om ervoor te zorgen dat deze registratie succesvol is. Als de LISP-configuratie op het controlevlak op de een of andere manier beschadigd is, kan deze registratie mislukken.
Als deze status wordt weergegeven als down, kan het interessant zijn om debugs of een pakketopname uit te voeren tussen de WLC en het controlevlak. De registratie betreft zowel TCP als UDP op 4342. Als het besturingsvlak niet de juiste configuratie heeft gekregen, kan het met een TCP RST reageren op het TCP SYN dat door de WLC is verzonden.
Dezelfde status kan worden geverifieerd met een overzicht van de structuurmap-server op de opdrachtregel. Het proces wordt gedebugd met debug fabric lisp map-server allemaal op de WLC CLI. Om een herverbindingspoging uit te lokken, kunt u naar DNA Center gaan en ervoor kiezen om de WLC van de stof te verwijderen en opnieuw toe te voegen.
Mogelijke redenen zijn ontbrekende configuratielijnen in het controlevlak. Hier is een voorbeeld van een werkende configuratie (alleen het belangrijkste deel):
rtr-cp-mer-172_16_200_4#show run | s WLC locator-set WLC 10.241.0.41 exit-locator-set map-server session passive-open WLC
Als de WLC-ip ontbreekt (hier 10.241.0.41) of als de opdracht passief openen ontbreekt, weigert de CP de WLC-verbinding.
De te gebruiken debugs zijn:
- 'Debug capwap events inschakelen'
- 'Fouten foutopsporing CAPWAP inschakelen'
- 'Debug Fabric AP-join Events inschakelen'
- 'Debug Fabric AP-join Details inschakelen'
- 'Debug Fabric LISP Map-Server All Enable'
Hier is een voorbeeld van het controlevliegtuig dat de WLC niet beantwoordt
*msfMsgQueueTask: May 07 14:08:10.080: Sent map-request to MS 10.32.47.128 for AP 10.32.58.36 VNID 4097 *msfMsgQueueTask: May 07 14:08:10.080: No messages are present in the Client list for Local UDP socket *msfMsgQueueTask: May 07 14:08:10.080: msfSendLocalUDPSocketMessage:637 Message get for UDP file socket list with path /tmp/msif_local_udp_socket_file failed *osapiBsnTimer: May 07 14:08:15.179: Map-reply timer for MS IP 10.32.47.128 expired for AP IP 10.32.58.36 and VNID 4097 *msfMsgQueueTask: May 07 14:08:15.179: msfQueue: recieved LISP_MAP_SERVER_TIMEOUT_QUEUE_MSG *msfMsgQueueTask: May 07 14:08:15.179: Found entry AP 10.32.58.36 vnid 4097 *msfMsgQueueTask: May 07 14:08:15.179: Added AP 10.32.58.36 VNID 4097 for long retry map-request *msfMsgQueueTask: May 07 14:08:15.179: Found entry AP 10.32.58.36 vnid 4097 *msfMsgQueueTask: May 07 14:08:15.179: No messages are present in the Client list for Local UDP socket *msfMsgQueueTask: May 07 14:08:15.179: msfSendLocalUDPSocketMessage:637 Message get for UDP file socket list with path /tmp/msif_local_udp_socket_file failed *spamApTask0: May 07 14:08:16.084: 00:fc:ba:15:95:00 WTP Event Request from 10.32.58.36:5248 epoch 1525694896 *spamApTask0: May 07 14:08:16.084: 00:fc:ba:15:95:00 WTP Event Response sent to 10.32.58.36:5248 *osapiBsnTimer: May 07 14:08:17.839: NAK Timer expiry callback *msfMsgQueueTask: May 07 14:08:17.839: msfQueue: recieved LISP_MAP_SERVER_NAK_TIMEOUT_QUEUE_MSG *msfMsgQueueTask: May 07 14:08:17.839: Started periodic NAK processing timer *msfMsgQueueTask: May 07 14:08:17.839: Process list of AP (1) for which RLOC is not received
Hier is een voorbeeld van de WLC-debugs van een toegangspunt dat in een uitgeschakelde fabriekstoestand wordt aangesloten omdat het fabriekscontrolevlak een specifieke route naar de WLC miste
(POD3-WLC1) >*emWeb: Oct 16 08:54:21.593: Fabric is supported for apType 54
*emWeb: Oct 16 08:54:21.593: Fabric is supported for apType 54
*emWeb: Oct 16 08:55:26.295: ip c0a82700,subnet ffffff00,l2vnid 8191,l3vnid 1001
*emWeb: Oct 16 08:55:26.295: Vnid Mapping added at index 2 with entries 192_168_39_0-INFRA_VN,8191,4097,c0a82700,ffffff00.Count 3
*emWeb: Oct 16 08:55:26.295:
Log to TACACS server(if online): fabric vnid create name 192_168_39_0-INFRA_VN l2-vnid 8191 ip 192.168.39.0 subnet 255.255.255.0 l3-vnid 4097
*spamReceiveTask: Oct 16 08:55:26.295: Fabric is supported for AP f4:db:e6:61:24:a0 (Pod3-AP4800). apType 54
*spamReceiveTask: Oct 16 08:55:26.295: spamProcessFabricVnidMappingAddRequest: Fabric Adding vnid mapping for AP Pod3-AP4800 f4:db:e6:61:24:a0,lradIp 192.168.39.100,AP l2_vnid 0, AP l3_vnid 0
*spamReceiveTask: Oct 16 08:55:26.295: Vnid Mapping return from index 2 with entries name 192_168_39_0-INFRA_VN,l2vnid 8191,l3vnid 4097,ip c0a82700,mask ffffff00.Count 3
*spamReceiveTask: Oct 16 08:55:26.295: spamSendFabricMapServerRequest: MS request from AP Pod3-AP4800 f4:db:e6:61:24:a0,l3vnid 4097,PMS 192.168.30.55,SMS 0.0.0.0,mwarIp 192.168.31.59,lradIp 192.168.39.100
*emWeb: Oct 16 08:55:29.944:
Log to TACACS server(if online): save
(POD3-WLC1) >*spamApTask6: Oct 16 08:56:49.243: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.
*spamApTask6: Oct 16 08:56:51.949: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.
*spamApTask6: Oct 16 08:56:51.953: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.
*spamApTask6: Oct 16 08:56:51.953: Fabric is supported for AP f4:db:e6:64:02:a0 (Pod3-AP3800). apType 52,apModel AIR-AP3802I-B-K9.
*spamApTask6: Oct 16 08:56:51.953: spamSendFabricMapServerRequest: MS request from AP Pod3-AP3800 f4:db:e6:64:02:a0 can not be sent ,AP vnid mapping does not exist
Het is interessant om op te merken dat als er twee besturingsvlakken in uw stoffennetwerk zijn, de WLC altijd contact zal opnemen met beide voor registratie of vragen. De verwachting is dat beide besturingsvlakken positieve antwoorden geven op registraties, dus de WLC zal er niet in slagen AP's in de stof te registreren als een van de twee besturingsvlakken het om welke reden dan ook afwijst. Eén controlevliegtuig dat niet antwoordt, is echter acceptabel en het resterende controlevliegtuig zal worden gebruikt.
AP's bereiken de WLC via de wereldwijde routeringstabel, maar LISP wordt nog steeds gebruikt om de WLC op te lossen. Het verkeer dat door AP's naar de WLC wordt verzonden, is pure CAPWAP-besturing (geen vxlan betrokken), maar het retourverkeer dat door de WLC naar de AP wordt verzonden, wordt over Vxlan op de overlay uitgevoerd. U kunt de connectiviteit van de AP-gateway SVI aan de rand naar de WLC niet testen omdat het een Anycast-gateway is en hetzelfde IP ook op de border node bestaat. Om connectiviteit te testen, is het het beste om vanaf het toegangspunt zelf te pingen.
scenario 2. Toegangspunten krijgen geen IP-adres
Toegangspunten krijgen naar verwachting een IP-adres van de AP Poo, in de Infra VNl gedefinieerd in DNA Center. Als dit niet gebeurt, betekent dit meestal dat de switchpoort waarop het toegangspunt is aangesloten, niet naar het juiste vlan is verplaatst. Wanneer de switch detecteert (via CDP) dat een toegangspunt is verbonden, past hij een switchport-macro toe waarmee de switchport wordt ingesteld in het door DNA-C gedefinieerde vlan voor de AP-groep. Als de problematische switchport inderdaad niet is geconfigureerd met de macro, kunt u de configuratie handmatig instellen (zodat het toegangspunt een IP-adres krijgt, zich bij de WLC voegt en waarschijnlijk de code upgradet en mogelijk een CDP-bug oplost) of problemen oplossen met het CDP-verbindingsproces. U kunt desgewenst host-onboarding configureren om de poort op DNA-Center statisch te definiëren om een toegangspunt te hosten, zodat het wordt voorzien van de juiste configuratie.
Smartport-macro's worden niet automatisch geactiveerd als de switch niet ten minste één toegangspunt heeft ontvangen, u kunt controleren of de toegangspunt-macro is voorzien van het juiste vlan (in plaats van het standaard vlan 1)
Pod3-Edge1#show macro auto device Device:lightweight-ap Default Macro:CISCO_LWAP_AUTO_SMARTPORT Current Macro:CISCO_LWAP_AUTO_SMARTPORT Configurable Parameters:ACCESS_VLAN Defaults Parameters:ACCESS_VLAN=1 Current Parameters:ACCESS_VLAN=2045
De commando's die Cisco DNA-C aanstuurt om dit in te stellen zijn
macro auto execute CISCO_WIRELESS_LIGHTWEIGHT_AP_EVENT builtin CISCO_LWAP_AUTO_SMARTPORT ACCESS_VLAN=2045 macro auto global processing
scenario 3. Toegangspunten hebben geen vxlan-tunnel die naar hun Fabric Edge-node is gebouwd
Zodra een toegangspunt zich bij de WLC aansluit, registreert de WLC (als de toegangspunt geschikt is voor verbindingen) het toegangspunt op het besturingsvlak als een speciaal type client. Het besturingsvlak vraagt vervolgens de Fabric Edge-node waar het toegangspunt is aangesloten om een valanitunnel naar het toegangspunt te bouwen.
Het toegangspunt gebruikt alleen vxlan-inkapseling om clientverkeer te verzenden (en alleen voor clients in de status RUN). Daarom is het normaal dat er geen vxlan-informatie op het toegangspunt wordt weergegeven totdat een fabric-client verbinding maakt.
Op het toegangspunt toont de opdracht show ip tunnel fabric de vxlan tunnel informatie zodra een client verbinding heeft gemaakt.
AP4001.7A03.5736#show ip tunnel fabric
Fabric GWs Information:
Tunnel-Id GW-IP GW-MAC Adj-Status Encap-Type Packet-In Bytes-In Packet-Out Bytes-out
1 172.16.2.253 00:00:0C:9F:F4:5E Forward VXLAN 39731 4209554 16345 2087073
AP4001.7A03.5736#
Op de Fabric Edge-node toont de opdracht show access-tunnel summary de vxlan-tunnels die naar de toegangspunten zijn gebouwd. De tunnels zullen worden getoond zodra het controlevliegtuig hun creatie heeft besteld wanneer het AP zich aansluit.
edge01#show access-tunnel summ Access Tunnels General Statistics: Number of AccessTunnel Data Tunnels = 2 Name SrcIP SrcPort DestIP DstPort VrfId ------ --------------- ------- --------------- ------- ---- Ac1 172.16.2.253 N/A 192.168.102.130 4789 2 Ac0 172.16.2.253 N/A 192.168.102.131 4789 2 Name IfId Uptime ------ ---------- -------------------- Ac1 0x0000003B 1 days, 22:53:48 Ac0 0x0000003A 0 days, 22:47:06
U kunt op de pagina WLC op het toegangspunt de instantie-id L2 LISP controleren die overeenkomt met dat toegangspunt en vervolgens de statistieken van die instantie controleren op de Fabric Edge waarop deze is aangesloten.
SDA-D-6880-1#show lisp instance-id 8188 ethernet statistics
LISP EID Statistics for instance ID 8188 - last cleared: never
Control Packets:
Map-Requests in/out: 0/0
Encapsulated Map-Requests in/out: 0/0
RLOC-probe Map-Requests in/out: 0/0
SMR-based Map-Requests in/out: 0/0
Map-Requests expired on-queue/no-reply 0/0
Map-Resolver Map-Requests forwarded: 0
Map-Server Map-Requests forwarded: 0
Map-Reply records in/out: 0/0
Authoritative records in/out: 0/0
Non-authoritative records in/out: 0/0
Negative records in/out: 0/0
RLOC-probe records in/out: 0/0
Map-Server Proxy-Reply records out: 0
Map-Register records in/out: 24/0
Map-Server AF disabled: 0
Authentication failures: 0
Map-Notify records in/out: 0/0
Authentication failures: 0
Deferred packet transmission: 0/0
DDT referral deferred/dropped: 0/0
DDT request deferred/dropped: 0/0
Scenario 4. Toegang tot tunnelingangen ontbreekt na enige tijd
Het is mogelijk dat de toegangstunnels met succes worden gemaakt wanneer WLC voor het eerst wordt geleverd via Cisco DNA-C en aan de fabric wordt toegevoegd, maar bij het opnieuw inrichten van draadloze configuratie (zoals de WLAN-configuratie) wordt opgemerkt dat toegangstunnelvermeldingen voor toegangspunten ontbreken, waardoor draadloze clients IP niet met succes kunnen ophalen.
De topologie is 9500(CP) --> 9300 (Edge) --> AP --> Wireless Client.
Items worden correct geobserveerd in show access-tunnel samenvatting op de edge node:
edge_2#show access-tunnel summary Access Tunnels General Statistics: Number of AccessTunnel Data Tunnels = 1 Name SrcIP SrcPort DestIP DstPort VrfId ------ --------------- ------- --------------- ------- ---- Ac0 172.16.3.98 N/A 172.16.3.131 4789 0 Name IfId Uptime ------ ---------- -------------------- Ac0 0x0000003C 5 days, 18:19:37
Bij het controleren van show platform software fed switch active ifm interfaces access-tunnel ontbreekt de vermelding voor het toegangspunt of kan deze niet worden geprogrammeerd in de hardware in dit voorbeeld.
edge_2#show platform software fed switch active ifm interfaces access-tunnel Interface IF_ID State ---------------------------------------------------------------- Ac0 0x0000003c FAILED
Voor meer output:
edge_2#sh platform software access-tunnel switch active F0 Name SrcIp DstIp DstPort VrfId Iif_id Obj_id Status -------------------------------------------------------------------------------------------- Ac0 98.3.16.172 131.3.16.172 0x12b5 0x000 0x00003c 0x00585f Done edge_2#sh platform software access-tunnel switch active R0 Name SrcIp DstIp DstPort VrfId Iif_id --------------------------------------------------------------------- Ac0 172.16.3.98 172.16.3.131 0x12b5 0x0000 0x00003c
U moet de verschillende uitgangen vergelijken en elke tunnel die door de show wordt getoond, moet in elk van hen aanwezig zijn.
scenario 5. draadloze clients kunnen geen IP-adres verkrijgen
Als de vxlan-tunnel aanwezig is en alles er goed uitziet, maar de draadloze clients zijn systematisch niet in staat om een IP-adres te verkrijgen, wordt u misschien geconfronteerd met een optie 82-probleem. Aangezien de DHCP DISCOVER van de client wordt doorgestuurd door de Anycast-gateway op de edge-node, zou er problemen zijn voor de DHCP-serverAANBIEDING om op de terugweg door de border naar de right edge-node te worden verzonden. Daarom voegt de fabric edge die de DHCP DISCOVER doorstuurt een optie 82-veld toe aan de DHCP DISCOVER die de daadwerkelijke fabric RLOC (loopback ip) van de edge node bevat die samen met andere informatie is gecodeerd. Dit betekent dat uw DHCP-server optie 82 moet ondersteunen.
Als u problemen met het DHCP-proces wilt oplossen, maakt u opnamen op de fabric-nodes (met name de node aan de rand van de client) om te controleren of de rand van de fabric het veld optie 82 toevoegt.
scenario 6. Gaststructuur/webverificatie werkt niet/leidt clients niet om
Het scenario voor de gaststructuur lijkt sterk op Central Web Authentication (CWA) op Flexconnect-toegangspunten en werkt precies hetzelfde (zelfs als de verbindings-toegangspunten zich niet in de flexconnect-modus bevinden).
De omleiding ACL en URL moet worden geretourneerd door ISE in het eerste mac-verificatieresultaat. Controleer deze in de ISE-logs en op de pagina met clientdetails op de WLC.
De omleiding ACL moet aanwezig zijn als een Flex ACL op de WLC en moet "vergunning" verklaringen naar het ISE IP-adres op poort 8443 (ten minste) bevatten.
De client moet zich in de "CENTRAL_WEBAUTH_REQ" -status bevinden op de pagina met clientgegevens op de WLC. De client kan zijn standaardgateway niet pingen en dit wordt verwacht. Als u niet wordt omgeleid, kunt u proberen handmatig een IP-adres in de webbrowser van de client in te voeren (om DNS uit te sluiten, maar de ISE-hostnaam moet hoe dan ook worden opgelost). U moet de ISE IP op poort 8443 in de clientbrowser kunnen invoeren en de portaalpagina kunnen zien, omdat deze stroom niet wordt omgeleid. Als dit niet gebeurt, wordt u geconfronteerd met een ACL-probleem of een routeringsprobleem naar. Verzamel pakketopnames onderweg om te zien waar de HTTP-pakketten worden gestopt.
begrijpen
Hoe krijgt een draadloze client een IP-adres in Fabric Architecture
Packet capture vindt plaats tussen de Fabric AP en de Fabric Edge. Pakketten worden gedupliceerd omdat er twee DHCP Discover-pakketten zijn verzonden. Het verkeer was alleen binnendringen en vastgelegd op de Fabric Edge.
Er zijn altijd twee DHCP-pakketten. Eén die door CAPWAP rechtstreeks naar de controller wordt verzonden om deze up-to-date te houden. De andere wordt door VXLAN naar de Control Node verzonden. Wanneer het toegangspunt bijvoorbeeld een DHCP-aanbieding met VXLAN van de DHCP-server ontvangt, verzendt het een kopie naar de controller met CAPWAP.
Om te zien waar het pakket is verzonden, moet u erop klikken op Wireshark. Hier kunnen we zien dat de bron onze AP 172.16.3.131 is en het pakket is verzonden naar de Fabric Edge 172.16.3.98. De Fabric Edge heeft het doorgestuurd naar de Control Node.
Begrijp de webomleidingsstroom in een fabric-scenario
De redirect ACL op de WLC definieert welk verkeer wordt omgeleid / onderschept op overeenkomende ontkenningsverklaringen (er is een impliciete ontkenning aan het einde). Dat verkeer dat moet worden omgeleid, wordt naar de WLC binnen CAPWAP-inkapseling verzonden zodat de WLC kan omleiden. Bij het matchen van een vergunningsverklaring leidt het dat verkeer niet om en laat het door en door op de stof (verkeer naar ISE komt in deze categorie).
Logbestanden van het toegangspunt dat zich bij de WLC aansluit in de status Fabric-enabled
Zodra Access-Point zich registreert bij WLC, registreert de controller zijn IP- en MAC-adres in SDA Control Node (LISP Map Server).
Het toegangspunt wordt alleen in de fabric-modus aan de WLC toegevoegd als de WLC het LISP RLOC-pakket ontvangt. Dit pakket wordt verzonden om er zeker van te zijn dat het toegangspunt is verbonden met een Fabric Edge.
De debugs die op de WLC voor dit voorbeeld worden gebruikt zijn:
- 'Debug capwap events inschakelen'
- 'Fouten foutopsporing CAPWAP inschakelen'
- 'Debug Fabric AP-join Events inschakelen'
- 'Debug Fabric AP-join Details inschakelen'
- 'Debug Fabric LISP Map-Server All Enable'
Voor de test wordt het toegangspunt opnieuw opgestart:
*spamApTask0: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for Aggregated Payload 3 sent to 172.16.3.131:5256 *msfMsgQueueTask: May 07 13:00:18.804: NAK list count becoming 0 *msfMsgQueueTask: May 07 13:00:18.804: NAK list count becoming 0 *msfMsgQueueTask: May 07 13:00:18.804: Cleaned up AP RLOC NAK entry for AP 172.16.3.131 vnid 4097 for BOTH MS *msfMsgQueueTask: May 07 13:00:18.804: Inserted entry for AP IP 172.16.3.131 and VNID 4097, db idx 12 *msfMsgQueueTask: May 07 13:00:18.804: Map-reply timer started for AP IP 172.16.3.131 and VNiD 4097 *msfMsgQueueTask: May 07 13:00:18.804: Creating new timer for AP IP 172.16.3.131 and VNID 4097 *msfMsgQueueTask: May 07 13:00:18.804: Map-reply Timer Started Successfully for AP IP 172.16.3.131 and VNID 4097 *msfMsgQueueTask: May 07 13:00:18.804: Not able to find nonce 0x3cd13556-0x81864b7b avl entry *msfMsgQueueTask: May 07 13:00:18.804: FAIL: not able to find avl entry *msfMsgQueueTask: May 07 13:00:18.804: Nonce 0x3cd13556-0x81864b7b inserted into nonce aVL tree for AP IP 172.16.3.131 VNID 4097 for MS 172.16.3.254 *msfMsgQueueTask: May 07 13:00:18.804: Set nonce 0x3cd13556-0x81864b7b for AP 172.16.3.131 and VNID 4097 *msfMsgQueueTask: May 07 13:00:18.804: Nonce 0x3cd13556-0x81864b7b is updated for AP IP 172.16.3.131, VNID 4097 and MS IP 172.16.3.254, db idx 12 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for PHY payload sent to 172:16:3:131 *msfMsgQueueTask: May 07 13:00:18.804: Build and send map-request for AP IP 172.16.3.131 and VNID 4097 to MS IP 172.16.3.254 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:3:131 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:3:131 *msfMsgQueueTask: May 07 13:00:18.804: nonce = 3cd13556-81864b7b lisp_map_request_build allocating nonce *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.3.131 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for CcxRmMeas payload sent to 172.16.3.131 *msfMsgQueueTask: May 07 13:00:18.804: Sending map-request for AP 172.16.3.131 VNID 4097 to MS 172.16.3.254 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update request for AP ext-logging AP ext-logging message sent to 172.16.3.131:5256 *spamReceiveTask: May 07 13:00:18.804: 70:70:8b:20:29:00 Configuration update for Delba sent to 172.16.3.131:5256 *msfMsgQueueTask: May 07 13:00:18.804: Map-request for AP IP 172.16.3.131 VNID 4097 to MS 172.16.3.254 is sent *msfMsgQueueTask: May 07 13:00:18.804: Sent map-request to MS 172.16.3.254 for AP 172.16.3.131 VNID 4097 *msfMsgQueueTask: May 07 13:00:18.804: Invalid secondary MS IP 0.0.0.0 for map-request for AP IP 172.16.3.131 *msfMsgQueueTask: May 07 13:00:18.804: No messages are present in the Client list for Local UDP socket *msfTcpTask: May 07 13:00:18.807: Sending the UDP control packet to queue task *msfMsgQueueTask: May 07 13:00:18.807: msfQueue: recieved LISP_MAP_SERVER_UDP_PACKET_QUEUE_MSG *msfMsgQueueTask: May 07 13:00:18.807: Mapping Record has locators and actions *msfMsgQueueTask: May 07 13:00:18.807: Mapping record address 172.16.3.98 EID address 172.16.3.98 *msfMsgQueueTask: May 07 13:00:18.807: Got AVL entry for nonce 0x3cd13556-0x81864b7b in map-reply for AP IP 172.16.3.131 *msfMsgQueueTask: May 07 13:00:18.807: Sent received RLOC IP 172.16.3.98 for AP 172.16.3.131 and VNID 4097 in map-reply to spam task *msfMsgQueueTask: May 07 13:00:18.807: Added RLOC 172.16.3.98 for AP IP 172.16.3.131 *spamReceiveTask: May 07 13:00:18.807: Recieved Fabric rloc response from msip 172.16.3.254 with apvnid 4097,fabricRLoc 172.16.3.98 apip 172.16.3.131 apRadMac 70:70:8b:20:29:00
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
17-Oct-2019
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)