Initial IBGP Peering | JNCIP: Juniper Networks Certified Internet Professional Study Guide

For proper operation, the IBGP protocol requires a full mesh of peering sessions or the use of route reflection and/or confederations. Our first IBGP example will involve a conventional full IBGP mesh, with peering established between router loopback addresses for maximum stability.

You begin your IBGP configuration example with the network topology shown in Figure 5.1, which recounts the multi-level IS-IS configuration left over from Chapter 4, “IS-IS Configuration and Testing.” You will use this topology as the starting point for your IBGP configuration tasks.

click to expand
Figure 5.1: IBGP full mesh peering

Referring to Figure 5.1, you can see that each router in the test bed will require six IBGP peering definitions to ensure the requisite full IBGP mesh, and that each router has a single static route that is to be advertised into IBGP to test connectivity and forwarding paths. To complete this configuration example, your IBGP configuration must meet the following criteria:

Ensure that the loss of any individual interface does not disrupt a router’s IBGP sessions.
All routers must log IBGP session establishment and tear down actions to a file called rn-bgp where n equals the router number.
Advertise the 192.168.x/24 static routes into IBGP.
Your network must use optimal forwarding paths.
Your AS number is 65412.

You begin by configuring the IBGP peering sessions on r1. The following commands define the local AS number:

[edit routing-options] lab@r1# set autonomous-system 65412

The next set of commands creates a BGP peer group called internal, and defines the IBGP peering sessions to the other six routers based on their loopback addresses. Loopback-based peering is required to guarantee that the loss of an individual interface will not disrupt your IBGP sessions:

[edit routing-options] lab@r1# top [edit] lab@r1# edit protocols bgp group internal [edit protocols bgp group internal] lab@r1# set type internal [edit protocols bgp group internal] lab@r1# set local-address 10.0.6.1 [edit protocols bgp group internal] lab@r1# set neighbor 10.0.6.2

The last command should be repeated using each of the remaining router’s lo0 addresses, with the results being the peering configuration shown next:

[edit protocols bgp group internal] lab@r1# show type internal; local-address 10.0.6.1; neighbor 10.0.6.2; neighbor 10.0.3.3; neighbor 10.0.3.4; neighbor 10.0.3.5; neighbor 10.0.9.6; neighbor 10.0.9.7;

Use of the local-address option is critical here, because failing to include this knob for a given IBGP router pairing will result in the inability to establish the loopback-based peering session. Though such a session can be established when just one of the paired routers makes use of this option, its inclusion on all routers is highly recommended so that either peer can initiate the IBGP session.

The following commands address the session logging aspects of the example by configuring the tracing of BGP connection state transitions to a file called rn-bgp. Using the log-updown option under [edit protocols bgp] would result in connection state changes being written to the /var/log/messages file, which would violate the restrictions of this example. It is also suggested that you configure the trace parameters at the group or neighbor level, as a global application could result in the unintentional logging of EBGP connection state changes in a later lab scenario:

[edit protocols bgp group internal] lab@r1# set traceoptions file r1-bgp [edit protocols bgp group internal] lab@r1# set traceoptions flag state detail

The completed tracing stanza is now shown:

[edit protocols bgp group internal] lab@r1# show traceoptions file r1-bgp; flag state detail;

IBGP Policy

The use of policy to effect route redistribution and to manipulate route attributes has been demonstrated in Chapters 3 and 4 for the RIP, OSPF, and IS-IS protocols. The use of policy for BGP is similar to the examples provided for other protocols, but you should consider that with BGP, policies can be applied as both import and export, and can be applied at the global, group, or neighbor levels. Many candidates fail to recognize that JUNOS software executes the most specific policy only, which means that the presence of a neighbor policy will exempt that neighbor from the actions specified in any group or global policy application.

You should recall that the default policy for BGP is to accept all received routes that pass incoming sanity checks (no AS path loops), and to advertise all active BGP routes to all BGP peers while obeying IBGP rules that prevent a BGP speaker from re-advertising IBGP-learned routes to other IBGP speakers. (The use of route reflection mitigates these restrictions, as discussed in the “IBGP Route Reflection” section later in this chapter.)

Tip

BGP policy mistakes often occur when an exam candidate attempts to link multiple policies together but fails to notice that one or more of these policies make use of an accept action, which when encountered causes all remaining policy processing to terminate. The same thing can happen with multiterm policies, but seeing multiple terminating actions in the same policy statement will often provide a clue as to what is wrong. If you plan on using one policy to, say, set local preference, and another to set the BGP next hop, it is suggested that you avoid the use of the accept action until the last policy, or that you rely on the default BGP policy of accepting all BGP routes so that your policies do not require an explicit accept action. Advertising non-BGP derived routes will require an explicit accept action because the default BGP policy will not accept these routes.

Policy in BGP is used to redistribute routes and to set various BGP and non-BGP attributes such as local preference, Multi-Exit Discriminator (MED), communities, global preference, etc. Various BGP policy applications will be provided throughout this chapter and Chapter 6, “EBGP Configuration and Testing.”

The static route definition and policy statement shown next define the 192.168.10/24 static route and the policy needed to selectively match on, and then accept, this prefix for redistribution into another routing protocol. The use of reject as a next hop for the static route is suggested, because this will allow pings and traceroutes to complete with a "destination unreachable" message:

[edit] lab@r1# show routing-options static route 10.0.200.0/24 next-hop 10.0.1.102; route 192.168.10.0/24 reject; [edit] lab@r1# show policy-options policy-statement ibgp term 1 {    from {        protocol static;        route-filter 192.168.10.0/24 exact;    }    then accept;  }

The ibgp policy is then applied as export to the internal peer group, which puts it into effect for all six of r1’s IBGP peers. In this example, you could also have applied the policy globally, or multiple times—once under each peer—if you are so inclined to practice your typing skills:

[edit] lab@r1# set protocols bgp group internal export ibgp

The initial BGP configuration for r1 is now displayed:

[edit] lab@r1# show protocols bgp group internal {      type internal;      traceoptions {         file r1-bgp;          flag state detail;     }     local-address 10.0.6.1;     export ibgp;      neighbor 10.0.6.2;      neighbor 10.0.3.3;      neighbor 10.0.3.4;      neighbor 10.0.3.5;      neighbor 10.0.9.6;      neighbor 10.0.9.7; }

You will need to replicate the BGP, static route, Autonomous System (AS) number, and IBGP export policy–related configuration on the remaining routers before proceeding to the next section. The use of load merge terminal for the BGP stanza is highly recommended, considering that all routers require the same basic configuration. You will need to edit the local address and neighbor statements to reflect the particulars of each router before performing the merge operation, however. To simplify the edits associated with the cut-and-paste approach, you can include a peering session to the local router so that all seven routers use a common list that includes all routers in the test bed. This will result in an active connection on each router because you cannot establish an IBGP session to yourself.

Verify Initial IBGP Peering and Policy

After committing the initial IBGP configuration on all seven routers, you confirm that the BGP sessions have been correctly established:

[edit] lab@r1# run show bgp summary Groups: 1 Peers: 6 Down peers: 0 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 6          6          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.3.3        65412         32         33       0       0       15:08 1/1/0                 0/0/0 10.0.3.4        65412         30         30       0       0       13:41 1/1/0                 0/0/0 10.0.3.5        65412         28         28       0       0       12:49 1/1/0                 0/0/0 10.0.6.2        65412         38         39       0       0       17:44 1/1/0                 0/0/0 10.0.9.6        65412         25         25       0       0       11:12 1/1/0                 0/0/0 10.0.9.7        65412         23         23       0       0       10:05 1/1/0                 0/0/0

The presence of six IBGP sessions, all in the established state, along with the peer references to lo0 addresses, indicates that the initial IBGP peering sessions have been correctly established. You can also see that each session is reporting one received route, which is also active, so indications are also positive with regard to your IBGP export policy and static route definitions. To confirm proper IBGP route advertisement, you examine the BGP routes on r2:

[edit] lab@r2# run show route protocol bgp inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24     *[BGP/170] 00:21:51, MED 0, localpref 100, from 10.0.6.1                        AS path: I                      > to 10.0.4.5 via fe-0/0/3.0 192.168.30.0/24     *[BGP/170] 00:19:02, MED 0, localpref 100, from 10.0.3.3                        AS path: I                        to 10.0.4.9 via fe-0/0/1.0                      > to 10.0.4.1 via fe-0/0/2.0 192.168.40.0/24     *[BGP/170] 00:17:45, MED 0, localpref 100, from 10.0.3.4                        AS path: I                      > to 10.0.4.9 via fe-0/0/1.0                        to 10.0.4.1 via fe-0/0/2.0 192.168.50.0/24     *[BGP/170] 00:16:53, MED 0, localpref 100, from 10.0.3.5                        AS path: I                        to 10.0.4.9 via fe-0/0/1.0                      > to 10.0.4.1 via fe-0/0/2.0 192.168.60.0/24     *[BGP/170] 00:15:15, MED 0, localpref 100, from 10.0.9.6                        AS path: I                        to 10.0.4.9 via fe-0/0/1.0                      > to 10.0.4.1 via fe-0/0/2.0 192.168.70.0/24     *[BGP/170] 00:14:09, MED 0, localpref 100, from 10.0.9.7                        AS path: I                      > to 10.0.4.9 via fe-0/0/1.0                        to 10.0.4.1 via fe-0/0/2.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

The output indicates that r2 has learned the 192.168.x/24 routes from the remote routers through IBGP. Because r2 receives two equal-cost next hops for the IS-IS level 1 default, many of the BGP routes show two viable IS-IS forwarding next hops, as expected. Displaying the routes that are being sent or received from various IBGP peers can also test your IBGP export policy:

lab@r1> show route receive-protocol bgp 10.0.9.7 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.70.0/24 10.0.9.7                 0         100 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) lab@r1> show route advertising-protocol bgp 10.0.9.7 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24 Self                     0         100 I

The results confirm the correct IBGP export policy on r1 and r7, because it confirms that both are correctly exporting their respective static routes. The next confirmation step is to conduct a few traceroutes to verify that all is well with the forwarding paths through your AS. The nature of IS-IS routing may cause packets to incur an "extra hop" now and then (due to level 1 routers always choosing the metrically closest attached router and the way summaries are being injected into the backbone), so the presence of a less-than-ideal path does not automatically indicate problems with BGP forwarding paths:

[edit] lab@r7# run traceroute 192.168.10.1 traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.346 ms 0.259 ms 0.218 ms  2 10.0.2.10 (10.0.2.10) 0.297 ms 0.252 ms 0.234 ms  3 10.0.4.10 (10.0.4.10) 0.406 ms 0.676 ms 0.375 ms  4 10.0.4.5 (10.0.4.5) 0.359 ms 0.684 ms 0.379 ms  5 10.0.4.5 (10.0.4.5) 0.353 ms !H 0.670 ms !H 0.372 ms !H [edit] lab@r7# run traceroute 192.168.20.1 traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.333 ms 0.250 ms 0.216 ms  2 10.0.2.10 (10.0.2.10) 0.275 ms 0.250 ms 0.236 ms  3 10.0.4.10 (10.0.4.10) 0.667 ms 0.679 ms 0.377 ms  4 10.0.4.10 (10.0.4.10) 0.362 ms !H 0.681 ms !H 0.371 ms !H

The forwarding path from r7 to the 192.168.10/24 and 192.168.20/24 prefixes is working as expected. An extra hop is observed when forwarding to 192.168.10/24 due to r5’s desire to forward all packets that match the summary route for area 49.0003 to r4, as shown by the presence of the 10.0.2.10 hop in both traceroutes. This behavior is expected due to r4 advertising a lower metric for its as0 interface when compared to r3’s metric for its at-0/1/0.35 interface. You will recall that in the IS-IS case study there was no requirement that r5 be able to load balance to the 10.0.4/22 summary route, and even if it could, the hashing function used to select one of the two equal-cost next hops would likely just reverse the situation at best.

Knowing when forwarding inefficiencies are the result of configuration mistakes, rather than normal and expected protocol behavior, is a valuable skill that can prevent you from wasting time trying to resolve “issues” that cannot be fixed. To confirm IBGP connection state logging, you monitor the log file before or after you have cleared your IBGP sessions. You should observe output similar to that shown here:

[edit] lab@r1# run clear bgp neighbor Cleared 6 connections [edit] lab@r1# run monitor start r1-bgp [edit] lab@r1# ] *** r1-bgp *** Jun 12 16:51:22 bgp_event: peer 10.0.3.3 (Internal AS 65412) old state Active  event ConnectRetry new state Connect Jun 12 16:51:22 bgp_event: peer 10.0.3.3 (Internal AS 65412) old state Connect  event Open new state OpenSent Jun 12 16:51:22 bgp_event: peer 10.0.3.3 (Internal AS 65412) old state OpenSent  event RecvOpen new state OpenConfirm Jun 12 16:51:22 bgp_read_message: 10.0.3.3 (Internal AS 65412): 0 bytes buffered Jun 12 16:51:22 bgp_event: peer 10.0.3.3 (Internal AS 65412) old state  OpenConfirm event RecvKeepAlive new state Established Jun 12 16:51:26 bgp_event: peer 10.0.3.4 (Internal AS 65412) old state Active  event ConnectRetry new state Connect Jun 12 16:51:26 bgp_event: peer 10.0.3.4 (Internal AS 65412) old state Connect  event Open new state OpenSent Jun 12 16:51:26 bgp_event: peer 10.0.3.4 (Internal AS 65412) old state OpenSent  event RecvOpen new state OpenConfirm Jun 12 16:51:26 bgp_read_message: 10.0.3.4 (Internal AS 65412): 0 bytes buffered Jun 12 16:51:26 bgp_event: peer 10.0.3.4 (Internal AS 65412) old state  OpenConfirm event RecvKeepAlive new state Established

This output indicates that IBGP connection state tracing has been properly configured. The various confirmation checks performed thus far indicate that you have met all objectives for the IBGP full mesh configuration example.