Multi-Technology Troubleshoot Lab 5 – Solutions

First, both routers are missing the ebgp-multihop command. This command is required when you are peering indirectly connected external BGP speakers

Second, R1 is missing a static route to the 2.2.2.2 address. This needs to point out of Serial0/0.

Third, R2 has the peer statement to R1 in the shutdown state. This can be rectified using the no neighbor <address> shutdown command

First, all routers in the topology need to be configured to advertise the 172.16.x.x subnets. This will allow ping packets back and forth between the BGP speakers using the network <network> mask <mask> configuration command because no IGPs are currently running

Second, R2 needs to be configured to change the NEXT_HOP for all updates sent to R3 because the 1.1.1.1 NEXT_HOP is invalid. This can be accomplished by issuing theneighbor 172.16.3.3 next-hop-self command on R2.

Third, by default, an iBGP speaker will not advertise routes received from another iBGP speaker to a third iBGP speaker. R3 will therefore not advertise any routes to R4. This is resolved by configuring R3 as a route reflector as follows:

First, the RIPng processes are using the same non-default port number but different Multicast groups. The port number and Multicast group address must be configured the same

Second, a metric is required when redistributing dynamic routing protocols into RIPng. The redistribution of OSPFv3 should include the metric keyword

Third, by default, connected subnets are not redistributed when redistributing between IPv6 protocols. The include-connected command is required for both OSPFv3 and RIPng

First, the crypto map is applied to the wrong interface on R3. This should be applied to Serial1/3 instead of Serial1/2. This needs to be corrected

Second, the pre-shared keys on the routers are mismatched. R3 has a pre-shared key of TSHOOT while R4 has a pre-shared key of TSH00T. The keys must match

Third, the ACLs that are referenced in the crypto map configuration are incorrect. These should match traffic from the local subnet to the remote subnet and not vice versa

First, the Cisco IOS IP SLA operations on R3 need to be started using the ip sla monitor schedule <operation> life <life> start-time <time> command. This is required for both configured operations on R3

Second, if the target is a Cisco IOS device, which is the case in this example, then the ip sla monitor responder command is required on this device. This must be configured on R2