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
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 65100
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> commit
cfg> show bgp peer
Instance: default
  Peer                     Remote AS    State         Up/Down Time          PfxRcvd         PfxSent
  R2                       64500        Established   0d:00h:00m:10s        1               4
  R3                       64500        Established   0d:00h:00m:19s        1               4
  ISP                      64501        Established   0d:00h:00m:16s        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
Instance: default, AFI: ipv4, SAFI: unicast
 Hostname: ISP, Peer IP: 192.168.1.2, Source IP: 192.168.1.1, Received routes: 2
    Prefix                 Next Hop               MED        Local Preference  AS Path    Status
    172.16.100.0/24        192.168.1.2            0          -                 64501      Valid
    192.168.0.4/32         192.168.1.2            0          -                 64501      Valid
cfg> show bgp rib-out ipv4 unicast peer R2
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R2, Sent routes: 2
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    172.16.100.0/24        0           100               Incomplete      192.168.1.2      64501
    192.168.0.4/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 most common method used is to rewrite the nexthop to the loopback address of the peering router. This can be achieved either via the update-next-hop or the nexthop-self option in the peer-group configuration. The first one is more flexible, while the second one only allows to set the nexthop to the peer IP address.

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
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R2, Sent routes: 2
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    172.16.100.0/24        0           100               Incomplete      192.168.0.1      64501
    192.168.0.4/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
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 ISP
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R4, Sent routes: 4
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    172.16.100.0/24        0           -                 Incomplete      -                64500, 64501
    172.16.123.0/26        0           -                 Incomplete      -                64500
    192.168.0.4/32         0           -                 Incomplete      -                64500, 64501
    172.16.123.64/26       0           -                 Incomplete      -                64500
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
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R3, Sent routes: 3
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    172.16.100.0/24        0           150               Incomplete      192.168.0.1      64501
    192.168.0.4/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> show bgp rib-out ipv4 unicast peer R4
Instance: default, AFI: ipv4, SAFI: unicast
  Peer: R4, Sent routes: 5
    Prefix                 MED         Local Preference  Origin          Next Hop         AS Path
    192.168.0.0/30         50          -                 Incomplete      -                64500
    172.16.100.0/24        50          -                 Incomplete      -                64500, 64501
    172.16.123.0/26        50          -                 Incomplete      -                64500
    192.168.0.4/32         50          -                 Incomplete      -                64500, 64501
    172.16.123.64/26       50          -                 Incomplete      -                64500
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