To implement BGP over GRE , the topology shown above. In topology R1 & R3 running BGP 100 whereas R2 running only IGP.R1-R4 & R3-R5 running ebgp and advertising prefix 220.127.116.11 and 18.104.22.168 respectively.
R1-R2-R3 running ospf under area 0.
Bgp over GRE can be configured in scenario where end to end BGP is not running or where we want to bypass non bgp peer to peering with BGP peer.
Want to switch to summary first
Till now we did basic configuration and bgp peering , Lets check if R4 and R5 advertising any routes to its upstream or not.
Its seems R4 and R5 both advertising the routes towards R1 and R3 , but R1 not learning R5 routes via R1 as best , same for R3.Let check the cause in debug ip bgp update.As per R1 there is no valid path for 22.214.171.124 thus the prefixes not learning as best path. This is due to BGP synchronization enabled on R1 and R3
The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP.
Here R3/R1 should not send the route 126.96.36.199/188.8.131.52 to its downstream unless that routes has been learned by IGP also. Let’s see if we are learning routes for 184.108.40.206/220.127.116.11 from IGP.BGP synchronization rule has been introduced to avoid loop. Now most routers have bgp synchronization comes with synchronization disabled. Let’s disable bgp synchronization manually here.
Once you disable bgp sync you have to hard reset the bgp peer.Great!! .Now we learning 18.104.22.168/22.214.171.124 as best routes into bgp table. Till now we have configured basic IGP , BGP and disabled Synchronization on transit R1/R3 router.
Let’s check If we are learning routes on R4/R5 also.
All seems fine, lets ping 126.96.36.199 from R5.We are not able to ping end host, this is because when packet reaching to R2 its getting blackhole.
When packet arrive at R2 , R2 dropping the packet since it’s not aware about 188.8.131.52.
R2 is not able about 184.108.40.206 & 220.127.116.11 since these routes learning via BGP and R2 running only IGP.
What is the solution to avoid this black hole. ??
1)Run BGP on R2.
2)Redistribute BGP into IGP.
3)Run BGP over GRE tunnel.
Due to some reason we cannot run BGP on R2, let say it is not capable of handling bgp protocol, we can redistribute bgp into IGP, but this is not recommended, and cause loop or can be hazardous in some situation. The easiest solution to create GRE tunnel and run BGP over that.
GRE Over BGP Configuration
Create GRE tunnel on R1 and R2 , with tunnel source/destination as R1/R3 loopback addresses.
The very first requirement of GRE tunnel is to check the IP reach-ability between tunnel source/destination.
Now lets ping 18.104.22.168 from R4 again if now its pingingStill we are not able to reach remote host, let’s check on R1/R3.So the problem here is we created GRE tunnel but our traffic is not going through tunnel instead it going via the same physical interface. We need to force inbound/outbound traffic to be diverted via tunnel interface, then our traffic will be encapsulated into GRE
Note: R2 or IGP cannot see the traffic encapsulated under GRE and forward it to further considering a normal IP packets.
Let’s create route map on R1/R3 for changing the next hop.Apply these route-map towards bgp peer R1/R3 and hard reset bgp peer.Now the next hop for routes 22.214.171.124/126.96.36.199 has been changed with the tunnel IP.
Let’s ping now 188.8.131.52 from 184.108.40.206.Now both end can ping each other.
Let’s inspect the Packet to know what happening behind the scene. Capture packet on R1 f0/1 and R3 F0/1.
R1 encapsulating the prefix 220.127.116.11/18.104.22.168 under GRE packet. From IP type 47, it shows its carrying GRE packet with it.
GRE protocol type 0x0800 specify that GRE carrying IP information within it.
Further IP packet inside GRE carry protocol type 1 , which means its carrying ICMP info with its.
And Finally ICMP packet carry Type which is 8 for ICMP request.
Packet capture on R1:F0/1
R2 will only check IP header with source and destination 22.214.171.124& 126.96.36.199 , and do not inspect the inside GRE encapsulated traffic. On R3 It will de encapsulate the GRE packet and send the plane IP to R5.
Packet capture on R3: f0/0