Showing posts with label GRE Tunnel. Show all posts
Showing posts with label GRE Tunnel. Show all posts

Tuesday, September 29, 2009

GRE Tunnels Never Down



Generic Routing Encapsulation aka GRE was originally developed by Cisco. In the recent stages, it was developed to transport packets from one network to another. As the time grows, it became a part of VPN. It is used to route non routeable packets from the IP backbones. GRE mechanism is used by various protocols to encapsulate the packet like PPTP uses GRE encapsulation for establishing tunnel and Rosen draft is fully based on GRE to provide Multicast Over VPN (MVPN) services in MPLS cloud.
GRE tunnels are completely stateless because of that, it doesn't contains the information of the remote end peer.During the creation of interface tunnel, we need to specify the valid source address or interface and destination address. Assume the remote end tunnel creation process is not in place but still the line protocol of tunnel is up which was created at one end. So it means, GRE has nothing to do with the remote destination address reachability. Due to this feature, GRE tunnel never bring down in case of remote failure or remote tunnel absence which leads lot of problems of flushing routes from the routing table. The problem was overcome by using GRE tunnel keepalives.
A decade or two decades ago, GRE was used for serving VPN to the customers. During that time, SP provide GRE connectivity among the remote sites of the customers. For complete traffic forwarding, a routeable IP address was extended from PE to CE and on the basics of that IP address a GRE tunnel was established. The main disadvantage of this model is that customers require (n*n-1)/2 tunnels for full mesh which was really a cumbersome one. This was overridden by MPLS because it provides full mesh by default.

Click Here To Read Rest Of The Post...

Thursday, July 9, 2009

MTI Tunnel In GSR



In GSR MTI tunnel will not come up until and unless customer initiated multicast traffic.

Click Here To Read Rest Of The Post...

Thursday, February 12, 2009

GRE Keepalives

2 years back When I was entered in service provider domain, the first I learned how to create GRE tunnel and keepalive is the mandid to get the tunnnel work properly. During googling I found a good document of cisco which is exlicitly defining the keepalive working.

Two routers R1 -> R2 are connected back to back.

When you enable keepalives on the tunnel endpoint of Router A, the router at every interval constructs the inner IP header. At the end of the header, the router also appends a GRE header with a Protocol Type (PT) of 0, and no other payload. The router then sends that packet through the tunnel, which results in its encapsulation with the outer IP header, and a GRE header with the PT of IP. The tunnel keepalive counter increments by one. If there is a way to reach the far end tunnel endpoint, and the tunnel line protocol is not down due to other reasons, the packet arrives on Router B. It is then matched against Tunnel 0, is
decapsulated, and forwarded to the destination IP, which is the tunnel source, Router A. Upon arrival on Router A, the packet is again decapsulated, and the PT is checked. If the result of the PT check is 0, it signifies that this is a keepalive packet. In such a case, the tunnel keepalive counter is reset to 0, and the packet is discarded. In case Router B is unreachable, Router A continues to construct and send the keepalive packets along with
normal traffic. If the line protocol is down, the keepalives do not come back to Router A. Therefore, the keepalive counter continues to increase. The tunnel line protocol stays up only as long as the tunnel keepalive counter remains zero, or less than a configured value. If that condition is not true, the next time you attempt to send a keepalive to Router B, the line protocol is brought down, as soon as the keepalive counter reaches the configured keepalive value. In the up/down state, the tunnel does not forward or process any traffic apart from the keepalive packets. For this to work for keepalive packets only, the tunnel must be forward-and-receive friendly. So the tunnel lookup algorithm must be successful in all cases, and must discard only the data packets if the line protocol is down. When a keepalive packet is received, it implies that the tunnel endpoint is again reachable. The tunnel keepalive counter is then reset to 0, and the line protocol comes back up.

regards
shivlu jain
Click Here To Read Rest Of The Post...