Miscellaneous IBGP Timers and Knobs

You should be familiar with all IBGP options and available knobs before attempting your lab examination. This section demonstrates how some of the remaining IBGP configuration parameters may be deployed in a lab scenario. Virtual Private Network (VPN) and multicast-related options, both of which relate to the support of non-IPv4 unicast address families, are beyond the scope of this book.

Figure 5.6 documents the topology for this section and shows that the OSPF router has been brought back into the fray.

click to expand
Figure 5.6: Miscellaneous IBGP timers and knobs

To complete this section, you must configure your network in accordance with the following tasks:

  • Redistribute the 192.168.x/24 routes from the OSPF router into BGP so that r5 selects the BGP routes as active, and is able to load balance to these routes. You must not modify the existing IS-IS configuration on r5, r6, and r7.

  • Configure the IBGP peering session between r3 and r4 so that r3 uses a 60-second keepalive interval.

  • Configure r4 to be passive for IBGP and C-BGP connections.

  • Configure r1 and r2 to redistribute a 192.168.100/24 static route into IBGP and ensure that all other routers forward through r1 when its IBGP session is up.

  • Use a community to ensure that other routers will not forward the 192.168.100/24 route outside your AS.

IBGP Preference and Load Balancing

The first task will require modifications to the ibgp export policy on r6 and r7, BGP preference adjustments on r5, and the use of the multipath option for IBGP. The following statements modify the export policy used by IBGP on r6. We begin by displaying the current state of the ibgp policy:

[edit policy-options policy-statement ibgp] lab@r6# show term 1 {    from {       protocol static;       route-filter 192.168.60.0/24 exact;    }    then accept;  }

You now add a new term to the ibgp export policy that will match on, and accept, the 192.168.x/24 routes coming from the OSPF router:

[edit policy-options policy-statement ibgp] lab@r6# set term 2 from protocol ospf [edit policy-options policy-statement ibgp] lab@r6# set term 2 from route-filter 192.168.0/21 longer [edit policy-options policy-statement ibgp] lab@r6# set term 2 then accept 

After committing the changes on r6, you confirm that the OSPF routes are being redistributed into IBGP:

[edit policy-options policy-statement ibgp] lab@r6# run show route advertising-protocol bgp 10.0.3.5 inet.0: 29 destinations, 33 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 172.16.40.1              0         100 I 192.168.0.1/32 172.16.40.1              1         100 I 192.168.1.0/24 172.16.40.1              0         100 I 192.168.2.0/24 172.16.40.1              0         100 I 192.168.3.0/24 172.16.40.1              0         100 I 192.168.4.0/24 172.16.40.1              0         100 I 192.168.60.0/24 Self                     0         100 I

The display confirms that the OSPF routes are now being sent to r5 through IBGP, so your export policy is working as designed. It is interesting to see that r6 is advertising a third-party next hop of 172.16.40.1. This is normal behavior for BGP running on a broadcast interface, because other BGP speakers might have a direct connection to the OSPF subnet and this would allow IBGP speakers to forward packets directly to the OSPF router, even though the OSPF router does not even speak BGP!

After similar modifications are made to r7, you confirm that r5 is receiving equal-cost BGP routes from both r6 and r7:

[edit] lab@r5# run show route 192.168.1/24 inet.0: 40 destinations, 54 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24     *[IS-IS/155] 00:22:09, metric 5, tag 1                       to 10.0.8.5 via fe-0/0/0.0                     > to 10.0.8.10 via fe-0/0/1.0                     [BGP/170]  00:21:27, MED 0, localpref 100, from 10.0.9.6                        AS path: I                     > to 10.0.8.10 via fe-0/0/1.0                     [BGP/170]  00:22:24, MED 0, localpref 100, from 10.0.9.7                        AS path: I                     > to 10.0.8.5 via fe-0/0/0.0 

Good, there are two sets of IBGP routes, but IBGP load balancing will be difficult considering that r5 has selected the IS-IS routes as active. To remedy this, you will need to modify the BGP preference on r5 so that BGP routes are preferred to IS-IS level 1 externals, which by default have a global preference of 160. The default IS-IS preference value was changed to 155 as part of the case study in Chapter 5. Adjusting the preference for IS-IS is also feasible, but disallowed by your rules of engagement for this scenario. Given these restrictions, you opt to adjust the BGP preference by the minimum amount required to make the BGP routes preferred over the IS-IS level 1 externals:

[edit] lab@r5# set protocols bgp preference 154 

After the commit, you once again examine r5’s routing table with your attention focused on the routes generated by the OSPF router:

[edit] lab@r5# run show route 192.168.1/24 inet.0: 40 destinations, 54 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24     *[BGP/154]  00:25:53, MED 0, localpref 100, from 10.0.9.6                        AS path: I                      > to 10.0.8.10 via fe-0/0/1.0                      [BGP/159] 00:26:50, MED 0, localpref 100, from 10.0.9.7                        AS path: I                      > to 10.0.8.5 via fe-0/0/0.0                     [IS-IS/154] 00:01:06, metric 5, tag 1                      > to 10.0.8.5 via fe-0/0/0.0                        to 10.0.8.10 via fe-0/0/1.0

Great—the IBGP routes are now preferred over the IS-IS alternatives, which is a big step forward in completing this aspect of your configuration. To complete this task, you must now enable IBGP load balancing with the multipath option to allow r5 to load balance to the OSPF prefixes using IBGP routes. Before making the change shown next, note that the currently active IBGP routes for the 192.168.0/22 prefix list a single IGP forwarding next hop. After enabling multipath, you will expect to see multiple IGP next hops listed for the various 192.168.0/22 OSPF prefixes:

 [edit] lab@r5# set protocols bgp group 65002 multipath 

Now to confirm the correct load-balancing behavior, the 192.168.1/24 route is once again displayed on r5:

[edit] lab@r5# run show route 192.168.1/24 inet.0: 40 destinations, 54 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24      *[BGP/154] 00:28:12, MED 0, localpref 100, from 10.0.9.6                        AS path: I                      > to 10.0.8.10 via fe-0/0/1.0                        to 10.0.8.5 via fe-0/0/0.0                      [BGP/154] 00:29:09, MED 0, localpref 100, from 10.0.9.7                        AS path: I                      > to 10.0.8.5 via fe-0/0/0.0                     [IS-IS/155] 00:03:25, metric 5, tag 1                      > to 10.0.8.5 via fe-0/0/0.0                        to 10.0.8.10 via fe-0/0/1.0

Excellent! Even though r6’s lower RID value results in its advertisement being chosen as the active IBGP route, multipath operation has allowed a recursive lookup on both of the protocol next hops being advertised by r6 and r7, and the result is the desired load-balancing behavior now observed at r5. Detailed output from a show route command is provided here with the various next hops highlighted:

[edit] lab@r5# run show route 192.168.1/24 detail inet.0: 40 destinations, 54 routes (40 active, 0 holddown, 0 hidden) 192.168.1.0/24 (3 entries, 1 announced)        *BGP Preference: 154/-101             Source: 10.0.9.6             Nexthop: 10.0.8.10 via fe-0/0/1.0, selected             Nexthop: 10.0.8.5 via fe-0/0/0.0             Protocol Nexthop: 172.16.40.1 Indirect nexthop: 83e9440 62             Protocol Nexthop: 172.16.40.5 Indirect nexthop: 83e9330 60             State: <Active Int Ext>             Local AS: 65002 Peer AS: 65002             Age: 30:21 Metric: 0 Metric2: 7             Task: BGP_65002.10.0.9.6+1032             Announcement bits (4): 0-KRT 3-Aggregate 4-BGP.0.0.0.0+179  5- Resolve inet.0             AS path: I             Localpref: 100             Router ID: 10.0.9.6         BGP Preference: 154/-101             Source: 10.0.9.7             Nexthop: 10.0.8.5 via fe-0/0/0.0, selected             Protocol Nexthop: 172.16.40.5 Indirect nexthop: 83e9330 60             State: <NotBest Int Ext>             Inactive reason: Router ID             Local AS: 65002 Peer AS: 65002             Age: 31:18 Metric: 0 Metric2: 7             Task: BGP_65002.10.0.9.7+1036             AS path: I             Localpref: 100            Router ID: 10.0.9.7 . . . 

Modify IBGP Timers

The second criterion is not as simple as it may at first seem. This is because the BGP keepalive value is configured indirectly in JUNOS software by setting the session hold time, and because the BGP protocol negotiates the session’s hold time such that the lower of the two proposed values (within protocol limits) will always be put into effect. The keepalive interval is always set to one- third of the session’s negotiated hold time, so a 60-second keepalive is achieved with a session hold time of 180 seconds. There is no way to have r3 and r4 use different hold times, but the wording of the task may lead you to believe that there is! To accomplish this task, you will need to modify the hold time on both r3 and r4, as shown next:

[edit protocols bgp] lab@r3# set group c-bgp neighbor 10.0.3.4 hold-time 180 

You must use care to ensure that you do not apply the modified hold time at either the global or group levels because doing so could affect all of r3’s IBGP and C-BGP sessions, which is a situation that would be outside of the parameters of this configuration task. After modifying r4’s hold time, the results are confirmed:

[edit] lab@r4# run show bgp neighbor 10.0.3.3 Peer: 10.0.3.3+1049 AS 65000 Local: 10.0.3.4+179 AS 65001   Type: External State: Established Flags: <>   Last State: OpenConfirm Last Event: RecvKeepAlive   Last Error: None   Export: [ ibgp ]   Options: <Multihop Preference LocalAddress HoldTime PeerAS Refresh Confed>   Local Address: 10.0.3.4 Holdtime: 180 Preference: 170   Number of flaps: 1   Error: 'Cease' Sent: 0 Recv: 1   Peer ID: 10.0.3.3 Local ID: 10.0.3.4 Active Holdtime: 180   Keepalive Interval: 60   NLRI advertised by peer: inet-unicast   NLRI for this session: inet-unicast   Peer supports Refresh capability (2)     Table inet.0 Bit: 10001     Send state: in sync     Active prefixes: 5     Received prefixes: 5     Suppressed due to damping: 0   Last traffic (seconds): Received 0    Sent 0   Checked 2   Input messages:  Total 1776   Updates 1775   Refreshes 0   Octets 122981   Output messages: Total 1780   Updates 1778   Refreshes 0   Octets 123202   Output Queue[0]: 0

This display confirms the correct setting of the r3–r4 C-BGP session’s keepalive time. The display can also be used to ascertain the session’s configured hold time versus the value that was actually negotiated, because the latter is preceded by the active keyword.

Configure Passive Mode

The third task requires that r4 be configured to operate in a passive mode for its IBGP and C-BGP connections. This means that it should never initiate a connection to r2, r3, or r5. This behavior is configured with the passive keyword, as shown next:

[edit] lab@r4# set protocols bgp group 65001 passive 

The results can be confirmed by verifying that the passive option is in place for r4’s IBGP and C-BGP neighbors:

[edit] lab@r4# run show bgp neighbor 10.0.6.2 Peer: 10.0.6.2+179 AS 65001 Local: 10.0.3.4+1029 AS 65001   Type: Internal State: Established Flags: <>   Last State: OpenConfirm Last Event: RecvKeepAlive   Last Error: None   Export: [ ibgp ]   Options: <Preference LocalAddress HoldTime Passive Refresh Confed>   Local Address: 10.0.3.4 Holdtime: 90 Preference: 170   Number of flaps: 0   Peer ID: 10.0.6.2          Local ID: 10.0.3.4      Active Holdtime: 90   Keepalive Interval: 30   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: 1     Received prefixes: 1     Suppressed due to damping: 0  Last traffic (seconds): Received 3 Sent 3 Checked 3  Input messages:  Total 380    Updates 1      Refreshes 0    Octets 7256  Output messages: Total 95837  Updates 95472  Refreshes 0    Octets 6282903  Output Queue[0]: 0

You could also use protocol tracing or traffic monitoring to verify that r4 does not initiate TCP sessions to port 179, if you are so inclined. Showing the system’s connections can also be used to verify that r4 is not initiating BGP connections because the "called" end of a TCP connection accepts packets destined to the well-known port while the "calling" end picks a random port above 1023 for its source port. The indication that the local side of a router’s TCP connection is using port 179 confirms that that router did not initiate the connection, as shown in this example of a BGP connection between r4 and r2, where r2 has initiated the BGP connection to r4:

[edit] lab@r4# run show system connections Active Internet connections (including servers) Proto Recv-Q Send-Q  Local Address          Foreign Address        (state) tcp4       0      0  10.0.3.4.179           10.0.6.2.1033          ESTABLISHED . . . 

The various displays shown in this section serve to confirm that r4 has been correctly configured for passive operation with its peers.

Use Local Preference and Communities

The requirement that other routers in AS 65412 prefer r1 as the source of the 192.168.100/24 prefix is easily accomplished by adjusting the redistribution policies of r1 or r2 so that other routers see r1 advertising a higher, and therefore more preferred, local preference value. Knowing that the default local preference from r2 will be 100 allows you to achieve your goal by simply having r1 set a local preference value of 101 or higher when redistributing the 192.168.100/24 route into IBGP.

This task also requires that you prevent the advertisement of the 192.168.100/24 prefix outside of your AS through the use of communities. While this can be accomplished using various combinations of user-defined communities and BGP policy, the most straightforward way to address this problem is to use the well-known no-export community. The presence of this community will automatically prevent a community-aware BGP speaker from advertising the route outside a confederation boundary, which means the route will never leave AS 65412 in this case. This sounds like just the ticket for getting one step closer to JNCIP nirvana.

The no-export community is coded as 0x FFFF FF01, or decimal 65,535:65,281. This author’s advice is that you make use of the JUNOS software support of predefined symbolic naming for well-known communities, because typing no-export is pretty easy compared to your remaining syntax alternatives.

You begin with the baseline redistribution policy for r2, starting with the definition of a named community. Oddly enough, you have to assign a user-defined variable name, which might or might not mimic the predefined JUNOS software name for the well-known community, before you can make use the no-export community in a policy:

[edit policy-options] lab@r2# set community no-export members no-export 

In this example, the user-assigned name matches the JUNOS software syntax for the community’s well-known name. You now write the policy that will attach this community when advertising the 192.168.100/24 static route to IBGP peers:

[edit policy-options] lab@r2# edit policy-statement static [edit policy-options policy-statement static] lab@r2# set term 1 from route-filter 192.168.100/24 exact [edit policy-options policy-statement static] lab@r2# set term 1 then community add no-export [edit policy-options policy-statement static] lab@r2# set term 1 then accept 

The completed policy is now shown:

[edit policy-options policy-statement static] lab@r2# show term 1 {      from {         protocol static;         route-filter 192.168.100/24 exact;      }      then {         metric 101;         community add no-export;         accept;      } }

The static policy is applied to r2’s 65001 IBGP peer group as export, which causes r2 to evaluate the ibgp and static policies when advertising BGP routes to its peers:

[edit protocols bgp] lab@r2# set group 65001 export static 

Next, you define the static route with a reject next hop and commit your changes:

[edit] lab@r2# set routing-options static route 192.168.100/24 reject [edit protocols bgp] lab@r2# commit commit complete

And now to confirm the results of your community tagging and redistribution policy on r2:

[edit] lab@r2# run show route advertising-protocol bgp 10.0.3.4 inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.20.0/24 Self                     0        100 I 192.168.100.0/24 Self                     0        100 I 

Good, both of the static routes associated with r2 are being redistributed into IBGP. To verify the presence of the community, use the detail switch:

[edit] lab@r2# run show route advertising-protocol bgp 10.0.3.4 192.168.100/24 detail inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden) 192.168.100.0/24 (2 entries, 1 announced)  BGP group 65001 type Internal      Nexthop: Self      MED: 0      Localpref: 100      AS path: I      Communities: no-export 

The route is being advertised by IBGP with the default local preference setting of 100 and the no-export community is correctly attached. After replicating the policy and static route definition on r1, the static policy is modified as highlighted:

[edit policy-options] lab@r1# set policy-statement static term 1 then local-preference 101 [edit policy-options] lab@r1# show policy-statement static {      term 1 {          from {             protocol static;             route-filter 192.168.100/24 exact;          }          then {             metric 101;             local-preference 101;             community add no-export;             accept;          }     } } 

Once applied to r1’s 65000 BGP group as export, the results are verified:

[edit] lab@r1# run show route advertising-protocol bgp 10.0.3.3 192.168.100/24 detail inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) 192.168.100/24 (1 entry, 1 announced)  BGP group 65000 type Internal      Nexthop: Self      MED: 101      Localpref: 101      AS path: I      Communities: no-export 

The routing tables of other routers are now analyzed to verify that the local preference causes them to prefer r1 as the source of the 192.168.100/24 route as required:

lab@r6> show route 192.168.100/24 detail inet.0: 30 destinations, 38 routes (30 active, 0 holddown, 0 hidden) 192.168.100.0/24 (1 entry, 1 announced)        *BGP Preference: 170/-102             Source: 10.0.3.5             Nexthop: 10.0.8.6 via fe-0/1/0.0, selected             Protocol Nexthop: 10.0.6.1 Indirect nexthop: 8460110 43             State: <Active Int Ext>             Local AS: 65002 Peer AS: 65002             Age: 28:19 Metric: 0 Metric2: 5             Task: BGP_65002.10.0.3.5+179             Announcement bits (2): 0-KRT 6-Resolve inet.0             AS path: (65000) I             Communities: no-export             Localpref: 101             Router ID: 10.0.3.5

Well, it does seem that r6 has installed r1’s route as active, but what about the fact that r2’s advertisement is not even shown? Is this a symptom of a malfunction in r2’s export policy? The answer to these questions can be gleaned from the understanding that BGP speakers advertise only active routes to other speakers, and that the lack of a full IBGP mesh between the routers that compose the test bed means that some routers are now reliant on the coupling of IBGP routes through other BGP speakers.

In this case, r1’s higher local preference setting is causing r4 to install r1’s 192.168.100/24 route as active (which it learns about through the C-BGP peering session to r3), and this in turn causes both r3 and r4 to suppress the advertisement of r2’s 192.168.100/24 BGP route in the updates they generate to r5. The route’s absence on r5 prevents r6 and r7 from learning r2’s advertisement in a similar fashion. Checking r2’s routing table confirms that it too prefers r1’s BGP route, although the local static route definition on r2 prevents r1’s BGP route from becoming active:

[edit] lab@r2# run show route 192.168.100/24 detail inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden) 192.168.100.0/24 (2 entries, 1 announced)        *Static Preference: 5                Next hop type: Reject                State: <Active Int Ext>                Age: 45:09      Metric: 0                Task: RT                Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0                AS path: I            BGP Preference: 170/-102                Source: 10.0.3.4                Nexthop: 10.0.4.5 via fe-0/0/3.0, selected                Protocol Nexthop: 10.0.6.1 Indirect nexthop: 84293b8 57                State: <Int Ext>                Inactive reason: Route Preference                Local AS: 65001 Peer AS: 65001                Age: 39:17      Metric: 0      Metric2: 5                Task: BGP_65001.10.0.3.4+179                AS path: (65000) I                Communities: no-export                Localpref: 101                Router ID: 10.0.3.4

By temporarily removing the static policy on r1, you can easily confirm that other routers will install r2’s advertisement as the active route:

[edit] lab@r1# delete protocols bgp group 65000 export static [edit] lab@r1# commit commit complete 

With only r2 advertising the 192.168.100/24 prefix, you confirm that other routers have installed r2’s route as active:

lab@r6> show route 192.168.100/24 detail inet.0: 30 destinations, 38 routes (30 active, 0 holddown, 0 hidden) 192.168.100.0/24 (1 entry, 1 announced)         *BGP Preference: 170/-101              Source: 10.0.3.5              Nexthop: 10.0.8.6 via fe-0/1/0.0, selected              Protocol Nexthop: 10.0.6.2 Indirect nexthop: 8460220 47              State: <Active Int Ext>              Local AS: 65002 Peer AS: 65002              Age: 49:27      Metric: 0      Metric2: 5              Task: BGP_65002.10.0.3.5+179              Announcement bits (2): 0-KRT 6-Resolve inet.0              AS path: (65000 65001) I              Communities: no-export              Localpref: 100              Router ID: 10.0.3.5

As expected, r2 has been chosen as the preferred source of the 192.168.100/24 route. r5 is now receiving more or less identical updates from both r3 and r4, but has chosen r3’s route as active because of its preferred RID value. As before, both routes carry the same protocol next hop of 10.0.6.2, so forwarding is not impacted by r5 choosing r3 as the preferred source of the route:

lab@r5> show route 192.168.100/24 detail inet.0: 41 destinations, 56 routes (41 active, 0 holddown,  0 hidden) 192.168.100.0/24 (2 entries, 1 announced)         *BGP Preference: 154/-101              Source: 10.0.3.3              Nexthop: 10.0.2.10 via as1.0, selected              Protocol Nexthop: 10.0.6.2 Indirect nexthop: 83e92a8 60              State: <Active Int Ext>              Local AS: 65002 Peer AS: 65000              Age: 51:18 Metric: 0 Metric2: 11              Task: BGP_65000.10.0.3.3+179              Announcement bits (3): 0-KRT 4-BGP.0.0.0.0+179 5-Resolve inet.0              AS path: (65000 65001) I              Communities: no-export              Localpref: 100              Router ID: 10.0.3.3          BGP Preference: 154/-101              Source: 10.0.3.4              Nexthop: 10.0.2.10 via as1.0, selected              Protocol Nexthop: 10.0.6.2 Indirect nexthop: 83e92a8 60              State: <NotBest Int Ext>              Inactive reason: Router ID              Local AS: 65002 Peer AS: 65001              Age: 5:25      Metric: 0      Metric2: 11              Task: BGP_65001.10.0.3.4+179              AS path: (65001) I              Communities: no-export              Localpref: 100              Router ID: 10.0.3.4 

With the correct redistribution, community, and local preference settings confirmed, you restore r1’s static export policy before moving on:

[edit] lab@r1# rollback 1 load complete [edit] lab@r1# commit commit complete 

start sidebar
Troubleshoot an IBGP Problem

Your test bed is configured according to Figure 5.6, shown earlier, when you notice that r4 and r5 are missing the 192.168.10/24 route from r1:

[edit] lab@r4# run traceroute 192.168.10.1 traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets traceroute: sendto: No route to host  1 traceroute: wrote 192.168.10.1 40 chars, ret=-1  ^C

You verify that r3 has the 192.168.10/24 route, which indicates the IBGP session to r1 is operational, but you notice that its C-BGP sessions to r4 and r5 are both active:

lab@r3> show route protocol bgp 192.168.10/24 inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.10.0/24    *[BGP/170] 00:09:46, MED 0, localpref 100, from 10.0.6.1                       AS path: I                     > to 10.0.4.14 via fe-0/0/0.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) lab@r3> show bgp summary Groups: 2 Peers: 3 Down peers: 2 Table          Tot Paths  Act Paths Suppressed    History Damp State     Pending inet.0                 2          2          0          0          0           0 Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn  State|#Active/Received/Damped... 10.0.3.4        65001          2          6       0      17          14  Active 10.0.3.5        65002          2          6       0      20          27  Active 10.0.6.1        65000         24         25       0       0       10:39 2/2/0                 0/0/0

This state of affairs explains the missing route on r4. You decide to trace BGP open messages on r3, and capture the following output:

Jun 7 13:15:49 trace_on: Tracing to "/var/log/hrr"  started Jun 7 13:16:03 bgp_send: sending 45 bytes to 10.0.3.4 (External AS 65001) Jun 7 13:16:03 Jun 7 13:16:03 BGP SEND 10.0.3.3+179 -> 10.0.3.4+1103 Jun 7 13:16:03 BGP SEND message type 1 (Open) length 45 Jun 7 13:16:03 BGP SEND version 4 as 65000 holdtime 180 id 10.0.3.3 parmlen 16 Jun 7 13:16:03 MP capability AFI=1, SAFI=1 Jun 7 13:16:03 Refresh capability, code=128 Jun 7 13:16:03 Refresh capability, code=2 Jun 7 13:16:03 bgp_send: sending 45 bytes to 10.0.3.4 (External AS 65001) Jun 7 13:16:03 Jun 7 13:16:03 BGP SEND 10.0.3.3+179 -> 10.0.3.4+1103 Jun 7 13:16:03 BGP SEND message type 2 (Update) length 45 Jun 7 13:16:03 BGP SEND flags 0x40 code Origin(1): IGP Jun 7 13:16:03 BGP SEND flags 0x40 code ASPath(2): 65000 Jun 7 13:16:03 BGP SEND flags 0x40 code NextHop(3): 10.0.3.3 Jun 7 13:16:03 BGP SEND       192.168.10.0/24 Jun 7 13:16:03 bgp_send: sending 52 bytes to 10.0.3.4 (External AS 65001) Jun 7 13:16:03 Jun 7 13:16:03 BGP SEND 10.0.3.3+179 -> 10.0.3.4+1103 Jun 7 13:16:03 BGP SEND message type 2 (Update) length 52 Jun 7 13:16:03 BGP SEND flags 0x40 code Origin(1): IGP Jun 7 13:16:03 BGP SEND flags 0x40 code ASPath(2): 65000 Jun 7 13:16:03 BGP SEND flags 0x40 code NextHop(3): 10.0.3.3 Jun 7 13:16:03 BGP SEND flags 0x80 code MultiExitDisc(4): 0 Jun 7 13:16:03 BGP SEND       192.168.30.0/24 Jun 7 13:16:03 bgp_read_v4_update: receiving packet(s) from 10.0.3.4 (External AS   65001) Jun 7 13:16:03 Jun 7 13:16:03 BGP RECV 10.0.3.4+1103 -> 10.0.3.3+179 Jun 7 13:16:03 BGP RECV message type 2 (Update) length 59 Jun 7 13:16:03 BGP RECV flags 0x40 code Origin(1): IGP Jun 7 13:16:03 BGP RECV flags 0x40 code ASPath(2): (65001) Jun 7 13:16:03 BGP RECV flags 0x40 code NextHop(3): 10.0.3.4 Jun 7 13:16:03 BGP RECV flags 0x80 code MultiExitDisc(4): 0 Jun 7 13:16:03 BGP RECV flags 0x40 code LocalPref(5): 100 Jun 7 13:16:03 BGP RECV       192.168.40.0/24 Jun 7 13:16:03 bgp_path_attr_error: NOTIFICATION sent to 10.0.3.4 (External AS   65001): code 3 (Update Message Error) subcode 11 (AS path attribute problem) Jun 7 13:16:03 bgp_send: sending 21 bytes to 10.0.3.4 (External AS 65001) Jun 7 13:16:03 Jun 7 13:16:03 BGP SEND 10.0.3.3+179 -> 10.0.3.4+1103 Jun 7 13:16:03 BGP SEND message type 3 (Notification) length 21 Jun 7 13:16:03 BGP SEND Notification code 3 (Update Message Error) subcode 11 (AS   path attribute problem)

You decide to focus on r3’s BGP-related configuration because r4 and r5 seem to be working fine. Can you spot the issue in the r3’s configuration?

[edit] lab@r3# show protocols bgp group 65000 {      type internal;     local-address 10.0.3.3;      hold-time 180;     export ibgp;     neighbor 10.0.6.1; } group c-bgp { group c-bgp {      type external;      traceoptions {         file hrr;         flag open detail;          flag update detail;      }     multihop;      local-address 10.0.3.3;     export ibgp;      neighbor 10.0.3.4 {          hold-time 180;          peer-as 65001;      }      neighbor 10.0.3.5 {          peer-as 65002;      } } [edit] lab@r3# show routing-options static {    route 10.0.200.0/24 next-hop 10.0.1.102;    route 192.168.30.0/24 reject;  } aggregate {    route 10.0.4.0/22; } autonomous-system 65000; confederation 65412 members [ 6500 6501 6502 ]; [edit] lab@r3# show policy-options policy-statement ibgp term 1 {    from {       protocol static;       route-filter 192.168.30.0/24 exact;    }    then accept;  }

If you spotted the “fat-finger” typing errors in r3’s confederation settings, then you have a good eye for details! The (AS path attribute problem) messages in the trace output also help to diagnose the problem, as the error report clearly indicates that r3 is having a problem with what appears to be a malformed AS path attribute in the update messages sent by r4 (and r5). This is caused by r3 treating r4 and r5 as conventional EBGP peers (because their AS numbers are not configured in the confederation list) while r4 and r5 treat r3 as a C-BGP peer. Different codes are used to identify a conventional AS path segment and a confederation AS path segment—which, in the case of an AS sequence segment type, is coded as 2 and 4, respectively. The differences in AS path segment coding cause the notification messages shown in the trace output and a subsequent teardown of the BGP session.

end sidebar




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net