CCNP BSCI Case Study 4 BGP

This Topic will address how to successfully navigate through the CCNP BSCI case study #4 BGP found here:
http://sadgull.com/learning/ccnp/Bsci/cs/cs4/index.html

Plan, design, and implement the International Travel Agency (ITA) core network as well as the Travel Data Providers (TDP) network and allow the networks to communicate via BGP. Verify that all implementations are operational and functional according to guidelines.

• Configure the International Travel Agency network to be in EIGRP AS 65001.

R1(config)#router eigrp 65001
R1(config-router)#network 10.0.0.0
R1(config-router)#network 192.168.14.0

R2(config)#router eigrp 65001
R2(config-router)#network 10.0.0.0

R3(config)#router eigrp 65001
R3(config-router)#network 10.0.0.0
R3(config-router)#network 192.168.34.0

• Configure the Travel Data Providers network to be in EIGRP AS 65002.

R4(config)#router eigrp 65002
R4(config-router)#network 172.16.0.0
R4(config-router)#network 192.168.14.0
R4(config-router)#network 192.168.34.0

• Disable automatic summarization in both EIGRP domains.

ALL ROUTERS(config-router)#no auto-summary

• Configure the International Travel Agency network to be in BGP AS 65001,
and the Travel Data Providers network to be in BGP AS 65002.

R1(config)#router bgp 65001
R1(config-router)#neighbor 10.1.103.3 remote-as 65001
- will peer w/ R2 using loopbacks see below
R1(config-router)#neighbor 192.168.14.2 remote-as 65002

R2(config)#router bgp 65001
R2(config-router)#neighbor 10.1.203.3 remote-as 65001
- will peer w/ R1 using loopbacks see below

R3(config)#router bgp 65001
R3(config-router)#neighbor 10.1.103.1 remote-as 65001
R3(config-router)#neighbor 10.1.203.2 remote-as 65001
R3(config-router)#neighbor 192.168.34.2 remote-as 65002


R4(config)#router bgp 65002
R4(config-router)#neighbor 192.168.14.1 remote-as 65001
R4(config-router)#neighbor 192.168.34.1 remote-as 65001

• Advertise the 192.168.14.0/30 and 192.168.34.0/30 networks in both EIGRP
autonomous systems.

See above for network statements added into EIGRP process

• All routers will be participating in BGP. Configure all routers for a full mesh of
IBGP peers in each system.

See above for neighbor statements

• Peer R1 and R2 using loopback addresses, not their directly connected
interfaces.

R1(config-router)#neighbor 10.2.2.2 remote-as 65001
R1(config-router)#neighbor 10.2.2.2 update-source Loopback1

R2(config-router)#neighbor 10.1.1.1 remote-as 65001
R2(config-router)#neighbor 10.1.1.1 update-source Loopback2

• Advertise all loopback interfaces into the BGP process, except on R2, where
the only loopback advertised should be loopback 2.

ALL ROUTERS: R*(config)#Router BGP 65001
R1(config-router)#network 10.1.1.0 mask 255.255.255.0

R2(config-router)#network 10.2.2.0 mask 255.255.255.0

R3(config-router)#network 10.3.3.0 mask 255.255.255.0

R4(config-router)#network 172.16.0.0 mask 255.255.252.0

• On R2, create a static summary route for the rest of its loopback interfaces
and advertise this static route in BGP.

R2(config)#ip route 10.20.0.0 255.255.252.0 Null0
R2(config)#router bgp 65001
R2(config-router)#redistribute static

• R4 should send a summary route to ITA representing all R4’s loopback
interfaces.

R4(config)#router bgp 65002
R4(config-router)#network 172.16.0.0 mask 255.255.252.0 (you must use this command w/ aggregate-address)
R4(config-router)#aggregate-address 172.16.0.0 255.255.240.0 summary-only
OR
R4(config)#ip route 172.16.0.0 255.255.240.0 null0
R4(config)#router bgp 65002
R4(config-router)#no network 172.16.0.0 mask 255.255.252.0
R4(config-router)#redistribute static
• R4 should prefer the path to ITA networks via the Ethernet link between R1
and R4. Accomplish this by modifying the MED advertised to TDP.

R1(config)#router bgp 65001
R1(config-router)#neighbor 192.168.14.2 route-map INFLUENCE_R4 out

R1(config)#route-map INFLUENCE_R4 permit 10
R1(config-route-map)#set metric 50

R3(config)#router bgp 65001
R3(config-router)#neighbor 192.168.34.2 route-map INFLUENCE_R4 out

R3(config)#route-map INFLUENCE_R4 permit 10
R3(config-route-map)#set metric 100

FYI on route maps, a route map must have at least one match clause or one set clause. If you have no match clauses, all routes match the route map, and the set conditions apply to all routes. If you have no set clauses, no action is taken other than that specified by the permit or deny keyword. If this were not true we would need to do the following:

R1(config)#access-list 1 permit any
R1(config)#route-map INFLUENCE_R4 permit 10
R1(config-route-map)#match ip address 1 (this is referencing the access list)
R1(config-route-map)#set metric 100

It is a requirement to advertise two different metrics to R4 from the two routers in AS 65001 in order to influence the path that it chooses because the default setting for metric is a null value. How can R4 make a comparison between a null metric advertised from R1 and a high metric advertised from R3? With metric lower is better. It seems as if simply placing a high metric on R3 advertised to R4 would be sufficient to influence R4 path selection but I have never tested this in a lab environment.

• Routers in the ITA AS should prefer the path to TDP networks via the
Ethernet link between R1 and R4. Accomplish this by modifying the local
preference of routes being advertised in from TDP.

R1(config)#router bgp 65001
R1(config-router)#neighbor 192.168.14.2 route-map IBGP_PEERS in

R1(config)#route-map IBGP_PEERS permit 10
R1(config-route-map)#set local-preference 160

The default local preference is 100. R3 is advertising a local preference of 100 for his path to AS 65002 to his IBGP peers. Local preference is used to influence the path that routers take to leave the local AS and has no influence over EBGP peers. Higher local preference is better than lower (this is the reverse of how metric works).