Verifying GRP Tunnels
As usual I’ll start with my favorite troubleshooting command, show ip interface brief .
Corp# sh ip int brief
Interface IP-Address OK? Method Status
FastEthernet0/0 10.10.10.5 YES manual up
Serial0/0 22.214.171.124 YES manual up
FastEthernet0/1 unassigned YES unset administratively down
Serial0/1 unassigned YES unset administratively down
Tunnel0 192.168.10.1 YES manual up
In this output, you can see that the tunnel interface is now showing as an interface on my router. You can see the IP address of the tunnel interface, and the Physical and Data Link status show as up/up. So far so good. Let’s take a look at the interface with the show interfaces tunnel 0 command.
Corp# sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.10.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL , loopback not set
Keepalive not set
Tunnel source 126.96.36.199, destination 188.8.131.52
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
The show interfaces command shows the configuration settings and the interface status as well as the IP address, tunnel source, and destination address. The output also shows the tunnel protocol, which
is GRE/IP. Last, let’s take a look at the routing table with the show ip route command.
Corp# sh ip route
192.168.10.0/24 is subnetted, 2 subnets
C 192.168.10.0/24 is directly connected, Tunnel0
L 192.168.10.1/32 is directly connected, Tunnel0
184.108.40.206/30 is subnetted, 2 subnets
C 220.127.116.11 is directly connected, Serial0/0
L 18.104.22.168/32 is directly connected, Serial0/0
The tunnel0 interface shows up as a directly connected interface, and although it’s a logical interface, the router treats it as a physical interface, just like serial 0/0 in the routing table.
Corp# ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2
Success rate is 100 percent (5/5)
Did you notice that I just pinged 192.168.10.2 across the Internet? I hope so! Anyway, there’s one last thing I want to cover before we move on to EBGP, and that’s troubleshooting an output, which is showing a tunnel routing error. If you configure your GRE tunnel and receive this GRE flapping message
Line protocol on Interface Tunnel0, changed state to up
Tunnel0 temporarily disabled due to recursive routing
Line protocol on Interface Tunnel0, changed state to
it means that you’ve misconfigured your tunnel, which will cause your router to try and route to the tunnel destination address using th e tunnel interface itself!
The Border Gateway Protocol (BGP) is perhaps one of the most well- known routing protocols in the world of networking. This is understandable because BGP is the routing protocol that powers the Internet and makes possible what we take for granted: connecting to remote systems on the other side of the country or planet. Because of its pervasive use, it’s likely that each of us will have to deal with it at some point in our careers. So it’s appropriate that we spend some time learning about BGP.
BGP version 4 has a long and storied history. Although the most recent definition was published in 1995 as RFC 1771 by Rekhter and Li, BGP’s
roots can be traced back to RFCs 827 and 904, which specified a protocol called the exterior gateway protocol (EGP). These earlier specifications date from 1982 and 1984, respectively—ages ago! Although BGP obsoletes EGP, it uses many of the techniques fir st defined by EGP and draws upon the many lessons learned from its use.
Way back in 1982, many organizations were connected to the ARPAnet, the noncommercial predecessor of the Internet. When a new network was added to ARPAnet, it would typically be added in a relatively unstructured way and would begin participating in a
common routing protocol, the Gateway to Gateway Protocol (GGP). As you might expect, this solution did not scale well. GGP suffered from excessive overhead in managing large routing tables and from the difficulty of troubleshooting in an environment in which there was no central administrative control.
To address these deficiencies, EGP was developed, and with it the concept of autonomous systems (ASs) . RFC 827 was very clear in laying out the problems with GGP and in pointing out that a new type of routing protocol was required, an exterior gateway protocol (EGP) . The purpose of this new protocol was to facilitate the flow of traffic among a series of autonomous systems by exchanging information about routes contained in each system. The complexities of this network of networks, the Internet, would be hidden from the end user contains a
Comparison of BGP and OSPF who simply views the Internet as a single address space through which they travel, unaware of the exact path they take.
The BGP that we know today flows directly from this work on EGP and builds upon it. So that you can get a better understanding of BGP, I
will provide an overview of its features next.