Solution du IT Problème "ping impossible".
Comme l'a dit Christophe en commentaire, il suffisait tout simplement de faire un ping en explicitant le nom de la VRF sur R1 : ping vrf CUST 192.168.0.1.
En effet, l'interface est configurée en étant membre de la VRF CUST. Donc elle n'est plus dans le contexte global du routeur. Il est d'ailleurs possible de vérifier cela en tapant un show ip route sur R1, on voit que le réseau n'est plus sur le routeur (ce que j'appelle contexte global), par contre un show ip route vrf CUST permet de voir l'existence de la route sur la vrf CUST.
J'en profite aussi pour dire que la solution Cisco EVN (Easy Virtual Network) facilite la gestion des VRFs. En effet, il suffira alors de se mettre dans la VRF CUST (via routing-context vrf CUST), puis de taper ping 192.168.0.1 pour faire un ping dans la VRF CUST.
Passons maintenant au problème ...Architecture globale |
Le réseau est un coeur basé sur du MPLS VPN, sur lequel les sites se connectent, ce qu'il y a de plus classique (sans feature spécifique ou technologie spécifique). Par contre, du ZBF et de la QoS a été configuré sur les routeurs.
Le problème est simple : des utilisateurs travaillant sur un site central (représenté par Client) se plaignent de problèmes lors de communications avec des serveurs situés au site central (représenté par Server). Ces problèmes sont récurrents depuis l'installation du site, et n'ont pu malheureusement être clairement corrigés. Malheureusement le NOC considère que tout est OK et que le problème vient plutôt de l'opérateur MPLS.
Les utilisateurs utilisent une application intranet requérant une authentification web. Des transferts de fichiers FTP se font entre le site central et les sites distants, sans problème apparent. Les utilisateurs sur d'autres sites ne rencontrent pas de problème. Aucune collision n'est détectée au niveau des interfaces des routeurs.
La question ici n'est pas d'identifier le problème, mais plutôt de trouver un moyen simple pour prouver l'hypothèse.
No comments:
Post a Comment