Vor einigen Tagen hat mich ein Kommilitone gefragt, ob ich ihm bei einem Problem bei der Konfiguration eines Layer-3-Switches helfen könne. Dieser würde ein unerklärliches Verhalten aufweisen und könne kein anderes System pingen. Er selbst könne jedoch von beliebigen Quellen gepingt werden. Nachdem wir die typischen Fehlerquellen gemeinsam ausschließen konnten, wurde ich neugierig. Die Ursache lag in dem Nichtbeachten des Virtual Routing and Forwarding. Wie wir das Ping-Problem genauer identifizieren und lösen konnten, erkläre ich in diesem Beitrag.
Symptom
Ein Desktop-PC ist physisch direkt mit dem Management-Interface eines Layer-3-Switches verbunden. Der Ping von dem PC zum Switch auf die IP-Adresse 192.168.1.1 funktioniert problemlos. Ein Ping vom Switch zum PC auf die IP-Adresse 192.168.1.3 hingegen nicht. Dieses Problem bleibt auch bestehen, wenn die Firewall des PCs deaktiviert wird. Mit Hilfe eines zweiten Switches kann verifiziert werden, dass der PC generell auf einen Ping anspricht.
Mit diesen Informationen übernehme ich das Problem. Ich überprüfe alle getätigten Einstellungen und rekonstruiere dann das beschriebene Verhalten. Das Problem wird vermutlich auf dem Switch und in seiner Konfiguration zu suchen sein. Ich pinge zunächst selbst den PC und versuche dann die eigene Adresse zu pingen.
switch# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
ping: sendto 192.168.1.3 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.3 64 chars, No route to host
Request 1 timed out
(...)
--- 192.168.1.3 ping statistics ---\n5 packets transmitted, 0 packets received, 100.00% packet loss
switch# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto 192.168.1.1 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.1 64 chars, No route to host
Request 1 timed out
(...)
--- 192.168.1.1 ping statistics ---\n5 packets transmitted, 0 packets received, 100.00% packet lossLetzteres Resultat habe ich nicht erwartet. Wieso sollte sich der Layer-3-Switch nicht auf seinem eigenen Interface pingen können? Es erhärtet meinen Verdacht, dass bei der Konfiguration etwas schiefgegangen ist.
Problem
Zunächst hole ich mir Informationen über die Netzwerkschnittstellen des Layer-3-Switches ein. Mich interessiert, ob das Management-Interface überhaupt aktiv gelistet wird. Ich weiß natürlich, dass es aktiv sein muss, damit der Ping vom PC aus überhaupt funktioniert, aber irgendwo muss ich die Fehlersuche beginnen.
switch# show interface brief
------------------------------------------------------------------------------------------
Ethernet VLAN Type Mode Status Reason Speed Port Ch
Interface#
------------------------------------------------------------------------------------------
Eth1/1 1 eth access down SFP not inserted 10G(D) --
(...)
Eth2/6 1 eth access down SFP not inserted 40G(D) --
------------------------------------------------------------------------------------------
Port VRF Status IP Address Speed MTU
------------------------------------------------------------------------------------------
mgmt0 -- up 192.168.1.1 1000 1500Offensichtlich ist das Interface aktiv und auch mit der korrekten IP-Adresse versehen. Auf den ersten Blick scheint es doch nicht an der aktiven Konfiguration zu liegen. Um dies zu verifizieren, lasse ich mir die aktuelle Konfiguration anzeigen
switch# show running-config
(...)
vlan 1
vrf context management
(...)
interface Ethernet1/1
(...)
interface mgmt0
vrf member management
ip address 192.168.1.1/24
line console
line vty
boot kickstart bootflash:/n6000-uk9-kickstart.7.0.2.N1.1.bin
boot system bootflash:/n6000-uk9.7.0.2.N1.1.bin
poap transitIch bin nun mehrmals über die Abkürzung VRF gestolpert, die mir bisher auch nicht bekannt ist. Eine kleine Recherche hierzu ergibt auch schon des Rätsels Lösung.
Lösungsstrategie
Die Abkürzung VRF steht für Virtual Routing and Forwarding. Eine VRF-Instanz bezeichnet eine im Cisco IOS und Routing Hardware anderer Hersteller implementierte Funktion, die einen neuen virtuellen Router auf einem physischen Router anlegt. Durch das Anlegen eines virtuellen Routers entsteht ein komplett neues Netz, d. h. in der VRF-Instanz 1, 2, 3, …, n kann jedes mal der komplette Adressraum vergeben werden und jedes ausgehende Interface einer jeder Instanz mit der gleichen IP-Adresse vergeben werden, obwohl für die angeschlossenen Hosts nur die Hosts derselben Instanz sichtbar sind. Eine Kommunikation zwischen Instanzen ist ohne internes, explizites Routing nicht möglich.Wikipedia
Ein genauer Blick in die Hilfe zum ping-Befehl zeigt mir, dass man als optionalen Parameter auch die VRF-Instanz angeben kann.
switch# ping -help
usage: ping {<host> | multicast <group>} [count <count>]
[packet-size <size>] [vrf <vrf>] [interval <interval] [df-bit]Ich passe meine Eingabe an und ergänze diese um den den Parameter VRF-Context.
switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.1
Repeat count [5] : 5
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.1
Timeout is 2 seconds, data pattern is 0xABCD
\n64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.298 ms
(...)
--- 192.168.1.1 ping statistics ---\n5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.156/0.195/0.298 ms
switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.3
Repeat count [5] :
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.3
Timeout is 2 seconds, data pattern is 0xABCD
\n64 bytes from 192.168.1.3: icmp_seq=0 ttl=127 time=0.659 ms
(...)Sowohl der Ping auf die lokale und die entfernte Schnittstellenadresse funktioniert. Es wurde einfach vergessen anzugeben von welcher Instanz der Ping abgesetzt werden soll. Die Kurzform für diesen Befehl wäre ping 192.168.1.3 vrf management.