Initial EBGP Peering
|
|
The overall operation of your network at the end of this chapter will depend on the complex interplay of your IGP, IBGP, EBGP, and routing policy configurations. Their interdependency creates a sequencing problem because an EBGP peering session may be useless until you apply the appropriate EBGP policy and IBGP policy modifications to your network. Dealing with your EBGP peering definitions, your EBGP policy statements, and any required IBGP policy modifications all at once is a reasonable thing to do, but there is also merit in addressing these tasks sequentially. In the sequential approach, you first concentrate on getting your EBGP peering sessions up, then worry about your EBGP policy, and then deal with any IBGP modifications necessitated by the relative success of the first two tasks. This chapter is organized according to the latter philosophy, in part because the author feels it is a sound approach, but also because it simplifies the chapter’s organization.
You will therefore begin with the configuration and verification of all the EBGP peering sessions in your network. After the EBGP peering sessions are operational, you will add a variety of EBGP import and export policy statements. Based on the overall operation of your EBGP policy, you will next decide what, if any, IBGP policy modifications are needed to achieve the synergistic operation that is required in an SP network. We start by reviewing the state of your network at the conclusion of the IBGP chapter’s case study, which is shown in Figure 6.1. You will use this topology as the starting point for your EBGP configuration tasks.
Figure 6.1: IBGP case study topology
You may want to review the case study configuration requirements from Chapter 5 to reacquaint yourself with the network that will now serve as the basis of your EBGP configuration activities. Figure 6.2 provides the information you will need to establish your EBGP peering sessions. The loopback addresses of all EBGP peers can be pinged (when routing policy is working), using a target address that is based on the prefix range owned by the remote AS in the form of x.x.0.1, such that C1’s lo0 address will be 200.200.0.1, for example. In the actual JNCIP examination, the EBGP peer routers are not accessible by the candidate. To closely approximate the actual examination environment, this chapter does not detail the specifics of the EBGP peer router configurations. In general, each EBGP peer has the necessary EBGP peering configuration and one or more static routes that are advertised once the EBGP session is established. Some of these routes may consist of Martians or other prefixes that should be filtered at the edge of your autonomous system as specified by the details of your test scenario.
Figure 6.2: EBGP topology
You will be able to follow the details of this chapter without the benefit of the extra routers that make up the various EBGP peers that are shown in Figure 6.1, but for maximum benefit at least some of the peers should be present in your test bed. This author was able to reduce the number of stand-alone EBGP routers needed by using multiple BGP routing instances.
As shown in Figure 6.2, your AS will now form EBGP sessions to various Customer, Transit, and Peer routers identified respectively on the figure as C, T, and P routers. To complete this section, you must configure your network to meet the following EBGP peering criteria:
-
Establish all EBGP peering sessions shown with the following criteria:
-
You must be able to load balance over the two links connecting r4 to C1.
-
You must be able to load balance from r3 to T1 and T2.
-
The P1 router is configured with a single neighbor statement. You must configure r1 and r2 to peer with P1 while ensuring that the failure of either r1 or r2 does not result in chronic loss of the routes advertised by P1.
-
The T2 router uses authentication with secret ebgp.
-
-
You must not view or modify the configurations of your EBGP peers.
-
Static routes are permitted to accommodate EBGP load balancing only. These routes cannot be redistributed into your network.
C2 EBGP Peering
You begin by configuring the EBGP peering session to C2, because this session represents the most straightforward of the EBGP peering tasks. The following commands create a new peer group called c2 and correctly configure the group to peer with router C2:
[edit] lab@r7# edit protocols bgp group c2 [edit protocols bgp group c2] lab@r7# set type external neighbor 172.16.0.26 [edit protocols bgp group c2] lab@r7# set peer-as 65020
The new peer group is displayed:
[edit protocols bgp group c2] lab@r7# show type external; peer-as 65020; neighbor 172.16.0.26;
| Note | To save time, you can omit the type statement in an EBGP peer group because the presence of the peer-as statement implies an external peer type. |
After committing, the EBGP session status is analyzed:
[edit] lab@r7# run show bgp summary Groups: 2 Peers: 3 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 8 7 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.26 65020 0 0 0 0 5 Idle 10.0.3.5 65001 184 184 0 0 2:14:17 6/6/0 0/0/0 10.0.9.6 65001 25754 189 0 0 2:17:08 1/2/0 0/0/0
The session’s idle status normally indicates that the router has no idea how to go about establishing the BGP session. This is a condition that typically results from not being able to route a connection request packet to the peer. This is confirmed with a quick ping test:
[edit] lab@r7# run ping 172.16.0.26 PING 172.16.0.26 (172.16.0.26): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ^C --- 172.16.0.26 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
The results confirm the routing problem. Because the EBGP peering address should be associated with a directly connected interface route, the status of r7’s fe-0/3/2 interface is checked:
[edit] lab@r7# run show interfaces fe-0/3/2 terse Interface Admin Link Proto Local Remote fe-0/3/2 up up
The output confirms that the problem is caused by the lack of IP address configuration on r7’s fe-0/3/2 interface. The correct address is now assigned and the change is committed:
[edit interfaces fe-0/3/2] lab@r7# set unit 0 family inet address 172.16.0.25/30 [edit] lab@r7# commit commit complete
After waiting for a little while (30 seconds or so), the EBGP session status is again displayed:
[edit] lab@r7# run show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 18 17 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.26 65020 6 13 0 0 0 10/10/0 0/0/0 10.0.3.5 65001 194 195 0 0 2:21:51 6/6/0 0/0/0 10.0.9.6 65001 25764 200 0 0 2:24:42 1/2/0 0/0/0
The r7-to-C2 EBGP session has been established, and the display indicates the reception of 10 routes from C2 and that all of them have been installed as active. You just have to dig that! It is not a bad idea to also display the routes being received for each EBGP peering session because your future policy configuration will be impacted by what is, or is not, being advertised by your external peers:
[edit] lab@r7# run show route receive-protocol bgp 172.16.0.26 inet.0: 48 destinations, 50 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 172.16.0.26 0 65020 62 39 I 64.0.0.0/7 172.16.0.26 0 65020 I 201.201.0.64/26 172.16.0.26 0 65020 I 201.201.1.0/24 172.16.0.26 0 65020 I 201.201.2.0/24 172.16.0.26 0 65020 I 201.201.3.0/24 172.16.0.26 0 65020 I 201.201.4.0/24 172.16.0.26 0 65020 I 201.201.5.0/24 172.16.0.26 0 65020 I 201.201.6.0/24 172.16.0.26 0 65020 I 201.201.7.0/24 172.16.0.26 0 65020 I
An interesting, if somewhat motley, collection of routes is being advertised by C2. The listing includes several 201.201/16–related prefixes, a default route, and a few other “nasties” that might necessitate future policy action to be sure.
C1 EBGP Peering
You now configure the r4-to-C1 peering session. In order to load balance over the two physical links, you will need to define a loopback-based peering session and the static routing needed to resolve the lo0 peering address to the appropriate physical next hops. This peer group also requires the multihop option to support the indirect lo0-based peering. The following commands create and configure the c1 peer group on r4:
[edit protocols bgp group c1] lab@r4# set type external neighbor 200.200.0.1 [edit protocols bgp group c1] lab@r4# set peer-as 65010 [edit protocols bgp group c1] lab@r4# set multihop
The c1 group is displayed:
[edit protocols bgp group c1] lab@r4# show type external; multihop; peer-as 65010; neighbor 200.200.0.1;
You next configure and display the static routing needed to resolve C1’s loopback address. The use of brackets allows you to specify the multiple next hops that are associated with the static route’s destination on a single command line, if so desired:
[edit routing-options static] lab@r4# set route 200.200.0.1 next-hop [172.16.0.6 172.16.0.10] [edit routing-options static] lab@r4# show route 10.0.200.0/24 { next-hop 10.0.1.102; no-readvertise; } route 192.168.40.0/24 reject; route 200.200.0.1/32 next-hop [ 172.16.0.6 172.16.0.10 ]; To complete the configuration of r4, you must assign the correct addresses to its fe-0/0/0 and fe-0/0/2 interfaces:
[edit interfaces] lab@r4# set fe-0/0/0 unit 0 family inet address 172.16.0.5/30 [edit interfaces] lab@r4# set fe-0/0/2 unit 0 family inet address 172.16.0.9/30
The status of the new peering session is displayed after the changes have been committed on r4:
[edit] lab@r4# run show bgp summary Groups: 3 Peers: 5 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 10 7 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 200.200.0.1 65010 0 8 0 0 3:03 Active 10.0.2.9 65001 353 25780 0 0 2:51:20 3/4/0 0/0/0 10.0.3.3 65000 25872 5203 0 0 2:49:16 1/2/0 0/0/0 10.0.6.1 65000 339 25779 0 0 2:49:20 1/2/0 0/0/0 10.0.6.2 65000 343 25780 0 0 2:50:31 2/2/0 0/0/0
| Tip | Due to the use of a fixed 30-second retry timer, BGP sessions can take what may seem an inordinate amount of time to become established. After making changes to a BGP peering configuration, you should make it a point to wait a minute or two before deciding whether the problem has been fixed. Some candidates are so “hyped-up” that they may alter a newly modified (and perhaps working) configuration, and in so doing break it again, because their instant gratification timer expires before the BGP retry time-out. This condition is especially true if the changes affect your IGP, as is the case when restarting rpd or clearing adjacencies, because BGP will now have to wait for the IGP to converge before it can even get started. |
Troubleshoot EBGP Peering
The active indication in the previous screen capture indicates that r4 is actively trying to establish the EBGP session to C1, but considering that the condition has persisted for over a minute in this author’s test bed, the prognosis for this connection suddenly entering the established state is starting to look mighty grim. Ping testing is used to determine if the problem relates to the physical layer, interface addressing, or static route definitions:
[edit] lab@r4# run ping 172.16.0.6 count 1 PING 172.16.0.6 (172.16.0.6): 56 data bytes 64 bytes from 172.16.0.6: icmp_seq=0 ttl=255 time=0.596 ms --- 172.16.0.6 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.596/0.596/0.596/0.000 ms [edit] lab@r4# run ping 172.16.0.10 count 1 PING 172.16.0.10 (172.16.0.10): 56 data bytes 64 bytes from 172.16.0.10: icmp_seq=0 ttl=255 time=0.599 ms --- 172.16.0.10 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.599/0.599/0.599/0.000 ms
The 172.16.0.4/30 and 172.16.0.8/30 subnets appear to be functional, which vindicates your interface configuration and their physical and link-level operation. You now test reachability to C1’s loopback address:
[edit] lab@r4# run ping 200.200.0.1 count 1 PING 200.200.0.1 (200.200.0.1): 56 data bytes 64 bytes from 200.200.0.1: icmp_seq=0 ttl=255 time=0.605 ms --- 200.200.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.605/0.605/0.605/0.000 ms
Because the r4-to-C1 peering session must be established between loopback addresses, it is a good idea to evoke the local switch in order to source the ping from r4’s loopback address.
This confirms that C1 also has the static routing needed to support the lo0-based peering session in place:
[edit] lab@r4# run ping 200.200.0.1 local 10.0.3.4 count 1 PING 200.200.0.1 (200.200.0.1): 56 data bytes 64 bytes from 200.200.0.1: icmp_seq=0 ttl=255 time=0.612 ms --- 200.200.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.612/0.612/0.612/0.000 ms
All four of the ping tests succeed, which provides a strong indication that the problem relates to the EBGP peering definition for C1 on r4. Although the astute reader will likely already know what is wrong with r4’s configuration, an example of EBGP tracing is provided to demonstrate its utility in times like these. The following highlighted capture shows the tracing configuration that has been added to r4; note that the tracing is applied only to the c1 peer group to minimize trace output clutter and the router’s processing burden:
[edit protocols bgp group c1] lab@r4# show type external; traceoptions { file c1; flag open detail; } multihop; peer-as 65010; neighbor 200.200.0.1; Key portions of the trace output are shown next. Can you spot the problem?
[edit] lab@r4# *** c1 *** Jun 18 12:36:54 bgp_send: sending 45 bytes to 200.200.0.1 (External AS 65010) Jun 18 12:36:54 Jun 18 12:36:54 BGP SEND 172.16.0.5+1074 -> 200.200.0.1+179 Jun 18 12:36:54 BGP SEND message type 1 (Open) length 45 Jun 18 12:36:54 BGP SEND version 4 as 65412 holdtime 90 id 10.0.3.4 parmlen 16 Jun 18 12:36:54 MP capability AFI=1, SAFI=1 Jun 18 12:36:54 Refresh capability, code=128 Jun 18 12:36:54 Refresh capability, code=2 Jun 18 12:36:54 Jun 18 12:36:54 BGP RECV 200.200.0.1+179 -> 172.16.0.5+1074 Jun 18 12:36:54 BGP RECV message type 1 (Open) length 29 Jun 18 12:36:54 BGP RECV version 4 as 65010 holdtime 90 id 200.200.0.1 parmlen 0 Jun 18 12:36:54 Jun 18 12:36:54 BGP RECV 200.200.0.1+179 -> 172.16.0.5+1074 Jun 18 12:36:54 BGP RECV message type 3 (Notification) length 21 Jun 18 12:36:54 BGP RECV Notification code 2 (Open Message Error) subcode 5 (authentication failure) *** monitor and syslog output disabled, press ESC-Q to enable ***
If you noted the fact that r4 is incorrectly sourcing its TCP connection from its physical interface address, as opposed to its loopback address, then you are spot on. The last few lines of trace output indicate that C1 is rejecting r4’s open message because it is presenting itself as 172.16.0.5, which is an undefined peer. Because BGP was originally intended to operate between autonomous networks, the protocol is designed to require explicit declaration of peers as a means for enhancing security, in that the lack of a corresponding peer statement will prevent the establishment of unauthorized BGP sessions. This aspect of EBGP accounts for the authentication-related error message generated when an unknown peer attempts to establish a BGP session.
JUNOS software supports BGP peer declarations that are based on address blocks, instead of host addresses using the allow keyword. For example, specifying allow 10/8 would permit BGP sessions from any BGP speaker with a 10.x.x.x address while "promiscuous" operation can be achieved by specifying an address of 0.0.0.0. Normally the passive keyword is used in conjunction with the allow keyword because the lack of explicit peer definitions prevents the local router from being able to successfully initiate BGP connections.
Because the local-address statement has "conveniently" been omitted from C1’s configuration, you must include this statement on r4 or the session will never be established. The following configuration adds the required local-address statement, and deletes the trace configuration because its purpose has been served:
[edit protocols bgp group c1] lab@r4# delete traceoptions [edit protocols bgp group c1] lab@r4# set local-address 10.0.3.4
The modified stanza is displayed next with the change highlighted:
[edit protocols bgp group c1] lab@r4# show type external; multihop; local-address 10.0.3.4; peer-as 65010; neighbor 200.200.0.1;
The status of the C1 EBGP session is again displayed a minute or so after you have committed the changes on r4:
[edit protocols bgp group c1] lab@r4# run show bgp summary Groups: 3 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 22 19 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 200.200.0.1 65010 5 9 0 0 15 12/12/0 0/0/0 10.0.2.9 65001 518 25947 0 0 4:13:45 3/4/0 0/0/0 10.0.3.3 65000 26037 5370 0 0 4:11:41 1/2/0 0/0/0 10.0.6.1 65000 504 25946 0 0 4:11:45 1/2/0 0/0/0 10.0.6.2 65000 508 25947 0 0 4:12:56 2/2/0 0/0/0
Good, the r4–C1 EBGP session has been established. You decide to display the routes being received from C1 to confirm what you are dealing with and whether the correct load-balancing behavior has been achieved:
[edit protocols bgp group c1] lab@r4# run show route receive-protocol bgp 200.200.0.1 inet.0: 48 destinations, 52 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 32.0.0.0/16 200.200.0.1 0 65010 420 I 200.200.0.0/24 200.200.0.1 0 65010 I 200.200.0.0/28 200.200.0.1 0 65010 I 200.200.1.0/24 200.200.0.1 0 65010 I 200.200.2.0/24 200.200.0.1 0 65010 I 200.200.3.0/24 200.200.0.1 0 65010 I 200.200.4.0/24 200.200.0.1 0 65010 I 200.200.5.0/24 200.200.0.1 0 65010 I 200.200.5.128/25 200.200.0.1 0 65010 I 200.200.6.0/24 200.200.0.1 0 65010 I 200.200.7.0/24 200.200.0.1 0 65010 I
As with C2, there appears to be an interesting assortment of routes being advertised by C1— you will revisit the specifics of these routes later when creating and applying your EBGP policy. To confirm load balancing, verify that both r4’s fe-0/0/0 and fe-0/0/2 interfaces are listed as the forwarding next hops for the routes that are learned from C1:
[edit protocols bgp group c1] lab@r4# run show route protocol bgp 200.200.0.0/24 inet.0: 48 destinations, 52 routes (48 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.0.0/24 *[BGP/170] 00:08:08, MED 0, localpref 100, from 200.200.0.1 AS path: 65010 I > to 172.16.0.6 via fe-0/0/0.0 to 172.16.0.10 via fe-0/0/2.0 200.200.0.0/28 *[BGP/170] 00:08:08, MED 0, localpref 100, from 200.200.0.1 AS path: 65010 I > to 172.16.0.6 via fe-0/0/0.0 to 172.16.0.10 via fe-0/0/2.0
Both forwarding next hops are correctly displayed, indicating that the r4–C1 EBGP session is now operating correctly.
P1 EBGP Peering
This section deals with the configuration of the EBGP session between r1, r2, and the P1 router. This task is made complex by the indication that P1 is configured with a single EBGP peering definition and the requirement that the failure of either r1 or r2 should not result in a long-term loss of P1’s routes within your network. Because BGP does not support point-to-multipoint modes of operation, peering two routers to a machine configured with a single neighbor statement may seem to verge on the impossible.
To get the ball rolling, the following configuration is committed on r1 to reverse engineer P1’s address assignment and BGP neighbor definition. The neighbor address has been chosen at random from the 10.0.5/24 subnet to allow the trace-related configuration to commit.
[edit protocols bgp group p1] lab@r1# show type external; traceoptions { file p1; flag open detail; } peer-as 65050; neighbor 10.0.5.10; Unfortunately, the trace output affords you little help in this case:
Jun 18 21:58:35 bgp_connect_complete: error connecting to 10.0.5.10 (External AS 65050): Socket is not connected
Looks like it may be time to throw r1’s fe-0/0/0 interface into promiscuous mode to see if anything of interest is hitting the wire:
[edit] lab@r1# run monitor traffic interface fe-0/0/0 Listening on fe-0/0/0 22:09:50.950616 Out VID [7: 150] 10.0.5.1 > 224.0.0.18: ip-proto-112 20 . . . 22:09:58.020679 Out VID [7: 150] 10.0.5.1 > 224.0.0.18: ip-proto-112 20 22:09:58.351962 In VID [0: 150] 10.0.5.254.1045 > 10.0.5.200.bgp: S 3318404620:3318404620(0) win 16384 <mss 1456,nop,wscale 0,nop,nop,timestamp 1984619 0> [tos 0xc0] 22:09:59.030732 Out VID [7: 150] 10.0.5.1 > 224.0.0.18: ip-proto-112 20 . . .
The highlighted entry provides the information being sought. The output confirms that P1’s address is 10.0.5.254, and that it has been configured to peer with 10.0.5.200, which is the VRRP virtual IP (VIP) address shared by r1 and r2. The requirement that both r1 and r2 should peer to a router with a single neighbor statement, and that the failure of either r1 or r2 should not disrupt this peering session, suddenly becomes feasible when illuminated by this newfound information.
To test the hypothesis that P1 is supposed to (or even can) peer with the VIP address shared by r1 and r2, you make the highlighted changes to r1’s configuration:
[edit protocols bgp group p1] lab@r1# show type external; traceoptions { file p1; flag open detail; } local-address 10.0.5.200; peer-as 65050; neighbor 10.0.5.254; A few minutes after the changes are committed, the session is still down so something else must be amiss. Analyzing the p1 trace file uncovers another clue:
Jun 18 22:28:54 task_addr_local: task BGP_65050.10.0.5.254 address 10.0.5.200: Can't assign requested address Jun 18 22:28:54 bgp_select_myaddr: peer 10.0.5.254 (External AS 65050) local address 10.0.5.200 unavailable, connection failed
Seems like r1 is having trouble sourcing packets from its VIP address. Displaying the VRRP status confirms that it is the current master, however:
[edit protocols bgp group p1] lab@r1# run show vrrp summary Interface Unit Group Type Address Int state VR state fe-0/0/0 0 1 lcl 10.0.5.1 up master vip 10.0.5.200
Any ideas? Another invaluable clue is obtained by r2’s indication that pings to the VIP address fail:
[edit] lab@r2# run ping 10.0.5.200 count 1 PING 10.0.5.200 (10.0.5.200): 56 data bytes ^C --- 10.0.5.200 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss
Examining r2’s ARP cache confirms that r1 has responded to ARP request for the VIP address:
[edit] lab@r2# run show arp | match 10.0.5.200 00:00:5e:00:01:01 10.0.5.200 10.0.5.200 fe-0/0/0.0
At this point, you should recall that, according to the VRRP standard, with the exception of ARP replies, a router can respond to traffic addressed to the VIP only when it is the VRRP group’s master and when the VIP is actually assigned to one of its interfaces. You should also recall that JUNOS software provides a knob that allows a router to respond to traffic sent to the VIP address, even though this address is not assigned to any of its interfaces. This sounds like an option worth exploring, so the following change is committed:
[edit interfaces fe-0/0/0 unit 0 family inet address 10.0.5.1/24] lab@r1# set vrrp-group 1 accept-data
A minute or so later, the BGP session status on r1 is again displayed:
[edit] lab@r1# run show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 38 26 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.3.3 65000 46 40 0 2 17:12 3/8/0 0/0/0 10.0.3.4 65000 48 39 0 2 17:12 13/20/0 0/0/0 10.0.5.254 65050 19 26 0 0 6:03 10/10/0 0/0/0
Excellent! The change to the VRRP configuration has done the trick. You will need to define a similar p1 peering group on r2, being sure to also add the accept-data option to r2’s VRRP configuration. You should also remove the BGP tracing configuration from r1 before proceeding. After committing the changes on r2, deactivate r1’s fe-0/0/0 interface to confirm that the VRRP mastership changes and that the EBGP session follows the VIP over to r2. Before deactivating r1’s interface, the VRRP status and P1 peering session are displayed on r2:
lab@r2# run show vrrp summary Interface Unit Group Type Address Int state VR state Fe-0/0/0 0 1 lcl 10.0.5.2 up backup vip 10.0.5.200 [edit protocols bgp] lab@r2# run show bgp summary | match 10.0.1.254 10.0.1.254 65050 0 0 0 0 22 Active
After r1’s fe-0/0/0 interface is deactivated, the change in r2’s VRRP status is confirmed:
[edit protocols bgp] lab@r2# run show vrrp summary Interface Unit Group Type Address Int state VR state fe-0/0/0 0 1 lcl 10.0.5.2 up master vip 10.0.5.200
The VIP is now owned by r2, so in a few minutes we expect to see the P1 EBGP session roll over to r2. The EBGP session must be torn down and reestablished as a result of the VRRP mastership change, so it may take a minute or two before r2 begins displaying routes from the P1 router. During the transition and reestablishment of the EBGP session, the routes learned from the P1 router will be withdrawn from your network. As long as the EBGP session successfully rolls over to r2, the loss of P1’s EBGP routes will be short-term, which is in accordance with the configuration criteria presented in this section:
[edit protocols bgp group p1] lab@r2# run show bgp summary | match 10.0.5.254 10.0.5.254 65050 9 16 0 0 18 10/10/0 0/0/0
The output confirms that the EBGP session has followed the VIP as planned. After restoring r1’s fe-0/0/0 interface, confirm that the BGP session successfully rolls back to r1 and display the routes being advertised by P1 using the source-gateway switch:
[edit] lab@r1# run show route protocol bgp source-gateway 10.0.5.254 inet.0: 46 destinations, 56 routes (43 active, 0 holddown, 3 hidden) + = Active Route, - = Last Active, * = Both 120.120.0.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.1.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.2.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.3.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.4.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.5.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.6.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.7.0/24 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0 120.120.69.128/25 *[BGP/170] 00:00:33, MED 0, localpref 100 AS path: 65050 I > to 10.0.5.254 via fe-0/0/0.0
The establishment of an EBGP session that successfully tracks the VIP address associated with r1 and r2 confirms that you have successfully configured r1 and r2 to peer with the P1 router.
T2 EBGP Peering
This section details the configuration of the EBGP session between r6 and transit provider T2. There is nothing particularly fancy about this task because EBGP authentication is configured in the same manner as that demonstrated for IBGP in Chapter 5. The following commands are entered on r6 to configure the t2 peer group:
[edit protocols bgp group t2] lab@r6# set type external neighbor 172.16.0.22 [edit protocols bgp group t2] lab@r6# set peer-as 65222 authentication-key ebgp
The completed t2 peer group configuration is displayed:
lab@r6# show type external; authentication-key "$9$vxvWLNVb2UDkwY"; # SECRET-DATA peer-as 65222; neighbor 172.16.0.22;
You now assign the correct IP address to r6’s fe-0/1/2 interface:
[edit interfaces fe-0/1/2] lab@r6# set unit 0 family inet address 172.16.0.21/30
The BGP session status is displayed a few minutes after committing the changes on r6:
[edit] lab@r6# run show bgp summary Groups: 2 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 111230 111218 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.22 65222 26760 26970 0 0 13:00 111235/ 111235/0 0/0/0 10.0.3.5 65001 858 49247 0 0 7:02:43 16/16/0 0/0/0 10.0.9.7 65001 572 52301 0 0 7:05:31 1/13/0 0/0/0
The EBGP session to T2 has been established, which indicates that compatible authentication settings are in effect. And no, that is not a typo in the screen capture; r6 really is receiving 111,235 routes from T2!
As with the actual JNCIP examination, this author’s test bed has been outfitted with a live BGP feed that carries a full Internet routing table. From here on out, the stakes have been significantly raised, because what might otherwise be classified as an innocuous mistake can now prove disastrous with this many routes floating around in your AS.
Having a full Internet routing table adds realism, complexity, and danger to the JNCIP examination. The realism and complexity aspects are the natural side effects of having so many darned routes to filter and parse through when looking for a particular route or community value. From now on, you should plan on filtering the output of show route commands so that the JUNOS software CLI does as much of the work for you as possible. The "danger" aspect relates to the fact that making a mistake, such as redistributing over 100,000 BGP routes into RIP, can lead to unexpected behavior and the possible meltdown of your network!
The well-written and modular nature of JUNOS software coupled with the ASIC-based design of the M-series and T-series routers creates a synergistic combination proven to carry more routes, converge faster, and be more stable than any other vendor’s equipment produced to date. Even so, the complex nature of a routing system coupled with the myriad ways in which various features can be configured and combined results in every network being a little distinct, to say the least. Although this author has intentionally redistributed a full Internet routing table into OSPF successfully several times during classroom demonstrations, the key words in that statement are “classroom” and “intentional.” Generally speaking, the time-constrained JNCIP lab environment is not the best place to conduct stress testing of a Juniper Networks router!
By way of example, instances have been observed in which setting next hop self in an EBGP import policy can result in an rpd core dump, while the same policy applied to a router with a paltry 18 routes results in nothing worse than having 18 routes that are hidden due to unusable next hops. The attentive reader should have noticed that the instructions provided in this chapter have guided the reader in the careful application of BGP tracing (for example, tracing just the problematic neighbor or group instead of applying the trace configuration at the global level), and have repeatedly advised you to remove tracing configurations after they have served their purpose.
To be clear, there is nothing wrong with leaving a tracing configuration in place that is selective and applied at a neighbor level, but applying a flag all detail tracing configuration globally, with this many routes being bandied about, can significantly delay network convergence and result in a slew of other problems ranging from scheduler slips to mysterious operation that cannot be reproduced. To put this into perspective, most experienced operators would consider typing the Cisco IOS command debug all to be the work of a fool, even on a router with only a few dozen routes, while in contrast it is more realistic to routinely trace BGP operation on Juniper Networks routers with full Internet routing feeds. The point is to use common sense when tracing by trying to be as selective as you can, both in the definition of what is being flagged for tracing, as well as where the tracing stanza is configured (i.e., at the global, group, or neighbor hierarchical levels).
Also, you should consider deactivating or deleting the tracing stanza if you sense that the router begins acting “funny” after the trace configuration is committed. This author once saw a candidate who was tracing all BGP packets at the global level and who repeatedly restarted routing and rebooted the routers that were thought to be misbehaving. These actions served only to exacerbate the problems, however, because the constant teardown and reestablishment of the BGP sessions resulted in an ongoing tsunami of BGP packets to be traced.
T1 EBGP Peering
This section describes the configuration of the EBGP session between r3 and the T1 and T2 routers. The need for load balancing to the routes advertised by the T1 and T2 routers necessitates the use of the multipath option. The following commands are entered on r3 to configure the t1–t2 peer group:
[edit protocols bgp group t1-t2] lab@r3# set type external peer-as 65222 [edit protocols bgp group t1-t2] lab@r3# set neighbor 172.16.0.14 [edit protocols bgp group t1-t2] lab@r3# set neighbor 172.16.0.18 [edit protocols bgp group t1-t2] lab@r3# set multipath
The resulting t1–t2 peer group is displayed:
[edit protocols bgp group t1-t2] lab@r3# show type external; peer-as 65222; multipath; neighbor 172.16.0.14; neighbor 172.16.0.18;
The interface addressing needed for r3 to peer with T1 and T2 is now configured:
[edit interfaces] lab@r3# set fe-0/0/2 unit 0 family inet address 172.16.0.13/30 [edit interfaces] lab@r3# set fe-0/0/3 unit 0 family inet address 172.16.0.17/30
After committing, you confirm that the EBGP sessions to T1 and T2 have been correctly established:
[edit protocols bgp] lab@r3# run show bgp summary Groups: 3 Peers: 6 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 222495 222484 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.14 65222 21036 21150 0 0 4:23 111229/ 111230/0 0/0/0 172.16.0.18 65222 19635 19857 0 0 4:14 111230/ 111230/0 0/0/0 10.0.2.1 65001 1887 68370 0 0 8:01:33 1/4/0 0/0/0 10.0.3.4 65000 7028 71753 0 0 9:35:31 12/17/0 0/0/0 10.0.6.1 65000 515 46115 0 2 3:50:32 10/12/0 0/0/0 10.0.6.2 65000 1155 72274 0 0 9:35:28 2/2/0 0/0/0
The output confirms the established state of both EBGP sessions and that each of the peering sessions has contributed almost the exact same number of active routes to the tune of some 111, 229 prefixes. The fact that both sessions display this level of concordance between the number of received and active routes provides a good indication that multipath load balancing is working, but a careful operator will analyze at least one of the routes to verify that the protocol and forwarding next hops associated with T1 and T2 are actually listed:
[edit protocols bgp group t1-t2] lab@r3# run show route 3/8 detail inet.0: 111284 destinations, 222518 routes (111282 active, 0 holddown, 3 hidden) 3.0.0.0/8 (2 entries, 1 announced) *BGP Preference: 170/-101 Source: 172.16.0.14 Nexthop: 172.16.0.14 via fe-0/0/2.0, selected Nexthop: 172.16.0.18 via fe-0/0/3.0 Protocol Nexthop: 172.16.0.14 Indirect nexthop: c4f3440 73 Protocol Nexthop: 172.16.0.18 Indirect nexthop: c4f3550 75 State: <Active Ext> Local AS: 65000 Peer AS: 65222 Age: 6:16 Metric2: 0 Task: BGP_65222.172.16.0.14+179 Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: 65222 10458 14203 3967 7018 80 I Localpref: 100 Router ID: 130.130.0.1 BGP Preference: 170/-101 Source: 172.16.0.18 Nexthop: 172.16.0.18 via fe-0/0/3.0, selected Protocol Nexthop: 172.16.0.18 Indirect nexthop: c4f3550 75 State: <NotBest Ext> Inactive reason: Router ID Local AS: 65000 Peer AS: 65222 Age: 3:57 Metric2: 0 Task: BGP_65222.172.16.0.18+1317 AS path: 65222 10458 14203 3967 7018 80 I Localpref: 100 Router ID: 130.130.0.2
The highlighted portions of the capture confirm that while T1’s advertisement has been selected as the active route because of its lower router ID, both of the protocol and forwarding next hops associated with the routes received from the T1 and T2 routers are listed under the active route. This output confirms that the load-balancing requirements for the multiple EBGP peering sessions supported by r3 have been met. By way of comparison, the same route is now displayed after the multipath option has been removed from r3:
[edit protocols bgp group t1-t2] lab@r3# run show route 3/8 detail inet.0: 111285 destinations, 222522 routes (111283 active, 9218 holddown, 3 hidden) 3.0.0.0/8 (2 entries, 2 announced) *BGP Preference: 170/-101 Source: 172.16.0.18 Nexthop: 172.16.0.18 via fe-0/0/3.0, selected Protocol Nexthop: 172.16.0.18 Indirect nexthop: c4f3550 75 State: <Active Ext> Local AS: 65000 Peer AS: 65222 Age: 11:04 Metric2: 0 Task: BGP_65222.172.16.0.18 Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0 AS path: 65222 10458 14203 3967 7018 80 I Localpref: 100 Router ID: 130.130.0.2 BGP Preference: 170/-101 Source: 172.16.0.14 Protocol Nexthop: 172.16.0.14 Indirect nexthop: c4f3440 73 Protocol Nexthop: 172.16.0.18 Indirect nexthop: c4f3550 75 State: <Delete Ext> Inactive reason: Unusable path Local AS: 65000 Peer AS: 65222 Age: 2 Metric2: 0 Task: BGP_65222.172.16.0.14 Announcement bits (1): 3-BGP.0.0.0.0+179 AS path: 65222 10458 14203 3967 7018 80 I Localpref: 100 Router ID: 130.130.0.1
By contrasting this capture with the previous example, you can easily spot the additional next hops that result when multipath is correctly configured. The BGP summary output also clearly shows that r3 has installed only routes from router T1 when multipath has been omitted from the t1–t2 stanza:
[edit protocols bgp] lab@r3# run show bgp summary Groups: 3 Peers: 6 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 222499 111250 0 0 0 4263 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.14 65222 20210 3806 13766 0 47 111231/ 111232/0 0/0/0 172.16.0.18 65222 19576 4053 13272 0 43 3/ 111232/0 0/0/0 10.0.2.1 65001 1898 68464 33343 0 8:07:03 1/4/0 0/0/0 10.0.3.4 65000 7039 71847 33343 0 9:41:01 3/17/0 0/0/0 10.0.6.1 65000 526 46209 33343 2 3:56:02 10/12/0 0/0/0 10.0.6.2 65000 1166 72368 33343 0 9:40:58 2/2/0 0/0/0
Make sure that you restore the multipath option to r3’s configuration before proceeding to the next section.
|
|
EAN: 2147483647
Pages: 132