Configuring a BGP Session Between Routers in Two ASs

Table of contents:

Problem

You want to configure BGP on the border routers that connect the two different ASs.

Solution

Configure the autonomous system number and router ID on each router:

	[edit routing-options]
	aviva@RouterF# set autonomous-system 65500
	aviva@RouterF# set router-id 192.168.16.1

Then configure an EBGP session to the border router in the other AS:

	[edit protocols bgp]
	aviva@RouterF# set group session-to-AS65505 type external
	aviva@RouterF# set group session-to-AS65505 peer-as 65505
	aviva@RouterF# set group session-to-AS65505 neighbor 10.0.31.1
	[edit protocols]
	aviva@RouterF# show
	bgp {
	 group session-to-AS65505 {
	 type external;
	 peer-as 65505;
	 neighbor 10.0.31.1;
	 }
	}

Discussion

The basic configuration of EBGP is very straightforward, and the configuration of the two EBGP peers is pretty much identical. This recipe shows how to configure a session between the two border routers shown in Figure 13-1.

Figure 13-1. EBGP network

You define the routers AS number and its router ID. You don configure these in the [edit protocols bgp] hierarchy but rather in the [edit routing-options] hierarchy because these two properties are not specific to BGP and can be used by other routing protocols. BGP includes the 32-bit router ID in Open messages when establishing a BGP connection. If you don manually set the router ID, the JUNOS software uses the IP address on the lo0 interface. However, it is good practice to configure the router ID so the address included in Open messages is always clear.

For an EBGP peering connection, the AS numbers must be different on the two routers. In this recipe, RouterF is in AS 65500 and RouterD is in AS 65505.

In the JUNOS BGP configuration, you place BGP neighbors into peer groups so you can apply the same policies and other characteristics to an entire group of neighbors. Each peer group is identified by a name. In this recipe, the group name is session-to-AS65505. While multiple peers can be members of the same group, it is good practice to configure a separate group for each external peer, especially if the external peer is untrusted.

Within a group, you need to configure three things to set up the EBGP session:

Use the type external statement to define the session as an external one.
Set the AS number of the remote peer AS (here, 65505).
Specify the address of the neighboring border router (here, 10.0.31.1).

For EBGP sessions, use the peer routers interface address. You can use the interface address instead of the routers lo0 address because, in most cases, the link between ASs is a point-to-point WAN link. If this link goes down, the peer router is unreachable anyway, so the remote AS would also be unreachable.

To establish the EBGP session, configure a similar EBGP group on the other border router:

	[edit routing-options]
	aviva@RouterD# show
	router-id 192.168.14.1;
	autonomous-system 65505;

	[edit protocols]
	aviva@RouterD# show
	bgp {
	 group session-to-AS65500 {
	 type external;
	 peer-as 65500;
	 neighbor 10.0.31.2;
	 }
	}

Another useful bit of information to set for each neighbor is a text description of the peering session:

	[edit protocols bgp]
	aviva@RouterF# set group session-to-AS65505 description "EBGP to Customer A"

This is especially useful to help identify peering sessions when many sessions are configured on a single router.

After you have configured the two peer routers, check that they have established a BGP connection:

	aviva@RouterF>  
show bgp neighbor
	Peer: 10.0.31.1+1778 AS 65505 Local: 10.0.31.2+179 AS 65500
	 Description: EBGP to Customer A
	 Type: External State: Established Flags: 
	 Last State: OpenConfirm Last Event: RecvKeepAlive
	 Last Error: None
	 Options: 
	 Holdtime: 90 Preference: 170
	 Number of flaps: 0
	 Peer ID: 192.168.14.1 Local ID: 192.168.16.1 Active Holdtime: 90
	 Keepalive Interval: 30 Peer index: 0
	 Local Interface: t1-0/0/3.0
	 NLRI advertised by peer: inet-unicast
	NLRI for this session: inet-unicast
	Peer supports Refresh capability (2)
	Table inet.0 Bit: 10000
	 RIB State: 
BGP restart is complete
	 Send state: in sync
	 
Active prefixes: 0
	 Received prefixes: 0
	 Suppressed due to damping: 0
	 Advertised prefixes: 0
	Last traffic (seconds): Received 19 Sent 19 Checked 19
	Input messages: Total 12 Updates 0 Refreshes 0 Octets 254
	Output messages: Total 13 Updates 0 Refreshes 0 Octets 273
	Output Queue[0]: 0

The third line of the output shows that the session has been established. The current state of the BGP connection is Established. If the connection isn up, but is in the process of establishing itself, this field shows the current state of the BGP session. These states correspond to the session establishment states defined in RFC 1771:

Idle: This is the initial stage of establishing a connection, when BGP is waiting for a start event.
Connect: BGP is waiting for TCP to establish its connection between the two peers.
Active: BGP is actively attempting to connect to its peer.
OpenSent: The local BGP peer has sent an open request to the peer and is waiting to receive an open message back.
OpenConfirm: BGP acknowledges that it has received an open message from the peer and is waiting to receive a keepalive message.

When a BGP session doesn get established, the state often remains as Connect or Active. To troubleshoot the problem, use the show interfaces terse and show interfaces commands to check that the interfaces between the two routers are up and configured properly. Check the BGP configuration on both routers, making sure that the AS numbers are correct. Also, check the current state of the TCP session with the show system connections extensive command (see Recipe 13.3).

The remainder of the third line and the next two lines provide additional information about the session. The Last State field shows the previous state of the BGP session, which is OpenConfirm, the BGP message the two peers exchange when they have confirmed that they will indeed establish a connection.

This command also shows other information about the BGP session. The first line shows the addresses and AS number of the peer border router and the address and AS number of the local router:

	Peer: 10.0.31.1+1778 AS 65505 Local: 10.0.31.2+179 AS 65500

The number following the remote peers address is the TCP port number used for the connection. The second line shows the peer description that you configured with the set description command.

The Options line shows the BGP options that the peers have agreed to use for the session:

	Options:

The next lines of the output show the specific values of options and other information about the session:

	Holdtime: 90 Preference: 170

Holdtime is the hold timer value, which is the maximum length of time that one peer will wait to get a BGP message from the other side (either an update or a keepalive message) before assuming that this session is down. RPD uses the Preference value to select among routes learned from different sources (see Table 8-2). These two output fields report the values configured with the hold-time and preference statements. Because we haven configured these values, both fields show the default values: 170 for the route preference and 90 seconds for the hold time (three times the default keepalive message interval of 30 seconds).

A few lines down in the output, you see the keepalive interval. The Number of flaps field tells you whether the BGP session has gone down and come back up:

	Number of flaps: 0

Because we just established the session, the value is 0. You can use this field to track whether the session has been interrupted. The Peer ID and Local ID fields show the router ID of each peer, which are configured with the set routing-options router-id command. The Active Holdtime field is the hold timer that has been negotiated between the BGP peers and is actually being used on the session.

	Peer ID: 192.168.14.1 Local ID: 192.168.16.1 Active Holdtime: 90

The next several lines show the NLRI learned from the BGP update messages sent on this session. These two lines show the address family that is being advertised by the peer and used by the session, which can be either unicast (as shown here) or multicast:

	NLRI advertised by peer: inet-unicast
	NLRI for this session: inet-unicast

The route refresh line shows that the peer supports the BGP route refresh capability, defined in RFC 2918, which allows BGP peers to readvertise their prefixes to the peer. Route refresh facilitates nondisruptive routing-policy changes.

Next is information about routes learned from BGP in the inet.0 routing table:

	Table inet.0 Bit: 10000
	RIB State: 
BGP restart is complete
	Send state: in sync
	Active prefixes: 0
	Received prefixes: 0
	Suppressed due to damping: 0
	Advertised prefixes: 0

The last few lines show traffic statistics for the session:

	Last traffic (seconds): Received 19 Sent 19 Checked 19
	 Input messages: Total 12 Updates 0 Refreshes 0 Octets 254
	 Output messages: Total 13 Updates 0 Refreshes 0 Octets 273
	 Output Queue[0]: 0

The show bgp summary command also shows information about the BGP connection that you can use to determine whether the session has been established:

	aviva@RouterF> show bgp summary
	Groups: 1 Peers: 1 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	inet.0 0 0 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	10.0.31.1 65505 29 30 0 0 13:56 0/0/0
	 0/0/0

The first line shows the number of groups configured (here, 1) and the number of peers that are up (1) and down (0). Because our router currently has just one peer, this line tells us that the peer is up. The Table portion of the output provides a summary of the BGP route information in each routing table. This output shows that the inet.0 routing table doesn yet have any BGP routes.

The Peer portion of the output shows the address of the BGP peer (10.0.31.1), its AS number (65505), and traffic statistics for the session. The State column shows three values separated by slashes that correspond to the states Active/Received/Damped. If the session with the neighbor is actively establishing itself but is not yet up, the State column shows Active. If the state is Connect or Idle and has remained that way for more than several minutes (the Last Up/Dwn field tells how long the neighbor has been in the particular state), this is a sign that the connection is not establishing. Use the show interfaces terse command to check that the physical connection to the peer is physically up and the show chassis hardware command to make sure that the network interface card is still installed and present in your router. If you determine that the Layer 1 and Layer 2 portions of the connection are functioning, move up the protocol stack. Try pinging the remote IP address to help identify if any filters are in place that might block the connection. You can also try ICMP tests and a Telnet test from the local IP address to port 179 on the remote IP address to determine whether you can establish a socket between the two IP addresses.

When the State column shows three numbers separated by slashes, the BGP session is up. The values are the number of routes received from the neighbor, the number of routes accepted as active and being used in the forwarding table, and the number of routes that have been damped. The current state is 0/0/0, and the previous state of the session, on the second line of output, is 0/0/0.

The remaining columns for the peer show the number of packets received from (InPkt) and sent to (OutPkt) the peer; the number of packets queued to be sent to the peer (OutQ), which is usually 0 because the queue is emptied quickly; the number of times the BGP session has flapped (gone down and then come back up); and how long it has been since the neighbor was established (Last Up/Dwn).

Why does the State column show that there are no BGP routes? Looking at the routing table confirms that the router hasn learned any routes from BGP:

	aviva@RouterF> show route
	inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[Static/5] 1w0d 22:18:02
	 > to 172.19.121.1 via fe-0/0/0.0
	10.0.8.0/24 *[Direct/0] 1w0d 22:17:55
	 > via fe-0/0/1.0
	10.0.8.2/32 *[Local/0] 1w0d 22:18:05
	 Local via fe-0/0/1.0
	10.0.13.0/24 *[Direct/0] 05:30:25
	 > via t1-0/0/2.0
	10.0.13.2/32 *[Local/0] 05:30:27
	 Local via t1-0/0/2.0
	10.0.31.0/24 *[Direct/0] 05:30:27
	 > via t1-0/0/3.0
	10.0.31.2/32 *[Local/0] 05:30:27
	 Local via t1-0/0/3.0
	172.19.121.0/24 *[Direct/0] 1w0d 22:18:02
	 > via fe-0/0/0.0
	172.19.121.116/32 *[Local/0] 1w0d 22:18:05
	 Local via fe-0/0/0.0
	192.168.16.1/32 *[Direct/0] 1d 22:22:13
	 > via lo0.0

Sure enough, no routes have been learned from BGP. You need a routing policy to redistribute the desired information from AS 65505 into the local AS. Create a routing policy on each peer so that it exports static routes into BGP:

	[edit policy-options policy-statement send-statics ]
	aviva@RouterF# set term 1 from protocol static 
	aviva@RouterF# set term 1 then accept

Then apply this policy to the EBGP group:

	[edit protocols bgp group session-to-AS65505 ]
	aviva@RouterG# set export send-statics

Looking at the remote peer router, you now see routes learned from BGP:

	aviva@RouterD> show route
	inet.0: 11 destinations, 15 routes (11 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[Static/5] 1w0d 22:33:16
	 > to 172.19.121.1 via t1-0/0/3.0
	 [BGP/170] 00:07:27, localpref 100
	 AS path: 65500 I
	 > to 10.0.31.2 via t1-0/0/3.0
	10.0.24.2/32 *[Local/0] 1d 23:00:04
	 Reject
	10.0.29.0/24 *[Direct/0] 05:31:20
	 > via fe-0/0/1.0
	10.0.29.2/32 *[Local/0] 05:31:20
	 Local via fe-0/0/1.0
	10.0.31.0/24 *[Direct/0] 05:31:20
	 > via t1-0/0/3.0
	 [BGP/170] 00:05:02, localpref 100
	 AS path: 65500 I
	 > to 10.0.31.2 via t1-0/0/3.0
	10.0.31.1/32 *[Local/0] 05:31:20
	 Local via t1-0/0/3.0
	172.19.121.0/24 *[Direct/0] 4d 20:23:23
	 > via fe-0/0/0.0
	 [BGP/170] 16:47:48, localpref 100
	 AS path: 65505 I
	 > to 10.0.31.1 via t1-0/0/3.0
	172.19.121.116/32 *[Local/0] 4d 20:23:23
	 Local via fe-0/0/0.0
	192.168.14.1/32 *[Direct/0] 1w0d 22:33:44
	 > via lo0.0
	192.168.16.1/32 *[BGP/170] 00:05:02, localpref 100
	 AS path: 65500 I
	 > to 10.0.31.2 via t1-0/0/3.0

The BGP route entries start with [BGP/170], and the router has learned four routes from BGP:

10.0.31.0/24 is the subnet that the BGP session is running on.
192.168.16.1/32 is the peers loopback address.
0.0.0.0/0 is the default gateway address.
172.19.121.1 goes to another network internal to the lab.

Each BGP route also contains specific BGP information. localpref is the value of the BGP local preference (LOCAL_PREF) attribute, which is the metric that BGP assigns to the route. Because BGP learned these routes as a result of the send-statics policy, which you defined to export static routes into BGP, the JUNOS BGP software assigns them a local preference of 100 by default. If these routes were learned from BGP and already had a local preference value, that value would not be changed.

The AS path line lists all AS paths from the AS_PATH attribute, which shows the ASs through which the announcement for the prefix has traveled. The first AS in the path is the most recent AS, and the last AS is the originating AS. All routes in this output have come directly from the peer AS, so there is just one AS number in the path, AS 65500.

Following the path is the information from the BGP ORIGIN attribute, which indicates how BGP learned the prefix. The I here means that the prefix was learned from an IGP. Routes learned from an EGP peer would have an E, and those learned some other way would show as INCOMPLETE. The final line for each BGP route entry shows the next hop toward the destination and the interface the router will use to reach that next hop. Of the three BGP routes, the one to 192.168.16.1/32 is active and is marked with an asterisk.

Checking the BGP connection status on the peer, you now see the BGP routes:

	aviva@RouterD> show bgp summary
	Groups: 1 Peers: 1 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	inet.0 4 1 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	10.0.31.2 65500 721 718 0 0 5:57:50 1/4/0
	0/0/0

The Table section of the output shows that the inet.0 routing table has four BGP routes, which matches what we saw in the routing-table entries above. In the Peer section, the State column indicates that four BGP routes have been received from peer 10.0.31.2 and that one is active. Again, this corresponds with the routing-table entries.

Another way to find out about BGP routes is to look at what the routing table has received from BGP:

	aviva@RouterD> show route receive-protocol bgp 10.0.31.2
	inet.0: 11 destinations, 15 routes (11 active, 0 holddown, 0 hidden)
	 Prefix Nexthop 
MED Lclpref AS path
	 0.0.0.0/0 10.0.31.2 65500 I
	 10.0.31.0/24 10.0.31.2 65500 I
	 172.19.121.0/24 10.0.31.2 65500 I
	* 192.168.16.1/32 10.0.31.2 65500 I

Again, you see the four routes learned from BGP but in a format that is much easier to scan. For each route, you also see the value of four BGP attributes: NEXT_HOP, MED, LOCAL_PREF, and AS_PATH. The active route is marked with an asterisk.

Use the following command to see which routes the router has advertised:

	aviva@RouterF> show route advertising-protocol bgp 10.0.31.1
	inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
	 Prefix Nexthop MED Lclpref AS path
	* 0.0.0.0/0 Self I
	* 10.0.31.0/24 Self I
	* 172.19.121.0/24 Self I
	* 192.168.16.1/32 Self I

Configuring a BGP Session Between Routers in Two ASs

Problem

Solution

Discussion

Figure 13-1. EBGP network

See Also