BGP over GRE

FrankGuthrieFrankGuthrie Member Posts: 245
in CCIE
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




BGPoverGRE.png


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?
· Share on FacebookShare on Twitter

Comments

  • deth1kdeth1k Member Posts: 312
    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
    · Share on FacebookShare on Twitter
  • Dieg0MDieg0M Member Posts: 861
    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.
    Follow my CCDE journey at www.routingnull0.com
    · Share on FacebookShare on Twitter
  • FrankGuthrieFrankGuthrie Member Posts: 245
    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....
    · Share on FacebookShare on Twitter
  • fredrikjjfredrikjj Member Posts: 879
    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.
    · Share on FacebookShare on Twitter
  • deth1kdeth1k Member Posts: 312
    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.
    · Share on FacebookShare on Twitter
  • _Gonzalo__Gonzalo_ Member Posts: 113
    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.
    · Share on FacebookShare on Twitter
  • FrankGuthrieFrankGuthrie Member Posts: 245
    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.
    · Share on FacebookShare on Twitter
  • _Gonzalo__Gonzalo_ Member Posts: 113
    FrankGuthrie wrote: »
    I made an error in thinking.

    Those are the best. I´d rather take one of those than one "in not thinking"!:)
    · Share on FacebookShare on Twitter
Sign In or Register to comment.