Configuring BGP on Routers Within an AS

Problem

You want to propagate the routes learned by your EBGP peering sessions to your IBGP routers.

Solution

Configure IBGP on the border router and on all the routers within your AS. On each router, configure an IBGP group:

	[edit protocols bgp]
	aviva@RouterF# set group internal-within-AS65500 type internal
	aviva@RouterF# set group internal-within-AS65500 local-address 192.168.16.1
	aviva@RouterF# set group internal-within-AS65500 neighbor 192.168.15.1
	aviva@RouterF# set group internal-within-AS65500 neighbor 192.168.17.1

Discussion

Once you have set up an external BGP connection that runs between two different ASs, the two border routers are able to exchange routing information, but you still need a way to propagate these routes within your AS. One way to do this is to inject all the external routes into your IGP. Generally, you do not want to use this approach, especially if you are an ISP and are carrying the full Internet routing table; there are too many routes (on the order of 170,000 and climbing), and they change too often, so you would end up overwhelming the IGP. The standard way to inject external routes into your AS is to set up IBGP sessions on all routers in your AS. The connections between all IBGP routers must be fully meshed to prevent routing loops within the AS. This full mesh is a virtual mesh, completely independent of any actual physical connections. To do this, you create an IBGP group in which you list as neighbors all the IBGP routers in the AS. You must also use an IGP, such as OSPF or IS-IS, to distribute the IBGP routing information to all the routers in the AS. This recipe configures the routers shown in Figure 13-2.

The configuration for IBGP is very similar to that for EBGP. You create a BGP group with the set protocols bgp group command. This time, however, the type is internal, not external. Because the group is within the AS, you do not need to configure the peers AS number. In the group, you list all the IBGP peers, one in each neighbor statement. These are all the IBGP routers in the AS, both the ones that the router is directly connected to and the ones that it is not directly connected to. These neighbor statements effectively create the full-mesh peering among all the IBGP routers. For IBGP peers, when you specify the addresses, you don use the physical interface but rather the loopback address of the router. You can do this because even if a link to the router is down, it might still be reachable through the IGP. Finally, the local-address statement sets the loopback address as the source address of all IP packets sent by BGP to all destination routers.

Figure 13-2. IBGP network

The configuration for all the IBGP routers is basically the same, with each router using the appropriate local address and listing all the other IBGP routers in the AS as neighbors.

Define the AS number and router ID on each IBGP router just as you did on the border router:

	[edit routing-options]
	aviva@RouterE# set autonomous-system 65500
	aviva@RouterE# set router-id 192.168.15.1

Be sure to configure the same AS number on all the IBGP routers.

Finally, an IGP must run among all the IBGP routers. For the examples in this chapter, we use a simple OSPF configuration. Here is the configuration on RouterF, the border router:

	[edit protocols]
	aviva@RouterF# show ospf
	area 0.0.0.0 {
	 interface lo0.0 {
	 passive;
	 }
	 interface t1-0/0/2.0;
	 interface fe-0/0/1.0;
	}

When all routers are configured for the IBGP mesh, use the show bgp summary command to check that all the sessions are up and running. Heres what you see on one of the internal routers:

	
	aviva@RouterE> show 
bgp summary
	Groups: 1 Peers: 2 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	inet.0 5 5 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	192.168.16.1 65500 1985 1977 0 1 16:27:39 5/5/0
	 0/0/0
	192.168.17.1 65500 15 17 0 0 7:36 0/0/0
	 0/0/0

The first line of output shows that this IBGP router has one BGP group and two peers, which are both up. The Table portion shows five active BGP paths in the inet.0 routing table. The Peer portion shows that the router received these routes from 192. 168.16.1, which is the border router. Use the show route command to verify this. The summary version provides an overview of routes learned from BGP and other protocols:

	aviva@RouterE>  
show route summary
	Autonomous system number: 65500
	Router ID: 192.168.15.1
	inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
	 Direct: 3 routes, 3 active
	 Local: 2 routes, 2 active
	 OSPF: 5 routes, 4 active
	 BGP: 5 routes, 5 active
	 Static: 1 routes, 1 active

The show route protocol bgp command gives more detail about the routes learned from BGP:

	aviva@RouterE> show route protocol bgp
	inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.24.0/24 *[BGP/170] 00:07:14, localpref 100, from 192.168.16.1
	 AS path: 65505 I
	 > to 172.19.121.1 via fe-0/0/0.0
	10.0.29.0/24 *[BGP/170] 00:07:14, localpref 100, from 192.168.16.1
	 AS path: 65505 I
	 > to 172.19.121.1 via fe-0/0/0.0
	192.168.11.1/32 *[BGP/170] 00:07:14, MED 1, localpref 100, from 192.168.16.1
	 AS path: 65505 I
	 > to 172.19.121.1 via fe-0/0/0.0
	192.168.14.1/32 *[BGP/170] 00:07:14, localpref 100, from 192.168.16.1
	 AS path: 65505 I
	 > to 172.19.121.1 via fe-0/0/0.0
	192.168.18.1/32 *[BGP/170] 00:07:14, MED 65, localpref 100, from 192.168.16.1
	 AS path: 65505 I
	 > to 172.19.121.1 via fe-0/0/0.0

The five BGP routes are marked with an asterisk to indicate that they are active routes. These routes are all to systems in the remote AS, 65505. The 192.168/32 addresses are the loopback addresses of the BGP routers (192.168.14.1 is the border router, and 192.168.11.1 and 192.168.14.1 are its IBGP peers), and the two 10.0/24 prefixes are the subnets connecting the remote IBGP peers.

Notice that from BGP, the router learns only about destinations in the remote AS. It learns routes to destinations within the local AS from OSPF:

	aviva@RouterE> show route protocol ospf
	inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.8.0/24 *[OSPF/10] 00:12:15, metric 66
	 > via t1-0/0/3.0
	10.0.13.0/24 [OSPF/10] 00:12:15, metric 65
	 > via t1-0/0/3.0
	192.168.16.1/32 *[OSPF/10] 00:12:15, metric 65
	 > via t1-0/0/3.0
	192.168.17.1/32 *[OSPF/10] 00:12:15, metric 66
	 > via t1-0/0/3.0
	224.0.0.5/32 *[OSPF/10] 17:32:17, metric 1
	 MultiRecv

OSPF has routes to the two internal subnets, 10.0.8.0/24 and 10.0.13.0/24, and to the loopback addresses of the other two routers in the AS (the 192.168 addresses).

Looking at the BGP sessions on the border router, heres what you see:

	aviva@RouterF> show bgp summary
	Groups: 2 Peers: 3 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	inet.0 8 5 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	192.168.15.1 65500 1994 2006 0 0 16:37:18 0/0/0
	 0/0/0
	192.168.17.1 65500 37 44 0 0 18:19 0/0/0
	 0/0/0
	10.0.31.1 65505 2002 2006 0 0 16:37:26 5/8/0
	 0/0/0

The Groups line shows that this router has two BGP groups (one for the EBGP session, the second for the IBGP peerings) and has three peers that are all up. The Table section shows that the router has eight BGP routes in the inet.0 table. The Peer section shows where the router is learning the BGP routes, which is only from its EBGP peer, 10.0.31.1. It is not receiving any routes from its IBGP peers, 192.168.15.1 and 192.168.17.1, as expected. Looking in the routing table confirms that the only routes learned from BGP are those from the remote AS:

	aviva@RouterF> show route protocol bgp
	inet.0: 18 destinations, 22 routes (18 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 [BGP/170] 15:23:37, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	10.0.24.0/24 *[BGP/170] 01:23:48, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	10.0.29.0/24 *[ 
BGP/170] 01:19:38, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	10.0.31.0/24 [ 
BGP/170] 15:23:37, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	172.19.121.0/24 [BGP/170] 15:23:37, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	192.168.11.1/32 *[BGP/170] 01:18:52, 
MED 1, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	192.168.14.1/32 *[BGP/170] 15:23:37, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	192.168.18.1/32 *[BGP/170] 01:23:38, MED 65, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0

The BGP routes in the routing table now include the value of the BGP multiple exit discriminator (MED) attribute that was advertised with the prefix:

	192.168.11.1/32 *[BGP/170] 01:18:52, MED 1, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	192.168.18.1/32 *[BGP/170] 01:23:38, MED 65, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0

The output shows the MED in the prefixes to the IBGP routers in the immediately adjacent AS. The MED is the BGP metric and is used as a tie-breaker to pick the path to an AS when there are multiple equivalent paths between the ASs and when all other factors in determining the exit point are equal.

The show bgp group command shows information about the two BGP groups on the router:

	aviva@RouterF> show bgp group
	Group Type: External Local AS: 65500
	 Name: session-to-AS65505 Index: 0 Flags: <>
	 Export: [ send-statics ]
	 Total peers: 1 Established: 1
	 10.0.31.1+179
	 inet.0: 5/8/0
	Group Type: Internal AS: 65500 Local AS: 65500
	 Name: internal-within-AS65500 Index: 1 Flags: 
	 Total peers: 2 Established: 2
	 192.168.15.1+179
	 192.168.17.1+179
	 inet.0: 0/0/0
	Groups: 2 Peers: 3 External: 1 Internal: 2 Down peers: 0 Flaps: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	inet.0 8 5 0 0 0 0

The first group is the external group session-to-AS65505, and the second is the IBGP group internal-within-AS65500. The output shows the local AS number and the export policies that have been applied to this group (here, send-statics). Because a group is a collection of peers with the same export characteristics, the show bgp group command shows just the configured export policy. Any import policies you might have configured are not displayed, because each peer in a group can have a different import policy. This command also shows the number of peers in the group and their addresses, and the number of routes active and received from this peer. This group has one peer, which is the remote border router 10.0.31.1, and it has received six routes from the peer, three of which are active (3/6/0).

The last three lines of the output summarize the BGP groups and the routes that have been placed into the routing table. It shows the two groups (one external and one internal) and three peers that are up and have never gone down. The routing table has learned eight total paths from its BGP peers and five of them are active in the inet.0 routing table.