Interaction Between BGP and IGPs

BGP and IGPs use different routing tables. To allow devices in different ASs to communicate, BGP needs to interact with IGPs. That is, BGP and IGP routes can be imported into IGP and BGP routing tables respectively.

Importing IGP Routes into BGP

BGP cannot discover routes and needs to import IGP routes into a BGP routing table for inter-AS communication. When an AS needs to advertise routes to another AS, an AS boundary router (ASBR) will import IGP routes into its BGP routing table. For better network planning, BGP can filter and set attributes for imported IGP routes based on routing policies. Alternatively, EBGP peers can select routes when traffic enters an AS based on the configured Multi-Exit Discriminator (MED) value.

BGP can import routes in either import or network mode:

In import mode, BGP imports routes according to protocol types, such as RIP routes, OSPF routes, and IS-IS routes. To ensure validity of imported IGP routes, BGP can also import static routes and direct routes in import mode.
In network mode, BGP imports routes in an IP routing table one by one. Therefore, the network mode is more precise than the import mode.

Importing BGP Routes into IGPs

When an AS needs to import routes from other ASs, an ASBR of this AS will import BGP routes into its IGP routing table. To prevent a large number of BGP routes from affecting devices in this AS, IGPs can filter and set attributes for imported BGP routes based on routing policies.

Problem and Solution Related to Route Import Between BGP and IGPs

BGP and IGPs often import routes from each other to advertise routes between ASs. However, the following problems may occur:

If a large number of BGP routes exist, low-end devices within ASs may be unable to have these routes installed, resulting in route loss.
If a route is unstable, for example, a port frequently alternates between Up and Down states, all routes within an AS may flap, affecting network stability.
BGP prevents routing loops using route attributes, for example, the AS_Path attribute. When all BGP routes are re-advertised into IGPs, their route attributes will be lost. As a result, the BGP routing loop prevention mechanism becomes ineffective, and routing loops may occur.

On a large IP network, the number of BGP routes is much larger than the number of IGP routes. Therefore, when BGP routes need to be imported into IGPs, exercise caution to prevent a large number of imported BGP routes from affecting IGP routes. To do so, use default routes and summarize routes to reduce the number of BGP routes.

Figure 1 Using EBGP and IBGP to Advertise Routes Between ASs

Figure 1 shows a typical IP backbone network topology. In this topology, the backbone layer and aggregation layer are AS 200 and AS 100 respectively, and AS 100 has two egress devices, SwitchC and SwitchD. The two ASs need to communicate using routes. The following requirements need to be met:

Devices on the aggregation layer are not expected to know route details of the backbone layer.
Devices on the aggregation layer have low performance and are not expected to receive a large number of BGP routes from the backbone layer.
Devices on the backbone layer have high performance and are expected to know route details of the aggregation layer.

In Figure 1, if the two egress devices SwitchC and SwitchD import BGP routes into OSPF, a large number of BGP routes will be transmitted from the backbone layer to the aggregation layer. This will enable the aggregation devices to receive a large number of BGP routes and know route details of the backbone layer. As a result, the preceding requirements cannot be met. The following solution can meet these requirements:

Two devices on the backbone layer, SwitchE and SwitchF, advertise default routes through BGP to two egress devices on the aggregation layer, SwitchC and SwitchD. This operation ensures that aggregation devices do not receive a large number of BGP routes from the backbone layer and do not know route details of the backbone layer.
The two egress devices, SwitchC and SwitchD, import only OSPF routes into BGP, without importing BGP routes into OSPF. This ensures that backbone devices know route details of the aggregation layer.
ASBRs of each AS establish an IBGP peer relationship. That is, SwitchC and SwitchD establish an IBGP peer relationship, and SwitchE and SwitchF establish an IBGP peer relationship. This ensures route backup of two egress devices in the ASs and improves reliability.