Redistribute IGP Information Into BGP

When using BGP to connect to the public Internet, you should advertise the minimum number of prefixes needed to make your site reachable from the Internet – the best approach is to configure the prefixes you want to advertise as you did in the Advertise IPv4 Prefixes to BGP Neighbors lab exercise. That makes little sense when using BGP as a generic routing protocol, for example, when connecting your sites to an MPLS/VPN service. In these scenarios, it’s better to redistribute local routing information (connected subnets, static routes, and IGP routes) into the BGP table; you’ll practice the route redistribution approach in this exercise.

Your lab has two sites connected to an MPLS/VPN provider. Each site has a WAN edge router and a core router, running OSPF between them. Your WAN edge routers run BGP with the provider edge routers.

Lab topology

In this lab exercise, you must establish connectivity between your sites to enable the core routers to ping each other.

Lab Configuration

If you’re using netlab, you’ll start with a preconfigured lab – netlab will configure IP addressing, OSPF routing, and EBGP sessions. If you’re using any other lab environment, you’ll have to configure all of that manually. The following tables describe the OSPF and BGP setup; the Reference Information section contains IP addressing information.

BGP Routers and AS Numbers

Node/ASN Router ID Advertised prefixes
AS65000
c1 10.0.0.1
AS65001
c2 10.0.0.2
AS65100
x1 10.0.0.10
x2 10.0.0.11

BGP Neighbors

Node Neighbor Neighbor AS Neighbor IPv4
c1 x1 65100 10.1.0.2
c2 x2 65100 10.1.0.10
x1 x2 65100 10.0.0.11
c1 65000 10.1.0.1
x2 x1 65100 10.0.0.10
c2 65001 10.1.0.9

OSPF Setup

Area 1 (AS 65000)

Router Interface IPv4 Address Neighbor(s)
c1 Loopback 10.0.0.1/32
Ethernet2 10.1.0.13/30 s1
s1 Loopback 10.0.0.3/32
Ethernet1 10.1.0.14/30 c1
Ethernet2 172.16.0.3/24 passive

Area 2 (AS 65001)

Router Interface IPv4 Address Neighbor(s)
c2 Loopback 10.0.0.2/32
Ethernet2 10.1.0.17/30 s2
s2 Loopback 10.0.0.4/32
Ethernet1 10.1.0.18/30 c2
Ethernet2 172.16.1.4/24 passive

Start the Lab

Assuming you already set up your lab infrastructure:

  • Change directory to basic/5-redistribute
  • Execute netlab up (device requirements, other options)
  • Log into your devices with netlab connect and verify IP addresses, OSPF routing, and basic BGP configuration.

Note: netlab will configure IP addressing, OSPF routing, and EBGP sessions on your routers. If you’re not using netlab, you must manually configure them.

Configuration Tasks

You have to exchange OSPF routing information between the two sites using BGP. To get that done, you have to:

  • Configure OSPF-to-BGP redistribution on C1 and C2, usually using a command similar to redistribute ospf1 within the BGP configuration.
  • Configure BGP-to-OSPF redistribution on C1 and C2, usually using a command similar to redistribute bgp2 within the OSPF configuration.

Warning

Two-way redistribution between routing protocols could quickly become exceedingly complex. Advertising the default route into the edge routing protocol is often better than redistributing core routes. You should test this alternative as an optional part of the lab exercise.

Verification

The local OSPF prefixes you want to advertise to the remote site must be in your router’s BGP table first. A command similar to show ip bgp is thus a good starting point; it’s even better to use a command that displays only the locally-originated prefixes, such as show ip bgp regexp ^$. The following printout contains the information displayed on C1 running Arista EOS:

c1#show ip bgp regexp ^$
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
Route status codes: s - suppressed contributor, * - valid, > - active, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
                    % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.0.0.3/32            10.1.0.14             -       -          -       0       i
 * >      172.16.0.0/24          10.1.0.14             -       -          -       0       i

c1#show ip bgp
...

          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.0.0.3/32            10.1.0.14             -       -          -       0       i
 * >      10.0.0.4/32            10.1.0.2              0       -          100     0       65100 65001 i
 * >      172.16.0.0/24          10.1.0.14             -       -          -       0       i
 * >      172.16.1.0/24          10.1.0.2              0       -          100     0       65100 65001 i

After validating the BGP table on C1 and C2, check that the BGP routes are redistributed into intra-site OSPF – inspect the routing table and OSPF topology database on S1 and S2. This is what Arista EOS displays on S1:

s1>show ip route

VRF: default
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B - Other BGP Routes,
       B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
       I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
       A O - OSPF Summary, NG - Nexthop Group Static Route,
       V - VXLAN Control Service, M - Martian,
       DH - DHCP client installed default route,
       DP - Dynamic Policy Route, L - VRF Leaked,
       G  - gRIBI, RC - Route Cache Route

Gateway of last resort:
 S        0.0.0.0/0 [1/0] via 192.168.121.1, Management0

 O        10.0.0.1/32 [110/20] via 10.1.0.13, Ethernet1
 C        10.0.0.3/32 is directly connected, Loopback0
 O E2     10.0.0.4/32 [110/1] via 10.1.0.13, Ethernet1
 C        10.1.0.12/30 is directly connected, Ethernet1
 C        172.16.0.0/24 is directly connected, Ethernet2
 O E2     172.16.1.0/24 [110/1] via 10.1.0.13, Ethernet1
 C        192.168.121.0/24 is directly connected, Management0

Next:

Reference Information

This lab uses a superset of the 4-router lab topology. You can still use that topology without the S1/S2 routers and redistribute connected prefixes into BGP.

The following information might help you if you plan to build custom lab infrastructure:

Device Requirements

Lab Wiring

Origin Device Origin Port Destination Device Destination Port
c1 Ethernet1 x1 swp1
x1 swp2 x2 swp2
c2 Ethernet1 x2 swp3
c1 Ethernet2 s1 Ethernet1
c2 Ethernet2 s2 Ethernet1
Origin Device Origin Port Description
s1 Ethernet2 s1 -> stub
s2 Ethernet2 s2 -> stub

Lab Addressing

Node/Interface IPv4 Address IPv6 Address Description
c1 10.0.0.1/32 Loopback
Ethernet1 10.1.0.1/30 c1 -> x1
Ethernet2 10.1.0.13/30 c1 -> s1
c2 10.0.0.2/32 Loopback
Ethernet1 10.1.0.9/30 c2 -> x2
Ethernet2 10.1.0.17/30 c2 -> s2
x1 10.0.0.10/32 Loopback
swp1 10.1.0.2/30 x1 -> c1
swp2 10.1.0.5/30 x1 -> x2
x2 10.0.0.11/32 Loopback
swp2 10.1.0.6/30 x2 -> x1
swp3 10.1.0.10/30 x2 -> c2
s1 10.0.0.3/32 Loopback
Ethernet1 10.1.0.14/30 s1 -> c1
Ethernet2 172.16.0.3/24 s1 -> stub
s2 10.0.0.4/32 Loopback
Ethernet1 10.1.0.18/30 s2 -> c2
Ethernet2 172.16.1.4/24 s2 -> stub

  1. You might have to add the OSPF process number to the command. ↩

  2. Depending on your devices, you might have to add the BGP AS number to the command. Some older platforms must be told to redistribute subnets into OSPF. ↩