Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les étapes à suivre pour dépanner les cas où une carte de Virtual Packet Core (VPC) dans la plate-forme Cisco Ultra Services Platform (UltraM) est bloquée lors de l'amorçage avec l'erreur « Échec de la recherche de VDU » comme indiqué dans les journaux de show.
Sample:
2017-Sep-26+08:05:05.839 [emctrl 218804 error] [2/0/16829 <emctrl:0> emctrl_vnf.c:828] [software internal system syslog] Failed to find VDU, of card number <1>
Si vous vérifiez plus en détail les journaux, vous voyez l'erreur très spécifique qui indique que le type de carte ne correspond pas aux informations de substitution de poste (EM) :
2017-Sep-26+08:03:32.126 [emctrl 218802 info] [2/0/16829 <emctrl:0> emctrl_util.c:381] [software internal system critical-info syslog] siti msg for standby CF, card type doesn't match EM, reboot it 2017-Sep-26+08:03:32.126 [emctrl 218802 info] [2/0/16829 <emctrl:0> emctrl_util.c:376] [software internal system critical-info syslog] siti card 1 card type drvctrl 40010100, siti 0 2017-Sep-26+08:03:32.126 [emctrl 218802 info] [2/0/16829 <emctrl:0> emctrl_util.c:329] [software internal system critical-info syslog] siti sync msg received for card 1 with cardtype 40010100, uuid 9F1F2B1E-35FC-4AF9-807A-E856336702D6 2017-Sep-26+08:03:32.105 [system 1004 info] [2/0/9741 <evlogd:0> evlgd_syslogd.c:279] [software internal system syslog] CPU[2/0]: sitiserv[9533]: SITI_PRESENT: invoking notify card present cmd notify_card_present 1 0 0x40010100 9F1F2B1E-35FC-4AF9-807A-E856336702D6
Comme le montre l'erreur, il existe un identifiant unique (UUID) de la carte affectée. Dans cet exemple, UUID est 9F1F2B1E-35FC-4AF9-807A-E85636702D6.
Idéalement, cet UUID devrait correspondre à la sortie de la commande show emctrl vdu detail output.
show emctrl vdu detail est la commande masquée.
[local]UltraM-QVPC-DI# show emctrl vdu detail
Showing emctrl vdu
card[01]: name[CFC_01 ] uuid[1FE70E43-0F33-4E17-8BFA-439169CD52BA]
card[02]: name[CFC_02 ] uuid[3AFC540B-546E-4F35-A645-A23E62C32C59]
card[03]: name[SFC_03 ] uuid[93359FA0-09C2-4F7C-93F6-17BE0A2AF49F]
card[04]: name[SFC_04 ] uuid[E02C8AAA-7E8A-4881-8018-6EC59963C8F6]
card[05]: name[SFC_05 ] uuid[6F297BF6-4AFC-43AB-A36D-FCD0FAE39DA3]
Si ce résultat est vide, il est possible que le processus EMCtrl soit endommagé.
Cet ID doit être identique à celui affiché sur le module EM comme mis en surbrillance :
admin@scm# show vdus vdu card-type session-function
vdus vdu session-function
card-type session-function
vnfci BOOT_generic_di-chassis_SF1_1
constituent-element-group di-chassis
is-infra true
initialized false
vim-id 93359fa0-09c2-4f7c-93f6-17be0a2af49f
vnfci BOOT_generic_di-chassis_SF2_1
constituent-element-group di-chassis
is-infra true
initialized false
vim-id e02c8aaa-7e8a-4881-8018-6ec59963c8f6
vnfci BOOT_generic_di-chassis_SF3_1
constituent-element-group di-chassis
is-infra true
initialized false
vim-id 54e9a5d6-f4dd-4636-95d3-b29443ebfa14
Pour plus d'informations sur cette instance du côté StarOS, utilisez la commande suivante :
[local]UltraM-QVPC-DI# show vdu detail type session-function instance BOOT_generic_di-chassis_SF1_1
vdu-id: session-function, vdu-instance: BOOT_generic_di-chassis_SF1_1, state: from:Invalid to:Alive
card_number: 3, card_type: 0x42030100, uuid:93359fa0-09c2-4f7c-93f6-17be0a2af49f
networks:
cp-id: di_intf1, state: Alive, type: unknown
vl: vl-di-internal1 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:87:ac:e4, ip: 192.168.1.12
cp-id: di_intf2, state: Alive, type: unknown
vl: vl-di-internal2 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:92:ea:26, ip: 192.168.2.11
cp-id: orch, state: Alive, type: unknown
vl: vl-orchestration vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:1e:f5:b5, ip: 172.16.180.21
cp-id: svc_intf1, state: Alive, type: unknown
vl: vl-service-network1 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:bf:c8:6f, ip: 10.10.10.2
cp-id: svc_intf2, state: Alive, type: unknown
vl: vl-service-network2 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:15:a9:22, ip: 20.20.20.7
cp-id: svc_intf3, state: Alive, type: unknown
vl: vl-service-network1 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:1f:fa:0c, ip: 10.10.10.6
cp-id: svc_intf4, state: Alive, type: unknown
vl: vl-service-network2 vnfc: sf-vnfc-di-chassis
mac: fa:16:3e:2f:6b:00, ip: 20.20.20.10
Si vous faites attention à l'ID de la carte 5, vous voyez qu'il s'agit de 6F297BF6-4AFC-43AB-A36D-FCD0FAE39DA3.
[local]UltraM-QVPC-DI# show emctrl vdu detail
Showing emctrl vdu
card[01]: name[CFC_01 ] uuid[1FE70E43-0F33-4E17-8BFA-439169CD52BA]
card[02]: name[CFC_02 ] uuid[3AFC540B-546E-4F35-A645-A23E62C32C59]
card[03]: name[SFC_03 ] uuid[93359FA0-09C2-4F7C-93F6-17BE0A2AF49F]
card[04]: name[SFC_04 ] uuid[E02C8AAA-7E8A-4881-8018-6EC59963C8F6]
card[05]: name[SFC_05 ] uuid[6F297BF6-4AFC-43AB-A36D-FCD0FAE39DA3]
Pourtant, si vous recherchez le même ID sur le module EM, vous ne le trouvez pas :
admin@scm# show vdus | include vim
vim-id 1fe70e43-0f33-4e17-8bfa-439169cd52ba ---> CF 1
vim-id 3afc540b-546e-4f35-a645-a23e62c32c59 ---> CF 2
vim-id 93359fa0-09c2-4f7c-93f6-17be0a2af49f ---> SF 3
vim-id e02c8aaa-7e8a-4881-8018-6ec59963c8f6 ---> SF 4
vim-id 54e9a5d6-f4dd-4636-95d3-b29443ebfa14 ---> ?
Vous pouvez donc voir que pour la carte du logement 5, il semble y avoir une incohérence.
Lorsque vous consignez plus de détails sur l'ID spécifique sur le StarOS, vous voyez maintenant qu'avec la commande show vdu detail, l'ID est en fait le même que sur le côté EM :
[local]UltraM-QVPC-DI# show vdu detail type session-function instance BOOT_generic_di-chassis_SF3_1
vdu-id: session-function, vdu-instance: BOOT_generic_di-chassis_SF3_1, state: from:Invalid to:Alive
card_number: 5, card_type: 0x42030100, uuid:54e9a5d6-f4dd-4636-95d3-b29443ebfa14
Vous pouvez ainsi confirmer que le processus EMCtrl ne dispose pas des informations appropriées.
Si vous vérifiez le journal, vous voyez cet avertissement :
2017-Sep-26+08:36:31.317 UltraM-QVPC-DI [emctrl 218802 info] [2/0/20871 <emctrl:0> emctrl_util.c:579] [software internal system critical-info syslog] drvctrl uuid mismatch /6F297BF6-4AFC-43AB-A36D-FCD0FAE39DA3 with em uuid 54e9a5d6-f4dd-4636-95d3-b29443ebfa14, use drvctrl uuid
1. Si vous supprimez la tâche EMCtrl, cela n'aide pas.
2. En outre, si vous redémarrez la carte, cela n'aide pas.
Ceci est probablement dû à la table EMCtrl corrompue et c'est la conséquence du bogue tel que vous le savez jusqu'à présent.
La sortie de la liste show emctrl vdu serait entièrement vide :
Showing emctrl vdu card[01]: name[ ] uuid[ ] card[02]: name[ ] uuid[ ]
Afin de vérifier l'état réel de la carte du côté du proxy VNFM :
#show vdu detail type control-function instance BOOT_generic_di-chasis_CF1_1
vdu-id: control-function, vdu-instance: BOOT_generic_di-chasis_CF1_1, state: from:Invalid to:Alive
Bogue connu : CSCvf32599
Solution de contournement: Redémarrer la tâche EMCtrl :
task kill facility emctrl all
Parfois, vous voyez qu'il manque une carte de type SF ou CF dans la table des cartes.
Comme le montre le résultat, le StarOS ne voit qu'une seule carte CF :
[local]AUPGW101# show card tabl
Wednesday September 27 09:26:46 UTC 2017
Slot Card Type Oper State SPOF Attach
----------- -------------------------------------- ------------- ---- ------
1: CFC Control Function Virtual Card Active Yes
3: FC 4-Port Service Function Virtual Card Active No
4: FC 4-Port Service Function Virtual Card Active No
5: FC 4-Port Service Function Virtual Card Active No
6: FC 4-Port Service Function Virtual Card Active No
7: FC 4-Port Service Function Virtual Card Active No
8: FC 4-Port Service Function Virtual Card Active No
9: FC 4-Port Service Function Virtual Card Active No
10: FC 4-Port Service Function Virtual Card Standby -
Pourtant, si vous vérifiez la console de débogage de la carte 2, vous voyez qu'elle tente de se connecter :
[local]AUPGW101# debug consol card 1 cpu 0
Wednesday September 27 09:26:58 UTC 2017
[local]AUPGW101# 2017-Sep-27+09:23:18.370 card 1-cpu0: collect persistdump for card <2> success
2017-Sep-27+09:24:22.112 card 1-cpu0: Hatsystem rcvd card 2/0 fail req from card (1) emctrl/0 - 32:150:3
2017-Sep-27+09:24:22.115 card 1-cpu0: The Control Function Virtual Card with serial number in slot 2 has failed and will be brought down and brought back online. (Device=CARD, Reason=EMCTRL_CARDTYPE_MISMATCH, Status=0)
C'est le cas, comme vous pouvez le voir dans show log as EMCtrl, qui pense que les FC n'existent pas dans EM :
2017-Sep-27+09:27:13.964 [emctrl 218802 info] [1/0/7805 <emctrl:0> emctrl_util.c:357] [software internal system critical-info syslog] siti msg for standby CF, but doesn't exist in EM, reboot it
2017-Sep-27+09:27:13.964 [emctrl 218802 info] [1/0/7805 <emctrl:0> emctrl_util.c:329] [software internal system critical-info syslog] siti sync msg received for card 2 with cardtype 40010100, uuid C6217904-8F65-4C48-B607-4F13EAE6745D
2017-Sep-27+09:27:13.939 [system 1004 info] [1/0/7684 <evlogd:0> evlgd_syslogd.c:279] [software internal system syslog] CPU[1/0]: sitiserv[3063]: SITI_PRESENT: invoking notify card present cmd notify_card_present 2 0 0x40010100 C6217904-8F65-4C48-B607-4F13EAE6745D
Vous pouvez en effet confirmer que :
[local]AUPGW101# show emctrl vdu list
Wednesday September 27 09:30:21 UTC 2017
Showing emctrl vdu
card[01]: name[CFC_01 ] uuid[42913D9A-91A9-4E5E-8473-AEADD73BEC08]
card[03]: name[SFC_03 ] uuid[CB2C4429-0965-4394-8200-ABB4071BB067]
card[04]: name[SFC_04 ] uuid[17997C02-DF9F-40BC-8A41-D2B9D448D47C]
card[05]: name[SFC_05 ] uuid[159F91EE-B6A4-4DE6-A8C9-F900CD087093]
card[06]: name[SFC_06 ] uuid[7EE371A9-4E64-477F-AA09-42B6ED70B92B]
card[07]: name[SFC_07 ] uuid[DF2D38F2-01FD-4E95-97EC-4B1EB75683FD]
card[08]: name[SFC_08 ] uuid[E7D7F817-09C6-4EBA-9537-A66A686713A1]
card[09]: name[SFC_09 ] uuid[B24BE6CC-EB7B-483D-A859-284EF638647C]
card[10]: name[SFC_10 ] uuid[2AAD074F-C65C-4708-AAA9-A76588BD434D]
Solution de contournement: Redémarrez la tâche EMCtrl.