In some ways, BGP is nice and simple. For instance, there’s only one BGP: BGP version 4. Many network professionals have been asking the question whether the BGP version 4 will soon be replaced by BGP 5. However, there is nothing to worry about. Today, we still run BGP version 4 as our Exterior Gateway Protocol (EGP). Even if today’s BGP4 does all kinds of things that the BGP4 from 20 years ago couldn’t do, such as routing IPv6, multicast and VPNs or using communities. BGP has shown itself to be very extensible, but it’s all still BGP—and a single BGP process at that. But BGP only handles the exterior side of routing—there’s also interior routing.

Interior Gateway Protocols



And there’s a lot more choice in Interior Gateway Protocols (IGPs). An old favorite is RIP, the Routing Information Protocol. Even the improved RIPv2 is too simple for most networks these days, as is RIPng (next generation) for IPv6. As such, Cisco created its own Interior Gateway Routing Protocol (IGRP) and then an enhanced version aptly named Enhanced IGRP (EIGRP). However, the most widely used IGP is OSPF: Open Shortest Path First. OSPF is an “open” implementation of the Shortest Path First or Dijkstra’s algorithm. (The name doesn’t refer to the possible openness of the shortest path.) OSPF version 2 is used for IPv4; OSPF version 3 for IPv6. Networks that run both IP versions and use OSPF as their IGP thus need to run both OSPFv2 and OSPFv3.

Back in the late 1980s when OSPF was developed, the OSI (Open Systems Interconnect) family of networking protocols was still in contention, and a lot of technology was borrowed/stolen by OSI from IP and by IP from OSI. As a result, OSI has the IS-IS routing protocol for OSI CLNP routing, which is very similar to OSPF in many ways (or the other way around). IS-IS stands for Intermediate System to Intermediate System, where “intermediate system” means “router”. IS-IS was later extended to support first IPv4 and then also IPv6 and is mainly used in very large IP networks.

With that introduction out of the way, I want to focus on the most common case: a network running BGP as the EGP and OSPF as the IGP and look at how the routing duties are divided over both protocols and how the two interact.

Redistribution



With OSPF being an IGP and BGP being an EGP suggests an obvious division of labor: OSPF handles the internal routing, BGP the routing towards external destinations. However, it’s not that simple. Yes, OSPF is in charge of internal routing. These routes show up as “O” routes in the output of “show ip route” on a Cisco router. If the network is split into multiple OSPF areas—not really necessary these days unless you have hundreds of routers—you may also see inter-area “O IA” routes.

O and O IA routes are only the address blocks that are used on router interfaces that actually run OSPF. That doesn’t include interfaces towards servers or PC’s and other end-user devices, or, in the case of ISPs, customers. To make those addresses show up in OSPF, we need to redistribute connected subnets and/or redistribute static routes:

!

router ospf 1

redistribute connected subnets

redistribute static subnets

!

The 1 in “router ospf 1” is the OSPF process or instance number. It’s possible to run multiple OSPF instances on the same router—which of course requires careful planning to keep everything straight. If redistribution of all connected and/or static routes in OSPF is more than you need, you can add “route-map <route-map-name>” and then use the indicated route map to filter out the unwanted routes to keep them from being redistributed.

By default, redistributed routes are made external type 2, and show up as “O E2”. It’s also possible to redistribute as external type 1 (with “metric-type 1”). The difference is that with O E1 routes the OSPF cost of the route includes the cost of the links to reach the external route, while with O E2 routes the cost of the internal links is ignored.

iBGP



Obviously, BGP handles the routes towards external networks that are BGP-capable. However, it would be a bit embarrassing if all the BGP routers in the network would be telling their external neighbors completely different things. So all the BGP routers in the network need to talk to each other in order to tell a consistent story to external networks. This is what internal BGP (iBGP) is for. The “regular” BGP is thus external BGP (eBGP). When I say all the BGP routers, I really do mean all of them: if your network has 100 BGP routers, each of those needs to maintain iBGP sessions with the other 99. Well, unless you use route reflectors, but that’s a story for another day.

If you’re used to eBGP, iBGP requires some getting used to. Unlike eBGP, iBGP is just fine

working over many hops. However, this adds a complication. Consider the following network:



Suppose the iBGP session from router A to router D gets set up towards router D’s address on the link between B and D. Then, when the link between routers B and D goes down, D’s address on the interface that connects to that link goes down, and with it, the iBGP session configured towards that interface’s address. So rather than configure iBGP sessions towards interface addresses, we set up loopback interfaces for this. Unlike the loopback interface on a server or other host, which always uses address 127.0.0.1, routers use “real” addresses on their loopback interfaces, which works like this:

!

interface loopback0

ip address 192.0.2.65 255.255.255.255

!

router bgp 9000

neighbor 192.0.2.67 remote-as 9000

neighbor 192.0.2.67 update-source loopback0

!

Unlike other interfaces, loopback interfaces can have a /32 prefix length, so they only use up a single address. The remote AS for neighbor 192.0.2.67 is the same as the local AS (9000), making this BGP session an iBGP session. The “update-source loopback0” line makes sure that the source address in outgoing BGP packets is the IP address configured on interface loopback0, so it matches the address the remote router is looking for. If now one path between the two iBGP routers goes down, the iBGP packets can be rerouted over another path and there’s no impact to BGP. Note that for this to work, the loopback interface addresses need2 to be present in the IGP—typically, connected routes will be redistributed to make this happen.



Also unlike eBGP, iBGP doesn’t update the AS path or the next hop address. This means that the next hop address in iBGP updates still points towards the IP address of the router in the neighboring network that the route was learned from. This address will reside in a point-to-point subnet between your eBGP router and the BGP router of the neighboring network. Your eBGP router will know this address because it’s present on a directly connected interface, but without further action, the rest of your routers won’t know this address, so the next hop address for iBGP routes won’t resolve and the iBGP routes can’t be used. Again, redistributing connected networks into OSPF (or your IGP of choice) solves this. Alternatively, you can configure “next-hop-self” on your iBGP sessions and the router will replace the next hop address in iBGP updates with its own address.

BGP redistribution



It’s also possible to redistribute routes into BGP. For instance, in a large ISP network you may redistribute connected and static routes in BGP rather than in IS-IS, because this will keep IS-IS lean and mean. The extra BGP routes are relatively inconsequential, and a nice benefit is that if they’re rerouted internally, this doesn’t trigger any BGP updates. Rather, the next hop addresses are resolved differently after an IS-IS change, which each router can do independently. Of course doing this requires good filters that make sure that the large numbers of small prefixes used by customers don’t leak into the global BGP table. A good way to accomplish such filtering is by adding a community to the routes that may be propagated in eBGP and then filter based on that community.

Back in the day, it wasn’t uncommon to redistribute all BGP routes into OSPF. With half a million prefixes in BGP, this practice has become less common. If you really want to live on the edge, you can redistribute BGP into OSPF and OSPF into BGP. Then, if your filters aren’t perfect, routes may round-trip between BGP and OSPF, with the result that the AS path gets removed. So now you’re advertising over BGP a whole bunch of routes that aren’t yours, but with a one-hop AS path, so a lot of your neighbors will start sending you traffic for these routes.