Build a Transit Network with IBGP

In the Establish an IBGP Session Between WAN Edge Routers lab exercise, you built a simple network with two adjacent BGP routers. In this exercise, you’ll explore the impact of adding a core router between edge routers running BGP.

After starting the lab, you’ll have to configure all the IBGP sessions needed to establish connectivity between the loopback interfaces of PE2 and EXT routers. You MUST NOT use route redistribution between OSPF and BGP to solve the connectivity issues (there’s an excellent reason for that restriction).

Existing Lab Configuration

When starting the lab with netlab, you’ll get a preconfigured lab:

• All routers will have their interfaces and IP addresses configured
• OSPF will be running between PE1, PE2, and CORE routers.
• BGP will be configured on PE1, PE2 and EXT routers. All three routers will advertise their loopback interfaces in BGP.
• There will be an EBGP session between PE1 and EXT routers.

The following tables summarize the existing lab configuration.

BGP Configuration

The routers in your lab use the following BGP AS numbers. The external router advertises an IPv4 prefix; your PE routers advertise their loopback IPv4 addresses.

Node/ASN	Router ID	Advertised prefixes
AS65000
pe1	10.0.0.2	10.0.0.2/32
pe2	10.0.0.3	10.0.0.3/32
AS65100
ext	10.0.0.10	172.16.42.0/24

netlab also configures the EBGP session between PE1 and EXT routers.

Node	Neighbor	Neighbor AS	Neighbor IPv4
ext	pe1	65000	10.1.0.6
pe1	ext	65100	10.1.0.5

OSPF Configuration

OSPF backbone area is configured on the following routers in AS 65000:

Router	Interface	IPv4 Address	Neighbor(s)
core	Loopback	10.0.0.1/32
	Ethernet1	10.1.0.1/30	pe1
	Ethernet3	True	pe2
pe1	Loopback	10.0.0.2/32
	swp1	10.1.0.2/30	core
pe2	Loopback	10.0.0.3/32
	Ethernet3	True	core

Start the Lab

Assuming you already set up your lab infrastructure:

• Change directory to ibgp/2-transit
• Execute netlab up (device requirements, other options)
• Log into your devices (R1, R2) with netlab connect and verify that netlab correctly configured their IP addresses, OSPF routing, and EBGP sessions.

Propagate External BGP Routes to PE2

Try to ping the external router (172.16.42.42) from PE2. You have to check the connectivity between the loopback addresses, so you should use a version of the ping command that specifies the source interface or the source IP address. For example, you must use ping 172.16.42.42 source loop 0 on Arista EOS.

The ping command will most likely fail¹. Arista EOS displays the root cause of the failure: the destination network is not in the IP routing table:

pe2#ping 172.16.42.42 source loop 0
PING 172.16.42.42 (172.16.42.42) from 10.0.0.3 : 72(100) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable

--- 172.16.42.42 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 40ms

A quick look into the routing- and BGP table on PE2² confirms that PE2 knows nothing about the IPv4 prefix 172.16.42.0/24.

pe2#show ip route | begin Gateway
Gateway of last resort is not set

 O        10.0.0.1/32 is directly connected, Ethernet3
 O        10.0.0.2/32 [110/20] via 10.0.0.1, Ethernet3
 C        10.0.0.3/32 is directly connected, Loopback0
 O        10.1.0.0/30 [110/20] via 10.0.0.1, Ethernet3

pe2#show ip bgp | begin Network
          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.0.0.3/32            -                     -       -          -       0       i

The lack of BGP routes on PE2 shouldn’t surprise you if you completed the Establish an IBGP Session Between WAN Edge Routers lab exercise – you already know you need an IBGP session between PE1 and PE2.

Configuration task:

• Configure an IBGP session between the loopback interfaces of PE1 and PE2³.

Verification:

Check the BGP neighbors and the BGP table on PE2. You should see an established IBGP session between PE1 and PE2 in the BGP summary printout and the BGP route for 172.16.42.0/24 in the BGP table.

This is the printout you should get on Arista EOS:

pe2#show ip bgp sum
BGP summary information for VRF default
Router identifier 10.0.0.3, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.0.0.2 4 65000             20        20    0    0 00:00:08 Estab   2      2
pe2#show ip bgp | begin Network
          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.0.0.2/32            10.0.0.2              0       -          100     0       i
 * >      10.0.0.3/32            -                     -       -          -       0       i
 * >      172.16.42.0/24         10.0.0.2              0       -          100     0       65100 i

Retry the ping command. It should no longer complain that the network is unreachable but could generate another bit of information on devices that parse and display ICMP error reports. For example, Arista EOS reports that the CORE router (10.0.0.1) claims it cannot reach the destination:

pe2#ping 172.16.42.42 source loop 0
PING 172.16.42.42 (172.16.42.42) from 10.0.0.3 : 72(100) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Net Unreachable

--- 172.16.42.42 ping statistics ---
5 packets transmitted, 0 received, +1 errors, 100% packet loss, time 30ms

Fixing the Core Routing

Log into the router complaining it cannot reach the destination (the CORE router) and check its IP routing table. The route for 172.16.42.0/24 is missing.

core#show ip route | begin Gateway
Gateway of last resort is not set

 C        10.0.0.1/32 is directly connected, Loopback0
 O        10.0.0.2/32 [110/10] via 10.1.0.2, Ethernet1
 O        10.0.0.3/32 is directly connected, Ethernet3
 C        10.1.0.0/30 is directly connected, Ethernet1

That shouldn’t be a big surprise; after all, the external prefix is advertised only in BGP, and the CORE router runs only OSPF.

There are at least four ways to fix the routing in the core of your autonomous system:

• Redistribute EBGP information into OSPF. That’s dangerous in real-life networks with large BGP tables, and thus, you are not allowed to do it in this lab exercise.
• Advertise an OSPF default route from PE1. That would solve your immediate problem but wouldn’t result in an actual transit network – you would run into “exciting” challenges when trying to connect external networks to PE2. This option is thus also off the table.
• Hide the transit packets from the CORE router using MPLS or IP-over-something tunnels. While the MPLS approach is commonly used to build BGP-free core networks, it’s too complex for this lab exercise⁴.
• Make the CORE router part of the BGP routing. This is the approach we’ll use.

Configuration tasks:

• Configure BGP with AS number 65000 on the CORE router
• Configure IBGP sessions between all BGP routers in AS 65000.

Verification:

Check the BGP neighbors and the BGP table on the CORE router. The router should have two established IBGP sessions and three prefixes in its BGP table:

core#show ip bgp sum
BGP summary information for VRF default
Router identifier 10.0.0.1, local AS number 65000
Neighbor Status Codes: m - Under maintenance
  Neighbor V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.0.0.2 4 65000             14        14    0    0 00:00:10 Estab   2      2
  10.0.0.3 4 65000             10         9    0    0 00:00:08 Estab   1      1
core#show ip bgp | begin Network
          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.0.0.2/32            10.0.0.2              0       -          100     0       i
 * >      10.0.0.3/32            10.0.0.3              0       -          100     0       i
 * >      172.16.42.0/24         10.0.0.2              0       -          100     0       65100 i

Retry the ping command on PE2. PE2 should be able to reach the EXT router:

pe2#ping 172.16.42.42 source loop 0
PING 172.16.42.42 (172.16.42.42) from 10.0.0.3 : 72(100) bytes of data.
80 bytes from 172.16.42.42: icmp_seq=1 ttl=62 time=0.086 ms
80 bytes from 172.16.42.42: icmp_seq=2 ttl=62 time=0.007 ms
80 bytes from 172.16.42.42: icmp_seq=3 ttl=62 time=0.008 ms
80 bytes from 172.16.42.42: icmp_seq=4 ttl=62 time=0.006 ms
80 bytes from 172.16.42.42: icmp_seq=5 ttl=62 time=0.007 ms

--- 172.16.42.42 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.006/0.022/0.086/0.032 ms, ipg/ewma 0.032/0.053 ms

Next: Use BGP Route Reflectors

Reference Information

This lab uses the 4-router lab topology. The following information might help you if you plan to build custom lab infrastructure:

Device Requirements

• Use any device supported by the netlab BGP and OSPF configuration modules.
• Git repository contains initial device configurations for Cumulus Linux.

Lab Wiring

This lab uses the 4-router lab topology with the following mapping between the routers in the 4-router lab topology and this lab:

4-router-topology device	Lab device
C1	Core
C2	PE2
X1	PE1
X2	EXT

Link Name	Origin Device	Origin Port	Destination Device	Destination Port
	core	Ethernet1	pe1	swp1
Unused link	core	Ethernet2	ext	swp1
Inter-AS link	pe1	swp2	ext	swp2
Unused link	pe2	Ethernet1	pe1	swp3
Unused link	pe2	Ethernet2	ext	swp3
	core	Ethernet3	pe2	Ethernet3

Note: Some interfaces are not used to conform with the predefined 4-router lab topology.

Lab Addressing

Node/Interface	IPv4 Address	IPv6 Address	Description
core	10.0.0.1/32		Loopback
Ethernet1	10.1.0.1/30		core -> pe1
Ethernet2			Unused link
Ethernet3	True		core -> pe2
ext	172.16.42.42/24		Loopback
swp1			Unused link
swp2	10.1.0.5/30		Inter-AS link
swp3			Unused link
pe1	10.0.0.2/32		Loopback
swp1	10.1.0.2/30		pe1 -> core
swp2	10.1.0.6/30		Inter-AS link
swp3			Unused link
pe2	10.0.0.3/32		Loopback
Ethernet1			Unused link
Ethernet2			Unused link
Ethernet3	True		pe2 -> core

Note: Some interfaces are not configured with IP addresses to conform with the predefined 4-router lab topology.