PRESENTACIÓN DEL INFORME FINAL

Now that the configuration of our peers is complete, we would like to verify that the peer ses- sions are actually established and operational. There are three main commands available in the JUNOS software to accomplish this. Each provides different levels of information to the user. Let’s examine them in greater detail using Figure 8.12 as a guide.

Using local-address

It might seem strange to you that configuring an IBGP session requires more commands than an EBGP session does. After all, these peers are inside your own AS, and you trust their ser- vices, so it should be easy to set up. The truth is that it has nothing to do with trust, but rather with the method that BGP operates.

Each peer session requires that the peer’s IP address and AS number be explicitly configured in order for the session to become established. This information is exchanged in Open mes- sages during session establishment and must be agreed on for the session to come up. The set- ting of AS numbers is straightforward in the configuration. It is the IP address of the peer that causes a possible issue.

One basic principle of IP packets is that each contains a source and destination IP address. When a router generates an IP packet itself, the source IP address becomes the address of the outbound interface. For EBGP peers, this default behavior is fine because the peers are connected and are peering across that interface address. IBGP peers, on the other hand, are peering to the loopback address of the remote router. Let’s look at a small example.

Router A and Router B want to become IBGP peers using their loopback addresses of 1.1.1.1 and 2.2.2.2, respectively. When Router A sends its Open message to 2.2.2.2, the source IP address of the packet is the outgoing interface, say 10.10.10.1. Router B receives this Open message and compares the source address of the packet to its list of configured peers. Router B does not find a configuration for 10.10.10.1 and rejects the Open message. Router B performs this same pro- cess in reverse, with Router A rejecting the Open message from Router B. Two routers in this sit- uation remain in the BGP Active state forever, a clear indication of this problem.

The resolution to this issue is the local-address command. Its function is quite simple—it changes the source IP address of the BGP messages. In our example, Router A configures local-address 1.1.1.1 within its peer session to Router B. The BGP Open message now lists 1.1.1.1 as the source IP address of the packet. Router B receives the message and compares the source address to its list of configured peers. It now finds a match for Router A and responds to the Open message with a BGP Keepalive message. The two peers can now become estab- lished and advertise routing knowledge to each other.

show bgp summary

The show bgp summary command provides you with a good snapshot of the protocol on your router. This is often the command you use to determine if your peer sessions are established. The Shiraz router has configured two EBGP and two IBGP peers. The output below reveals the state of each peer:

user@Shiraz> show bgp summary Groups: 2 Peers: 4 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 12 12 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State 172.16.1.1 10 428 430 0 0 3:33:00 4/4/0 172.16.2.1 30 428 430 0 0 3:32:56 4/4/0 192.168.6.6 20 392 392 0 0 3:14:30 2/2/0 192.168.7.7 20 390 391 0 0 3:14:02 2/2/0

The command output is separated into a summary section and a detailed section for the spe- cific peers. Within the summary area, you can see the number of peer groups and peers config- ured. You also can determine some routing information for received BGP routes. In the case of Shiraz, 12 path advertisements have been received from peers, and all 12 are currently active and being used to forward user traffic.

The specific peer portion of the show bgp summary output contains the following fields:

Peer The configured peer address for each peer is listed in this field.

AS The configured AS number for each peer is listed here.

InPkt This field lists the total number of BGP messages received from the peer.

OutPkt This field lists the total number of BGP messages sent to each peer.

OutQ This field displays the number of BGP messages queued and waiting to be sent to a peer. This number is usually 0 because the queue is emptied quickly. A high and constant value in this column may indicate a problem with the peer session.

Flaps This field specifies the number of times the peer session has been closed and reestablished.

Last Up/Dwn This field displays the amount of time since the peer last changed state from Established to any other BGP state, or to Established from any other BGP state.

State This field shows the current BGP state of the peer. When the session reaches the Established state, routing information is displayed instead of a keyword. The routes are shown in the format <# Active>/<# Received</<# Damped>. For example, Shiraz has received four routes from its peer at 172.16.2.1. All four routes are currently active in the routing table and none of them have been damped.

352 Chapter 8  Border Gateway Protocol (BGP)

show bgp group

To view the configured peer groups on your router, use the show bgp group command. This displays each group’s name, type, and configured peers. The output from Shiraz shows:

user@Shiraz> show bgp group

Group Type: External Local AS: 20 Name: ebgp-peers

Total peers: 2 Established: 2 172.16.1.1+179

172.16.2.1+179

Route Queue Timer: unset Route Queue: empty Group Type: Internal AS: 20 Local AS: 20 Name: ibgp-peers

Total peers: 2 Established: 2 192.168.6.6+1910

192.168.7.7+1127

Route Queue Timer: unset Route Queue: empty

The IP addresses displayed are the configured BGP peer addresses. The additional informa- tion details the TCP port number used for the session. For example, Shiraz is peering with 172.16.2.1 and the remote port number is 179. This tells you that Shiraz established the peer session because it is using the well-known port for BGP. The situation is a bit different for the 192.168.6.6 peer, whose remote TCP port is 1910. The far-end router initiated the session to Shiraz using the well-known BGP port number.

show bgp neighbor

To receive the most detailed information about your BGP peers, use the show bgp neighbor command. The output from Shiraz for just the 172.16.1.1 peer is as follows:

user@Shiraz> show bgp neighbor 172.16.1.1

Peer: 172.16.1.1+179 AS 10 Local: 172.16.1.2+1028 AS 20 Type: External State: Established Flags: <>

Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None

Options: <Preference HoldTime PeerAS Refresh> Holdtime: 90 Preference: 170

Number of flaps: 0

Peer ID: 192.168.2.2 Local ID: 192.168.5.5 Active Holdtime: 90 Keepalive Interval: 30

Local Interface: so-0/0/1.0 NLRI advertised by peer: inet-unicast

NLRI for this session: inet-unicast Peer supports Refresh capability (2) Table inet.0 Bit: 10000

Send state: in sync Active prefixes: 4 Received prefixes: 4

Suppressed due to damping: 0

Last traffic (seconds): Received 13 Sent 13 Checked 13

Input messages: Total 438 Updates 4 Refreshes 0 Octets 8473 Output messages: Total 440 Updates 4 Refreshes 0 Octets 8526 Output Queue[0]: 0

The output of this command contains a wealth of information, including the following:

 The peer address and AS number of the peer

 _{Configured hold time (Holdtime) and negotiated hold time (Active Holdtime)}  _{Router ID values for each peer}

 _{The number of active and received routes}

 The number of packets and the amount of octets sent to and received from the peer

Viewing Routing Knowledge

BGP routers by default advertise only active BGP routes in the routing table. This creates a sort of chicken-and-egg problem. A route can appear in the routing table as a BGP route only if it is received from a BGP peer, but a BGP peer can only advertise a route if it’s already in the rout- ing table as a BGP route.