reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec)
Tunnel source 11.11.11.11 (Ethernet0), destination 9.9.9.9
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled
Last input 00:16:42, output 00:17:40, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 5 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
118 packets input, 19144 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
164 packets output, 49624 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Verify that the tunnel works is to ping the tunnel destination IP address. This will verify IP connectivity only,
not the actual functioning of the tunnel.
From ubr924−ddd5 we ping 11.11.11.11
ubr924−ddd5#ping 11.11.11.11
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round−trip min/avg/max = 12/14/17 ms
ubr924−ddd5#
Ping from ubr924−b5db the destination address 9.9.9.9.
ubr924−b5db#ping 9.9.9.9
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round−trip min/avg/max = 12/14/16 ms
ubr924−b5db#
To verify that the tunnel works, issue the show ip route x.x.x.x command, where x.x.x.x is the IP address
assigned to the far end of the tunnel. In this case, it would be the loop−back address of the far router. If the
only route shown is to the tunnel interface, a ping to that address will prove that the tunnel works.
If there is an IP addressing scheme that advertises routes to the tunnel segment back across the network, there
would be more than one route to the far end of the tunnel interface. If that is the case, it is very difficult to
verify that the tunnel is working. Typically in this situation, you do not want duplicate routes to the tunnel
network. Steps should be taken to prevent the advertisement of the routes by a routing protocol across the
network. If the tunnel is being used to transport traffic of a different protocol from IP, the same basic
verification method applies.
From ubr924−ddd5 we get
ubr924−ddd5#show ip route 192.168.20.2
Routing entry for 192.168.20.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
From ubr924−b5db we get
Kommentare zu diesen Handbüchern