Internal BGP Configuration

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot bgp_ibgp/bgp_ibgp_setup.robot

Internal BGP Peering

In the last module we have configured a BGP peering to a router in another autonomous systems. We now want to configure a BGP peering to a router in the same autonomous system and learn how internal and external BGP peerings differ. We use the following setup:

ibgp lab
Figure 1. Internal BGP Lab Setup

One of the main differences between internal BGP and external BGP is, that in general there is no IGP running between external peers which implies that the BGP peering is setup on interface IP addresses. In contrast, within an autonomous system there is an IGP (e.g., OSPF or IS-IS) running. As BGP peerings are based on TCP sessions, internal BGP peering are setup based on IP addresses of loopback interfaces for the sake of reliability.

Exercise 1: BGP Peer Configuration

Configure BGP peering to R2, R3, and ISP according to the following table:

Peer Peer Group Peer Address Peer AS Address Family

R2

Internal

192.168.0.2

64500

IPv4/IPv6 Unicast

R3

Internal

192.168.0.3

64500

IPv4/IPv6 Unicast

R4

Internal

192.168.0.4

64500

IPv4/IPv6 Unicast

ISP

AS64501

192.168.1.2

65100

IPv4/IPv6 Unicast
Click to reveal the answer 
cfg> set instance default protocol bgp hostname R1
cfg> set instance default protocol bgp local-as 64500
cfg> set instance default protocol bgp router-id 192.168.0.1
cfg> set instance default protocol bgp address-family ipv4 unicast
cfg> set instance default protocol bgp address-family ipv6 unicast
cfg> set instance default protocol bgp peer-group AS64501 remote-as 64501
cfg> set instance default protocol bgp peer-group AS64501 address-family ipv4 unicast
cfg> set instance default protocol bgp peer-group AS64501 address-family ipv6 unicast
cfg> set instance default protocol bgp peer ipv4 192.168.1.2 192.168.1.1 peer-group AS64501
cfg> set instance default protocol bgp peer-group Internal remote-as 64500
cfg> set instance default protocol bgp peer-group Internal address-family ipv4 unicast
cfg> set instance default protocol bgp peer-group Internal address-family ipv6 unicast
cfg> set instance default protocol bgp peer ipv4 192.168.0.2 192.168.0.1 peer-group Internal
cfg> set instance default protocol bgp peer ipv4 192.168.0.3 192.168.0.1 peer-group Internal
cfg> set instance default protocol bgp peer ipv4 192.168.0.4 192.168.0.1 peer-group Internal
cfg> commit
cfg> show bgp peer
Instance: default
  Peer                                     Remote AS    State         Up/Down Time               PfxRcvd              PfxSent
  R2                                       64500        Established   0d:00h:04m:18s             1                    4
  R3                                       64500        Established   0d:00h:04m:25s             1                    4
  R4                                       64500        Established   0d:00h:04m:21s             0                    4
  ISP                                      64501        Established   0d:00h:00m:46s             4                    6

Difference between iBGP and eBGP

There are only a couple of prefixes learned, so let’s analyze them. First, we look at the prefixes we have received from an external peer (here R4) and how they are sent to an internal peer (e.g., R2):

cfg> show bgp rib-in ipv4 unicast peer ISP
Flags: & - Imported, ! - Error, N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Hostname: ISP, Peer IP: 192.168.1.2
  Source IP: 192.168.1.1, Total routes: 2
    Prefix                                       Next Hop                           MED         Lpref       AS Path
    172.16.100.0/24                              192.168.1.2                        0           -           64501
    192.168.0.100/32                             192.168.1.2                        0           -           64501
cfg> show bgp rib-out ipv4 unicast peer R2
Flags: N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R2, Peer IP: 192.168.0.2, Sent routes: 2
    Flags  Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
           172.16.100.0/24                               0       100        Incomplete      192.168.1.2                              64501
           192.168.0.100/32                              0       100        Incomplete      192.168.1.2                              64501
A BGP speaker advertises prefixes learned from an external BGP peer to an internal BGP. The nexthop attributes remains unchanged.

The problem is that the BGP nexthop for the routes learned from R4 is the IP address of the directly connected interface between R1 and R4. As there is no IGP running on this interface, the internal BGP neighbors won’t be able to resolve this nexthop. There are two possible solutions:

  • Distribute the nexthop via IGP (e.g., redistribution or passive interface)

  • Rewrite the nexthop before sending update to iBGP peer

The best practice is to rewrite the nexthop to a local address that is known in the IGP, such as the router’s loopback address. This can be achieved either via the update-next-hop or the nexthop-self option in the peer-group configuration. The first one is flexible, while the second one only allows to set the nexthop to the advertising router’s end of the BGP session; since IBGP is typically established between loopback interfaces, nexthop-self will set the next-hop to the loopback address of the advertising router.

Exercise 2: BGP Nexthop Setting

Configure for the peer-group Internal for both address-families the nexthop to be updated to 192.168.0.1.

Click to reveal the answer 
cfg> set instance default protocol bgp peer-group Internal address-family ipv4 unicast update-nexthop ipv4-address 192.168.0.1
cfg> set instance default protocol bgp peer-group Internal address-family ipv6 unicast update-nexthop ipv4-address 192.168.0.1
cfg> commit
cfg> show bgp rib-out ipv4 unicast peer R2
Flags: N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R2, Peer IP: 192.168.0.2, Sent routes: 2
    Flags  Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
           172.16.100.0/24                               0       100        Incomplete      192.168.0.1                              64501
           192.168.0.100/32                              0       100        Incomplete      192.168.0.1                              64501

From the output, we can also see that the local preference of 100 is attached to the prefixes sent to internal peers as a default. Modifying local preference values is best done via routing policies, but it is possible to change the default setting for the whole BGP protocol within an instance:

cfg> set instance default protocol bgp local-preference 150
cfg> commit

Now let’s look at the opposite direction and see how prefixes learned from internal peers are sent to external peers:

cfg> show bgp rib-in ipv4 unicast peer R2
Flags: & - Imported, ! - Error, N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Hostname: R2, Peer IP: 192.168.0.2
  Source IP: 192.168.0.1, Total routes: 1
    Prefix                                       Next Hop                           MED         Lpref       AS Path
    172.16.123.64/26                             192.168.0.2                        -           100
cfg>  show bgp rib-out ipv4 unicast peer ISP
Flags: N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: ISP, Peer IP: 192.168.1.2, Sent routes: 4
    Flags  Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
           172.16.100.0/24                               0       -          Incomplete      192.168.1.1                              64500, 64501
           172.16.123.0/26                               0       -          Incomplete      192.168.1.1                              64500
           172.16.123.64/26                              0       -          Incomplete      192.168.1.1                              64500
           192.168.0.100/32                              0       -          Incomplete      192.168.1.1                              64500, 64501
A BGP speaker advertises prefixes learned from an internal BGP peer to an external BGP. The BGP AS_PATH attributed is prepended with the local AS number and the nexthop attributes is updated.

We also see that a MED value of 0 is assigned to the prefix. This default value can be modified within the BGP protocol:

cfg> set instance default protocol bgp med 50
cfg> commit

An interesting aspect of internal BGP can be seen if we compare the prefixes learned from R2 and the prefixes sent to R3:

cfg> show bgp rib-in ipv4 unicast peer R2
Instance: default, AFI: ipv4, SAFI: unicast
 Hostname: R2, Peer IP: 192.168.0.2, Source IP: 192.168.0.1, Received routes: 1
    Prefix                    Next Hop                            MED        Local Preference  AS Path    Status
    172.16.123.64/26          192.168.0.2                         -          100               -          Valid
cfg> show bgp rib-out ipv4 unicast peer R3
Flags: N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R3, Peer IP: 192.168.0.3, Sent routes: 2
    Flags  Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
           172.16.100.0/24                               0       150        Incomplete      192.168.0.1                              64501
           192.168.0.100/32                              0       150        Incomplete      192.168.0.1                              64501
A BGP speaker does not advertise IP prefixes it has learned from an iBGP peer to another iBGP peer.

This rule is very important to know. The main reason for this behavior is that BGP uses AS_PATH for loop prevention and within an autonomous system, AS_PATH is not updated. We will deal with the impact in the next module.

Exercise 3: BGP Redistribution

By default, a BGP speaker only advertises prefixes to neighbors which it has learned from other neighbors. In order to make AS64500 reachable to the outside world, you need to bring the internal networks into BGP. Create a static route summarizing the loopback addresses (192.168.0.1-3) and redistribute it into BGP.

Click to reveal the answer 
cfg> set instance default static nexthop-profile NULL exit-interface null0
cfg> set instance default static route ipv4 192.168.0.0/30 unicast NULL
cfg> set instance default static route ipv6 fc00:c0a8::192:168:0:0/126 unicast NULL
cfg> set instance default protocol bgp address-family ipv4 unicast redistribute static
cfg> set instance default protocol bgp address-family ipv6 unicast redistribute static
cfg> commit
cfg> show bgp rib-out ipv4 unicast peer ISP
Flags: N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: ISP, Peer IP: 192.168.1.2, Sent routes: 5
    Flags  Prefix                                        MED     Lpref      Origin          Next Hop                                 AS Path
           192.168.0.0/30                                50      -          Incomplete      192.168.1.1                              64500
           172.16.100.0/24                               50      -          Incomplete      192.168.1.1                              64500, 64501
           172.16.123.0/26                               50      -          Incomplete      192.168.1.1                              64500
           172.16.123.64/26                              50      -          Incomplete      192.168.1.1                              64500
           192.168.0.100/32                              50      -          Incomplete      192.168.1.1                              64500, 64501
Description internal BGP external BGP

Local AS number added to path

no

yes

Nexthop overwritten

no

yes

MED added

no

yes

Local Preference added

yes

no

TTL

64

1

Updates from eBGP peer

all iBGP peers

all eBGP peers

Updates from iBGP peer

no

all eBGP peers

Summary

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot bgp_ibgp/bgp_ibgp_verify.robot