Lab 7 - BGP over GRE

Understanding how BGP operates over tunneling technology such as GRE tunnels can be helpful when studying more advanced concepts like MPLS. This lab hopes to help reinforce some of those basic concepts before we move on into those more advanced topics.

Concepts covered:

-eBGP peering

-Configuring GRE tunnels

-Modifying BGP next-hop parameters

-eBGP multi-hop

-BGP routing over non BGP clouds

Topology used

Tasks to complete this lab

-Establish eBGP peering between R1 and PE10

-Establish eBGP peering between R3 and PE20

-Establish eBGP peering between R1 and R3

-Advertise the loopback address of R1 and R3 into BGP

-Ensure R1 can reach the loopback address of PE20 and R3 can reach the loopback of PE10 when sourcing packets from their respective loopback interfaces

Constraints

-Use the subnet 99.9.9.0/24 for any tunnel interfaces

-Do not modify the IGP configuration

-Do not redistribute any addresses into the IGP

-Do not modify the configuration on PE10 and PE20

-Do not modify any configuration on R2

GNS3 lab files: link

Solution

Though there are alternative solutions to the approach I use, this one provides a better learning opportunity then some of the other options which I will mention at the end of the blog.

Let's begin by configuring our eBGP peering

R1(config-router)#router bgp 100

R1(config)#neighbor 192.168.1.10 remote-as 10

R1(config)#neighbor 192.168.3.3 remote-as 200

R1(config)#neighbor 192.168.3.3 ebgp-multihop 255

R3(config-router)#router bgp 100

R3(config)#neighbor 192.168.4.20 remote-as 20

R3(config)#neighbor 192.168.2.1 remote-as 100

R3(config)#neighbor 192.168.2.1 ebgp-multihop 255

With the eBGP peering established we move on to the next task which is to redistribute R1 and R2's loopback addresses

R1(config)#access-list 1 permit 1.1.1.1

R1(config)#route-map LOOPBACK_0 permit 10

R1(config-route-map)#match ip address 1

R1(config)#router bgp 100

R1(config-router)#redistribute connected route-map LOOPBACK_0

R3(config)#access-list 1 permit 3.3.3.3

R3(config)#route-map LOOPBACK_0 permit 10

R3(config-route-map)#match ip address 1

R3(config)#router bgp 200

R3(config-router)#redistribute connected route-map LOOPBACK_0

A network statement above would have also worked but I like to make things a little more complicated to keep my acl/route-map skills up.

So at this point we should see the loopback networks on PE10 and PE20.

PE10#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.1.1              0             0 100 ?

 *>  3.3.3.3/32       192.168.1.1                            0 100 200 ?

 *>  10.10.10.10/32   0.0.0.0                  0         32768 i

 *>  20.20.20.20/32   192.168.1.1                            0 100 200 20 i

PE20#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.4.3                            0 200 100 ?

 *>  3.3.3.3/32       192.168.4.3              0             0 200 ?

 *>  10.10.10.10/32   192.168.4.3                            0 200 100 10 i

 *>  20.20.20.20/32   0.0.0.0                  0         32768 i

And we do, so what do these prefixes look like on their peers R1 and R3

R1#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       0.0.0.0                  0         32768 ?

 *>  3.3.3.3/32       192.168.3.3              0             0 200 ?

 *>  10.10.10.10/32   192.168.1.10             0             0 10 i

 *>  20.20.20.20/32   192.168.3.3                              0 200 20 i

R3#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.2.1              0             0 100 ?

 *>  3.3.3.3/32       0.0.0.0                  0         32768 ?

 *>  10.10.10.10/32   192.168.2.1                               0 100 10 i

 *>  20.20.20.20/32   192.168.4.20             0             0 20 i

OK, let's see if we can ping these networks source from the loopbacks on R1 and R3.

R1#ping 20.20.20.20 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

…..

Success rate is 0 percent (0/5)

R3#ping 10.10.10.10 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

.....

Success rate is 0 percent (0/5)

Well that is not good. The reason we cannot ping these addresses is because R2 has no knowledge of these networks.

R2#sh ip route

<snip>

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets

O        1.1.1.1 [110/2] via 192.168.2.1, 01:01:45, FastEthernet0/0

      2.0.0.0/32 is subnetted, 1 subnets

C        2.2.2.2 is directly connected, Loopback0

      3.0.0.0/32 is subnetted, 1 subnets

O        3.3.3.3 [110/2] via 192.168.3.3, 01:01:31, FastEthernet0/1

      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.2.0/24 is directly connected, FastEthernet0/0

L        192.168.2.2/32 is directly connected, FastEthernet0/0

      192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.3.0/24 is directly connected, FastEthernet0/1

L        192.168.3.2/32 is directly connected, FastEthernet0/1

Since we cannot modify R2 in any way or redistribute into IGP we are going to have to use the routing table on R2 as it exists. That means if we can tunnel the packets through R2 then we can solve our problem.

This requires essentially two steps, first create a GRE tunnel then modify the next-hop attributes on the BGP prefixes so that traffic for those prefixes go over the tunnel.

Let's start with creating the tunnels

R1(config)#interface Tunnel0

R1(config-if)#ip address 99.9.9.1 255.255.255.0

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360

R1(config-if)#tunnel source FastEthernet0/1

R1(config-if)#tunnel destination 192.168.3.3

R1(config)#interface Tunnel0

R1(config-if)#ip address 99.9.9.3 255.255.255.0

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360

R1(config-if)#tunnel source FastEthernet0/0

R1(config-if)#tunnel destination 192.168.2.1

Next we identify the traffic we want to modify  and then modify the next-hop attribute using a route-map

R1(config)#route-map CHANGE_NEXT_HOP permit 10

R1(config-route-map)# match as-path 1

R1(config-route-map)# set ip next-hop 99.9.9.1

R1(config-route-map)#route-map CHANGE_NEXT_HOP permit 999

R1(config-route-map)#exit

R3(config)#route-map CHANGE_NEXT_HOP permit 10

R3(config-route-map)# match as-path 1

R3(config-route-map)# set ip next-hop 99.9.9.3

R3(config-route-map)#route-map CHANGE_NEXT_HOP permit 999

R3(config-route-map)#exit

Now let's ping our IP addresses again and see the results

R1#ping 20.20.20.20 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 48/72/84 ms

R3#ping 10.10.10.10 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/97/120 ms

Success!

Keep in mind that there are several ways to approach solving this issue. Another approach could have been to simply establish the eBGP peering between R1 and R3 using the tunnel interfaces. This would have accomplish essentially the same thing because the next-hop address for the advertised prefixes would have been the update source address which is the tunnel interface. Another option could be use policy based routing to modify the next hop.