Spot the Issues: Review Questions

1.	You are having problems establishing IBGP sessions between r3, r1, and r2 in the topology shown earlier in Figure 5.2. Can you spot the problem in r3’s configuration? [edit] lab@r3# show protocols bgp local-address 10.0.3.3; group core { type internal; traceoptions { file r3-bgp; flag state detail; } authentication-key "$9$tOrr01h7Nbs2a"; # SECRET-DATA export ibgp; neighbor 10.0.3.4; neighbor 10.0.3.5; } group cluster-1111 { type internal; traceoptions { file r3-bgp; flag state detail; } authentication-key "$9$G3jkPpu1Icl"; # SECRET-DATA export ibgp; cluster 1.1.1.1; neighbor 10.0.4.14; neighbor 10.0.4.2; }
2.	Your goal is to advertise the 192.168.20/24 and 192.168.100/24 static routes into IBGP while attaching the r2 community only to 192.168.100/24, as per this chapter’s case study. Will the following policy work without any snags? [edit] lab@r2# show policy-options policy-statement ibgp term 1 { from { protocol static; route-filter 192.168.0.0/16 longer; route-filter 192.168.100.0/24 exact next term; } then accept; } term 2 { then { community add r2; accept; } }
3.	You are having problems getting BGP sessions established on r5 using the topology shown earlier in Figure 5.4. Any ideas? [edit] lab@r5# show routing-options static { route 10.0.200.0/24 next-hop 10.0.1.102; route 192.168.50.0/24 reject; } aggregate { route 10.0.2.0/23; route 10.0.8.0/21; route 192.168.0.0/22; route 172.16.40.0/29; } autonomous-system 65412; confederation 65412 members [ 65000 65001 65002 ]; [edit] lab@r5# show protocols bgp group 65002 { type internal; local-address 10.0.3.5; export ibgp; neighbor 10.0.9.6; neighbor 10.0.9.7; } group c-bgp { type external; multihop; local-address 10.0.3.5; export ibgp; neighbor 10.0.3.3 { peer-as 65000; } neighbor 10.0.3.4 { peer-as 65001; } }
4.	A route exists in both OSPF and IBGP. You need to advertise it to a BGP peer without altering the protocol next hop. How can you accomplish this?
5.	Will the following configuration support C-BGP peering between loopback addresses? [edit] lab@r5# show protocols bgp group 65002 { type internal; local-address 10.0.3.5; export ibgp; neighbor 10.0.9.6; neighbor 10.0.9.7; } group c-bgp { type external; local-address 10.0.3.5; export ibgp; neighbor 10.0.3.3 { peer-as 65000; } neighbor 10.0.3.4 { peer-as 65001; } } [edit] lab@r5# show routing-options static { route 10.0.200.0/24 next-hop 10.0.1.102; route 192.168.50.0/24 reject; } aggregate { route 10.0.2.0/23; route 10.0.8.0/21; route 192.168.0.0/22; route 172.16.40.0/29; } autonomous-system 65002; confederation 65412 members [ 65000 65001 65002 ];
6.	Why will the following policy not advertise the 192.168.100/24 static route with a modified local preference? [edit policy-options policy-statement static] lab@r2# show term 1 { from { protocol static; route-filter 192.168.20.0/24 exact; } then accept; } term 2 { from { protocol static; route-filter 192.168.100.0/24 orlonger; } then { local-preference 120; } }

Answers

1.	The global application of the local-address statement in r3’s configuration is affecting the behavior of both the core and cluster-1111 peer groups. With this configuration, r3 sources packets from its lo0 address when attempting to connect with r1 and r2, and this conflicts with their interface peering definitions, causing them to declare that r3’s packets belong to an undefined peer. You can resolve this by removing the global application of local-address and reapplying it under the core group, or by applying the local-address statement at the neighbor level in the cluster-1111 group, being careful to specify the correct interface addresses, as shown next: [edit protocols bgp group cluster-1111] lab@r3# show type internal; traceoptions { file r3-bgp; flag state detail; } authentication-key "$9$G3jkPpu1Icl"; # SECRET-DATA export ibgp; cluster 1.1.1.1; neighbor 10.0.4.14 { local-address 10.0.4.13; } neighbor 10.0.4.2 { local-address 10.0.4.1; }
2.	Well, not quite. It is true that the 192.168.20/24 route will be advertised without the r2 community, and that the 192.168.100/24 route will be advertised with the r2 community, but unfortunately, the match all nature of term 2 will result in r2’s advertisement of every other active route in its routing table with the r2 community attached. While some might argue that the policy meets the stated objectives, blatantly advertising OSPF and direct routes when a lab scenario does not call for such redistribution can result in point loss for not adhering to the specified goals. You can also encounter operational problems when routes are leaked with no reason. For example, think about what might happen in a complex internetworking topology should r2 suddenly start announcing a default route with a "prefer me" community attached to all its IBGP peers?
3.	The problem here lies in r5’s confederation and autonomous system–related configuration. The operator has incorrectly specified its autonomous system number as 65412 when it should have been 65002. This is causing the open messages it sends to its IBGP and C-BGP peers to indicate that it belongs to AS number 65412, which the peers see as an unauthorized connection attempt. The confederation AS number should only be seen by EBGP peers, but this configuration exposes all peers to the network’s real AS number.
4.	You could change protocol preferences to cause the BGP route to become active so that it is eligible for export. If preference adjustment is not possible, you will need to use the advertise-inactive option to instruct BGP to send the "best" BGP routes, even though some may currently be inactive because of the presence of a route with equal specificity having been learned through a protocol with a lower global preference.
5.	No. The default behavior of EBGP will only support peering over a directly connected subnet. C-BGP peering between lo0 addresses requires the use of the multihop option in addition to the correct use of the local-address statement.
6.	The issue with this policy lies in the absence of an accept action in term 2. You do not need to include an accept action for routes that are learned through BGP, because the default export policy for BGP is to advertise all BGP routes. You must include an explicit accept action to cause the redistribution of routes from all other protocol sources into BGP, however. As written, the 192.168.100/24 has a local preference attribute of 120 associated with it, but upon encountering the default BGP export policy the route meets up with a reject action and is therefore never exported.