BGP over GRE

I'm working on a INE Task in their workbook CCIE R&S workbook. The task is:

Configure R7 in AS 100.
Configure R8 in AS 200, with an EBGP peering to R10 in AS 54 using the password CISCO.Configure an EBGP peering between R7 and R8.
- R10 is preconfigured for this EBGP peering.
Advertise the Loopback0 networks of R7 and R8 into BGP.
Ensure that R7 and R8 can reach prefixes learned from AS 54 when sourcing traffic from their Loopback0 interfaces.
Do not redistribute between BGP and IGP to accomplish this.

When I configure the peerings with the following config:
R7:

router bgp 100
neighbor 155.1.58.8 remote-as 200
neighbor 155.1.58.8 ebgp-multihop 255
network 150.1.7.7 mask 255.255.255.255

R8:
router bgp 200
neighbor 155.1.67.7 remote-as 100
neighbor 155.1.67.7 ebgp-multihop 255
neighbor 155.1.108.10 remote-as 54
neighbor 155.1.108.10 password CISCO
network 150.1.8.8 mask 255.255.255.255

After I have done the config above, I have a peering with R8:
R7#sh bgp summ
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
155.1.58.8 4 200 138 133 13 0 0 01:57:40 11

When I look at the bgp route I'm getting from R8:

R7#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 155.1.58.8 0 200 54 i
*> 28.119.17.0/24 155.1.58.8 0 200 54 i
*> 112.0.0.0 155.1.58.8 0 200 54 50 60 i
*> 113.0.0.0 155.1.58.8 0 200 54 50 60 i
*> 114.0.0.0 155.1.58.8 0 200 54 i
*> 115.0.0.0 155.1.58.8 0 200 54 i
*> 116.0.0.0 155.1.58.8 0 200 54 i
*> 117.0.0.0 155.1.58.8 0 200 54 i
*> 118.0.0.0 155.1.58.8 0 200 54 i
*> 119.0.0.0 155.1.58.8 0 200 54 i
*> 150.1.7.7/32 0.0.0.0 0 32768 i
*> 150.1.8.8/32 155.1.58.8 0 0 200 i

I'm getting the 112.0.0.0 - 119.0.0.0 routes from R8 with a next hop of R8.

Now, when I try to ping 112.0.0.1 I get the following output:
R7#ping 112.0.0.1 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 112.0.0.1, timeout is 2 i not seconds:
Packet sent with a source address of 150.1.7.7
.....
Success rate is 0 percent (0/5)

Why an I not able to ping the 112.0.0.1 address from Lo0?

If I look on R8 the rouoing table shows this:
28.0.0.0/24 is subnetted, 2 subnets
B 28.119.16.0 [20/0] via 155.1.108.10, 01:02:25
B 28.119.17.0 [20/0] via 155.1.108.10, 01:02:25
B 112.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 113.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 114.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 115.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 116.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 117.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 118.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
B 119.0.0.0/8 [20/0] via 155.1.108.10, 01:02:25
150.1.0.0/32 is subnetted, 1 subnets
C 150.1.8.8 is directly connected, Loopback0
155.1.0.0/16 is variably subnetted, 15 subnets, 2 masks
D 155.1.0.0/24 [90/25881600] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
D 155.1.5.0/24 [90/307200] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
D 155.1.7.0/24 [90/384000] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
C 155.1.8.0/24 is directly connected, GigabitEthernet0/1.8
L 155.1.8.8/32 is directly connected, GigabitEthernet0/1.8
D 155.1.13.0/24 [90/358400] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
D 155.1.23.0/24 [90/384000] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
D 155.1.37.0/24 [90/384000] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
D 155.1.45.0/24 [90/307200] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
C 155.1.58.0/24 is directly connected, GigabitEthernet0/1.58
L 155.1.58.8/32 is directly connected, GigabitEthernet0/1.58
D 155.1.67.0/24 [90/358400] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
C 155.1.108.0/24 is directly connected, GigabitEthernet0/1.108
L 155.1.108.8/32 is directly connected, GigabitEthernet0/1.108
D 155.1.146.0/24 [90/332800] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58
R8#

I am able to ping R8 but not from the loopback. Why are the Loopbacks not seen in BGP?

What am I missing here?
To get it working INE also has the following config for R7 and R8:
R7 additional:
interface Tunnel0
ip address 10.0.0.7 255.255.255.0
tunnel source 155.1.67.7
tunnel destination 155.1.58.8

R8 additional:
interface Tunnel0
ip address 10.0.0.8 255.255.255.0
tunnel source 155.1.58.8
tunnel destination 155.1.67.7

route-map SET_NEXT_HOP_TO_TUNNEL_OUT permit 10
set ip next-hop 10.0.0.8

route-map SET_NEXT_HOP_TO_TUNNEL_IN permit 10
set ip next-hop 10.0.0.7

router bgp 200
neighbor 155.1.67.7 route-map SET_NEXT_HOP_TO_TUNNEL_OUT out
neighbor 155.1.67.7 route-map SET_NEXT_HOP_TO_TUNNEL_IN in

I want to know hwy the use of a GRE tunnel fixes the problem?

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

deth1k

Do all routers in the network know how to reach loopbacks of R7 and R8? Remember your IGP is unaware of them as per restrictions (do not redistribute).

P.S that is not loopback IP of R7

D 155.1.7.0/24 [90/384000] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58

Dieg0M

That's an EIGRP route and not a /32. Are you sure you are getting the loopback address from BGP? I'm guessing it's a BGP next hop problem and that is why they are changing it manually to go through a GRE tunnel.

FrankGuthrie

deth1k wrote: »

Do all routers in the network know how to reach loopbacks of R7 and R8? Remember your IGP is unaware of them as per restrictions (do not redistribute).

P.S that is not loopback IP of R7

D 155.1.7.0/24 [90/384000] via 155.1.58.5, 01:14:21, GigabitEthernet0/1.58

The loopback of R7 is 155.1.7.7, does that not fall in the range? And IF R8 and R7 have an BGP peering, why does it matter if the network is IN BGP or EIGRP. The routing will look in the routing table if it has a route to a destination regardless if it was learned from BGP of EIGRP, right?

Looking at the diagram:
R9 (AS 54) <--- BGP peering ---> R10 (AS 54) => IBGP
R10 (AS 54) <--- BGP peering ---> R8 (AS 200) => EBGP
R8 (AS200) <--- BGP peering ---> R7 (AS 100) => EBGP

R9 is originating the 112.0.0.0 - 119.0.0.0 routes:

R9#sh ip bgp
BGP table version is 12, local router ID is 212.18.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 28.119.16.0/24 155.1.109.10 0 100 0 i
*>i 28.119.17.0/24 155.1.109.10 0 100 0 i
*> 112.0.0.0 0.0.0.0 0 32768 i
*> 113.0.0.0 0.0.0.0 0 32768 i
*> 114.0.0.0 0.0.0.0 0 32768 i
*> 115.0.0.0 0.0.0.0 0 32768 i
*> 116.0.0.0 0.0.0.0 0 32768 i
*> 117.0.0.0 0.0.0.0 0 32768 i
*> 118.0.0.0 0.0.0.0 0 32768 i
*> 119.0.0.0 0.0.0.0 0 32768 i
*>i 150.1.8.8/32 155.1.109.10 0 100 0 200 i

You can see that because the next hop points to 0.0.0.0:

Looking on R10:
R10#sh ip bgp
BGP table version is 11, local router ID is 31.3.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 0.0.0.0 0 32768 i
*> 28.119.17.0/24 0.0.0.0 0 32768 i
*>i 112.0.0.0 155.1.109.9 0 100 0 i
*>i 113.0.0.0 155.1.109.9 0 100 0 i
*>i 114.0.0.0 155.1.109.9 0 100 0 i
*>i 115.0.0.0 155.1.109.9 0 100 0 i
*>i 116.0.0.0 155.1.109.9 0 100 0 i
*>i 117.0.0.0 155.1.109.9 0 100 0 i
*>i 118.0.0.0 155.1.109.9 0 100 0 i
*>i 119.0.0.0 155.1.109.9 0 100 0 i

The next hop is R9, which is correct. Look at R8:
R8#sh ip bgp
BGP table version is 12, local router ID is 150.1.8.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 155.1.108.10 0 0 54 i
*> 28.119.17.0/24 155.1.108.10 0 0 54 i
*> 112.0.0.0 155.1.108.10 0 54 50 60 i
*> 113.0.0.0 155.1.108.10 0 54 50 60 i
*> 114.0.0.0 155.1.108.10 0 54 i
*> 115.0.0.0 155.1.108.10 0 54 i
*> 116.0.0.0 155.1.108.10 0 54 i
*> 117.0.0.0 155.1.108.10 0 54 i
*> 118.0.0.0 155.1.108.10 0 54 i
*> 119.0.0.0 155.1.108.10 0 54 i
*> 150.1.8.8/32 0.0.0.0 0 32768 i

R8 point to R10, which is correct.

If I look on R7:
R7#sh ip bgp
BGP table version is 13, local router ID is 150.1.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 155.1.58.8 0 200 54 i
*> 28.119.17.0/24 155.1.58.8 0 200 54 i
*> 112.0.0.0 155.1.58.8 0 200 54 50 60 i
*> 113.0.0.0 155.1.58.8 0 200 54 50 60 i
*> 114.0.0.0 155.1.58.8 0 200 54 i
*> 115.0.0.0 155.1.58.8 0 200 54 i
*> 116.0.0.0 155.1.58.8 0 200 54 i
*> 117.0.0.0 155.1.58.8 0 200 54 i
*> 118.0.0.0 155.1.58.8 0 200 54 i
*> 119.0.0.0 155.1.58.8 0 200 54 i
*> 150.1.7.7/32 0.0.0.0 0 32768 i
*> 150.1.8.8/32 155.1.58.8 0 0 200 i

So R7 is able to get the routes, but not ping them. Ot me this is strange, because when I loop in the routing table:
R7#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

28.0.0.0/24 is subnetted, 2 subnets
B 28.119.16.0 [20/0] via 155.1.58.8, 23:04:18
B 28.119.17.0 [20/0] via 155.1.58.8, 23:04:18
B 112.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 113.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 114.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 115.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 116.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 117.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 118.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18
B 119.0.0.0/8 [20/0] via 155.1.58.8, 23:04:18

It states the next-hop is R8. If I ping R8:
R7#ping 155.1.58.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.58.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms
R7#

See R7 has reachability, but not via the loopback
R7#ping 155.1.58.8 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.58.8, timeout is 2 seconds:
Packet sent with a source address of 150.1.7.7
.....
Success rate is 0 percent (0/5)

So R8 probably doesn't have a way back it seems:
R8#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

28.0.0.0/24 is subnetted, 2 subnets
B 28.119.16.0 [20/0] via 155.1.108.10, 1d00h
B 28.119.17.0 [20/0] via 155.1.108.10, 1d00h
B 112.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 113.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 114.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 115.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 116.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 117.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 118.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
B 119.0.0.0/8 [20/0] via 155.1.108.10, 1d00h
150.1.0.0/32 is subnetted, 1 subnets
C 150.1.8.8 is directly connected, Loopback0
155.1.0.0/16 is variably subnetted, 15 subnets, 2 masks
D 155.1.0.0/24 [90/25881600] via 155.1.58.5, 1d00h, Ethernet0/1.58
D 155.1.5.0/24 [90/307200] via 155.1.58.5, 1d00h, Ethernet0/1.58
D 155.1.7.0/24 [90/384000] via 155.1.58.5, 1d00h, Ethernet0/1.58
C 155.1.8.0/24 is directly connected, Ethernet0/1.8
L 155.1.8.8/32 is directly connected, Ethernet0/1.8
D 155.1.13.0/24 [90/358400] via 155.1.58.5, 1d00h, Ethernet0/1.58
D 155.1.23.0/24 [90/384000] via 155.1.58.5, 1d00h, Ethernet0/1.58
D 155.1.37.0/24 [90/384000] via 155.1.58.5, 1d00h, Ethernet0/1.58
D 155.1.45.0/24 [90/307200] via 155.1.58.5, 1d00h, Ethernet0/1.58
C 155.1.58.0/24 is directly connected, Ethernet0/1.58
L 155.1.58.8/32 is directly connected, Ethernet0/1.58
D 155.1.67.0/24 [90/358400] via 155.1.58.5, 1d00h, Ethernet0/1.58
C 155.1.108.0/24 is directly connected, Ethernet0/1.108
L 155.1.108.8/32 is directly connected, Ethernet0/1.108
D 155.1.146.0/24 [90/332800] via 155.1.58.5, 1d00h, Ethernet0/1.58

This seems to be correct if you look at R8's routing table...Why is R8 not getting R7's loopback. If I look in the BGP config for R7:
router bgp 100
bgp log-neighbor-changes
network 150.1.7.7 mask 255.255.255.255
neighbor 155.1.58.8 remote-as 200
neighbor 155.1.58.8 ebgp-multihop 255

R7 is advertising it's loopback and so is R8:
R8#sh run | sec bgp
router bgp 200
bgp log-neighbor-changes
network 150.1.8.8 mask 255.255.255.255
neighbor 155.1.67.7 remote-as 100
neighbor 155.1.67.7 ebgp-multihop 255
neighbor 155.1.108.10 remote-as 54
neighbor 155.1.108.10 password CISCO

So why don't they lear each others loopback... They're peering whith eachtoher using BGP... What Am I missing here. Again, INE uses a GRE tunnel, so that will solve it, but I'm trying to understand what is it solves....

fredrikjj

I fired up VIRL with the correct topology (you are using the "BGP over GRE" config I hope?) and did the lab. As deth1k suggests, the issue that you are trying to solve is that the routers do not know other router's loopback addresses since they are not advertised in the IGP. A packet with a destination address of 150.1.7.7 (R7's loopback) or 150.1.8.8 (R8's loopback) will never reach the destination due to the packet being blackholed.

I put a GRE tunnel between R7 and R8 and then peered BGP using the tunnel's addresses. The advantage of this is that you don't have to mess around with the next hops to get the packets into the GRE tunnel. The workbook solution seems to be to peer between the transport addresses and then adjusts the BGP next hop with a route map to match the GRE tunnel destination address. The workbook also points out that you can peer directly over the tunnel.

R7:

interface Tunnel0
 ip address 10.1.78.7 255.255.255.0
 tunnel source 155.1.67.7
 tunnel destination 155.1.58.8

router bgp 100
 bgp log-neighbor-changes
 network 150.1.7.7 mask 255.255.255.255
 neighbor 10.1.78.8 remote-as 200

R8:

interface Tunnel0
 ip address 10.1.78.8 255.255.255.0
 tunnel source 155.1.58.8
 tunnel destination 155.1.67.7

router bgp 200
 bgp log-neighbor-changes
 network 150.1.8.8 mask 255.255.255.255
 neighbor 10.1.78.7 remote-as 100
 neighbor 155.1.108.10 remote-as 54
 neighbor 155.1.108.10 password CISCO

I don't know exactly what mistakes you have made, but looking at your routing tables, it seems that you have failed to account for the next hop issues that you can run into. Like the workbook mentions, you're basically running the equivalent of an MPLS VPN service with a "BGP free core", except using only IP/GRE. The "PE routers" R7/R8 know routes that the transport network between them doesn't know, and you must therefore use some kind of encapsulation.

deth1k

FrankGuthrie loopback is 150.1.7.7/32 and not 155.1.7.0/24 ... I think you need to look at the diagram again.

_Gonzalo_

Dieg0M wrote: »

Are you sure you are getting the loopback address from BGP? I'm guessing it's a BGP next hop problem and that is why they are changing it manually to go through a GRE tunnel.

To OP: reread this comment. With the information that you provided, it makes a lot of sense.

FrankGuthrie

I made an error in thinking. The Routers between R7 and R8 are not running BGP. So they don't have a route to 112.0.0.0 - 119.0.0.0. By using GRE they don't need to be aware of the 112.0.0.0 - 119.0.0.0 routes.

Thanks for the help.

_Gonzalo_

FrankGuthrie wrote: »

I made an error in thinking.

Those are the best. I´d rather take one of those than one "in not thinking"!:)