Lab 91 - non-BGP Transit with MPLS

Prerequisites: CCNP level skills.

Notice!
Interfaces in the topology changed (my previous setup using 3640 does not support MPLS; here 3275 routers are used). Also, for the purposes of MPLS, R4 is connected using sub-interfaces to R1 and R2.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Notice!
Use Initial configuration (Task 1) from the lab 89.

Task 1
Ensure 172.16.105.0/24 (R5) can reach 172.16.102.0/24 (R2). Use MPLS to accomplish the goal.

Lab Solution

Notice!
The same problem as in Lab 89. R1 is NOT running BGP and drops the packets between 172.16.102.0/24 and 172.16.105.0/24

Task 1

Ensure 172.16.105.0/24 (R5) can reach 172s.16.102.0/24 (R2). Use MPLS to accomplish the goal.

Personal Note!
Since this mini-lab is a bit more complex than the previous ones, step-by-step procedure is shown below. Just so I can get back to it at a later stage when I begin to forget some details.

R2 BGP Configuration:

!

 bgp router-id 172.16.102.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.24.4 remote-as 134
 no auto-summary

!

R5 BGP Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 172.16.105.5
 bgp log-neighbor-changes

 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 134
 no auto-summary

!

Step 1 - IGP Routing protocol configuration

R1 Configuration:

!
router ospf 1
 router-id 172.16.101.1
 log-adjacency-changes
 network 10.1.13.1 0.0.0.0 area 0
 network 10.1.14.1 0.0.0.0 area 0
 network 172.16.101.1 0.0.0.0 area 0

!

R3 Configuration:

!

router ospf 1
 router-id 172.16.103.3
 log-adjacency-changes
 network 10.1.13.3 0.0.0.0 area 0
 network 172.16.103.3 0.0.0.0 area 0

!

R4 Configuration:

!

router ospf 1
 router-id 172.16.104.4
 log-adjacency-changes
 network 10.1.14.4 0.0.0.0 area 0
 network 172.16.104.4 0.0.0.0 area 0

!

Notice!
Loopback interfaces have been advertised into OSPF. They will be used by LDP protocol to establish session TCP session (DPort=646). It is recommended to use the same router ID when implementing BGP, OSPF, LDP, so I use manual settings.

Step 2 - LDP configuration

Notice!
IP CEF is enabled on all interfaces (it is a pre-requisite).

Notice!

R3 and R4 loopbacks have been re-configured to have /32 network mask as per LDP requirement. VPN does not work otherwise. BGP sends the following message:

%BGP-4-VPNV4NH_MASK: Nexthop 172.16.103.3 may not be reachable from neigbor 172.16.104.4 - not /32 mask

R1 Configuration:

!
mpls label protocol ldp
!
mpls ldp router-id Loopback0 force
!
interface FastEthernet0/0
 ip address 10.1.14.1 255.255.255.0
 speed 100
 full-duplex
 mpls ip

!
interface serial1/1
 mpls ip

Verification:

Pic. 2 - LDP-enabled Interfaces on R1.

  

R3 Configuration:

!
mpls label protocol ldp
!
mpls ldp router-id Loopback0 force

!

interface Serial1/1
 ip address 10.1.13.3 255.255.255.0
 mpls ip
 serial restart-delay 0
!

R4 Configuration:

!
mpls label protocol ldp
!
mpls ldp router-id Loopback0 force

!

interface FastEthernet0/0.14
 encapsulation dot1Q 14
 ip address 10.1.14.4 255.255.255.0
 mpls ip
!

Notice!
R4 has two loopbacks. The higher IP address becomes LDP ID. Since I did not advertised loopback1, I need to force R4 to use loopback0  address as its ID.

Verification:

Pic. 3 - R1's LDP Neighbors.

Pic. 4 - R1's LDP Neighbor Discovery.

Pic. 5 - R3's LFIB.

Pic. 6 - R4's LFIB.

  

Notice!

The Loopbacks shown (pic. 6 and pic. 7) become the next-hop attributes for MP-BGP session in my configuration.

Step 3 - Basic BGP Configuration

R3 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 neighbor 172.16.104.4 remote-as 134
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary

!

R4 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 134
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

Verification:

Pic. 7 - BGP Neighbors.

Step 4 - MP-IBGP Configuration

R3 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 neighbor 172.16.104.4 remote-as 134
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 172.16.104.4 activate
  neighbor 172.16.104.4 send-community both
  neighbor 172.16.104.4 next-hop-self
 exit-address-family

!

R4 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 134
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 172.16.103.3 activate
  neighbor 172.16.103.3 send-community both
  neighbor 172.16.103.3 next-hop-self
 exit-address-family

!

Verification:

Pic. 8 - MP-IBGP Session.

Step 4 - VRF Configuration:

R3 Configuration:

!

ip vrf R2_R5
 rd 134:25
 route-target export 134:25
 route-target import 134:25
!
interface FastEthernet0/0
 ip vrf forwarding R2_R5
 ip address 10.1.35.3 255.255.255.0
 speed 100
 full-duplex

!

R4 Configuration:

!

ip vrf R2_R5
 rd 134:25
 route-target export 134:25
 route-target import 134:25
!
interface FastEthernet0/0.24
 encapsulation dot1Q 24
 ip vrf forwarding R2_R5
 ip address 10.1.24.4 255.255.255.0

!

Notice!

Once you activate VRF on an interface, the IP address is removed and must be manually re-created.

Pic. 9 - Reachability Check Using VRF.

Step 5 - PE-CE BGP Connection

R3 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.103.3
 bgp log-neighbor-changes
 neighbor 172.16.104.4 remote-as 134
 neighbor 172.16.104.4 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 172.16.104.4 activate
  neighbor 172.16.104.4 send-community both
  neighbor 172.16.104.4 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf R2_R5
  neighbor 10.1.35.5 remote-as 50
  neighbor 10.1.35.5 activate
  no synchronization
 exit-address-family

!

Verification:

Pic. 10 - BGP Neighbor and VRF Table on R3.

Pic. 11 - VRF Table on R4.

R4 Configuration:

!

router bgp 134
 no synchronization
 bgp router-id 172.16.104.4
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 134
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 172.16.103.3 activate
  neighbor 172.16.103.3 send-community both
  neighbor 172.16.103.3 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf R2_R5
  neighbor 10.1.24.2 remote-as 20
  neighbor 10.1.24.2 activate
  no synchronization
 exit-address-family

!

Verfication:
The same verification as per R3.

Pic. 12 - Ping Test.

Lab 90 - non-BGP Transit with GRE Tunnel

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Notice!
Use Initial configuration (Task 1) from the lab 89.

Task 1
Ensure 172.16.105.0/24 (R5) can reach 172.16.102.0/24 (R2). Use GRE tunnel to accomplish the goal.

Lab Solution

Notice!
The same problem as in Lab 89. R1 is NOT running BGP and drops the packets between 172.16.102.0/24 and 172.16.105.0/24


Task 1
NOTICE!
OSPF does not have to be enabled on Tunnel interface. I did it for practice purpose only!

Ensure 172.16.105.0/24 (R5) can reach 172.16.102.0/24 (R2). Use GRE tunnel to accomplish the goal.

R3 Configuration:

!

interface Tunnel0
 ip address 10.1.34.3 255.255.255.0
 tunnel source Loopback0
 tunnel destination 172.16.104.4
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 10.1.13.3 0.0.0.0 area 0
 network 10.1.34.3 0.0.0.0 area 0
 network 172.16.103.3 0.0.0.0 area 0
!

router bgp 134
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.34.4 remote-as 134
 neighbor 10.1.34.4 next-hop-self
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

R4 Configuration:

!

interface Tunnel0
 ip address 10.1.34.4 255.255.255.0
 tunnel source Loopback0
 tunnel destination 172.16.103.3
!

router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 10.1.34.4 0.0.0.0 area 0
 network 10.1.124.4 0.0.0.0 area 0
 network 172.16.104.4 0.0.0.0 area 0
!

router bgp 134
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 network 172.16.104.0 mask 255.255.255.0
 network 172.16.144.0 mask 255.255.255.0
 neighbor 10.1.34.3 remote-as 134
 neighbor 10.1.34.3 next-hop-self
 neighbor 10.1.124.2 remote-as 20
 no auto-summary

!

Verification:

Pic. 2 - GRE Tunnel.

Pic. 3 - BGP Session Over Tunnel0.

Pic. 4 - Tunnel Interface OSPF-Enabled.

Pic. 5 - 0SPF Adjacency Between R3 and R4.

Pic. 6 - BGP Table on R3.

Pic. 7 - BGP Table on R4.

Pic. 8 - Ping Test.

Lab 89 - non-BGP Transit with IGP Redistribution

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Notice!
Router R1 is NOT running BGP in AS 134.

Initial Configuration:

BGP Peering:

• R2 EBGP with R4
• R3 IBGP with R4
• R3 EBGP with R5
  

OSPF Configuration:
Routers R1, R3, and R4 should run OSPF area 0. Do NOT advertise loopbacks of these routers into OSPF.


Task 1
Configure BGP and OSPF as per topology diagram.

Task 2
Ensure 172.16.105.0/24 (R5) can reach 172.16.102.0/24 (R2). Use IGP redistribution to accomplish the goal.

Lab Solution

Task 1

Configure BGP and OSPF as per topology diagram.

R1 Configuration:

!

router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 10.1.13.1 0.0.0.0 area 0
 network 10.1.124.1 0.0.0.0 area 0

!

R2 Configuration:

!

router bgp 20
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.124.4 remote-as 134
 no auto-summary

!

R3 Configuration:

!

router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 10.1.13.3 0.0.0.0 area 0

!

router bgp 134
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 10.1.124.4 remote-as 134
 neighbor 10.1.124.4 next-hop-self
 no auto-summary
!

R4 Configuration:

!

router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 10.1.124.4 0.0.0.0 area 0
!

router bgp 134
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 network 172.16.104.0 mask 255.255.255.0
 network 172.16.144.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 134
 neighbor 10.1.124.2 remote-as 20
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 134
 no auto-summary

!

Pic. 2 - R2's BGP Table.

Pic. 3 - Ping Fails.

Pic. 4 - R5's BGP Table.

Notice!

R1 is NOT running BGP. It creates a 'black hole' between 172.16.102.0/24 and 172.16.105.0/24. Since it is not running BGP in never receives the two subnets in question. Packets traversing R1 are being dropped. The 'synchronization' rule was supposed to protect system from such situations. Now, the synchronization is turned off by default!

Pic. 5 - R1's Routing Table.

Task 2
Ensure 172.16.105.0/24 (R5) can reach 172.16.102.0/24 (R2). Use IGP redistribution to accomplish the goal.

R3 Configuration:

!

ip prefix-list BGP_PRFX seq 5 permit 172.16.105.0/24

!

route-map BGP_TO_OSPF permit 10
 match ip address prefix-list BGP_PRFX
!

router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 redistribute bgp 134 subnets route-map BGP_TO_OSPF
 network 10.1.13.3 0.0.0.0 area 0

!

R4 Configuration:

!

ip prefix-list BGP_PRFX seq 5 permit 172.16.102.0/24

!

route-map BGP_TO_OSPF permit 10
 match ip address prefix-list BGP_PRFX
!

router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 redistribute bgp 134 subnets route-map BGP_TO_OSPF
 network 10.1.124.4 0.0.0.0 area 0

!

Verification:

Pic. 6 - Ping Test.

Notice!

If the prefixes have been learned using EBGP peer the redistribution from BGP into IGP works by default.

If BGP router receives the prefixes from IBGP peer, the redistribution from BGP into IGP protocol does NOT work by default. It is a loop prevention mechanism. In order to be able to redistribute them you must use the following command under the BGP process:

bgp redistribute internal

Caution must be taken when using this solution since it is prone to create routing loops.

Lab 88 - BGP Auto-Summary

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure EBGP session between R1 and R4. R4 should advertise an aggregate 172.16.0.0 instead of individual subnets. Do not use 'aggregate-address' command to accomplish this.

Lab Solution

Task 1

Configure EBGP session between R1 and R4. R4 should advertise an aggregate 172.16.0.0 instead of individual subnets. Do not use 'aggregate-address' command to accomplish this.

R1 Configuration:

!

router bgp 10
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 10.1.124.4 remote-as 40
 no auto-summary

!

R4 Configuration:

!

router bgp 40
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 network 172.16.0.0
 neighbor 10.1.124.1 remote-as 10
 auto-summary

!

Notice!
BGP 'auto-summary' command allows to use a classful 'network' statement (contrary to the situation when auto-summary is disabled). Also, when redistributing subnets into BGP, auto-summary is going to install and advertise them as classful networks.

Verification:

Pic. 2 - BGP Table on R1.

Lab 87 - BGP Authentication

Prerequisites: CCNP level skills.

Note!
Use Lab 86 configuration.

Topology

Pic. 1 - Topology Diagram.

 Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure BGP authentication between R1 and R3. Use the password Cisco13.

Lab Solution

Task 1

Configure BGP authentication between R1 and R3. Use password Cisco13.

R1 Configuration:

!

router bgp 10
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 30
 neighbor 172.16.103.3 password Cisco13
 neighbor 172.16.103.3 disable-connected-check
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

R3 Configuration:

!

router bgp 30
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 172.16.101.1 remote-as 10
 neighbor 172.16.101.1 password Cisco13
 neighbor 172.16.101.1 disable-connected-check
 neighbor 172.16.101.1 update-source Loopback0
 no auto-summary

!

Notice!
BGP supports MD5 authentication only.


Verification:

Pic. 2 - BGP Authentication.

Lab 86 - BGP Disable-Connected-Check

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

 Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure EBGP between R1 and R3 in such a way that it can survive either Frame-Relay or HDLC link failure. Do not use ebgp-multihop command.

Lab Solution

Task 1
Configure EBGP between R1 and R3 in such a way that it can survive either Frame-Relay or HDLC link failure. Do not use ebgp-multihop command.

R1 Configuration:

!

ip route 172.16.103.0 255.255.255.0 10.1.0.3
ip route 172.16.103.0 255.255.255.0 10.1.13.3

!

router bgp 10
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 30
 neighbor 172.16.103.3 disable-connected-check
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

R3 Configuration:

!

ip route 172.16.101.0 255.255.255.0 10.1.0.1
ip route 172.16.101.0 255.255.255.0 10.1.13.1
!

router bgp 30
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 172.16.101.1 remote-as 10
 neighbor 172.16.101.1 disable-connected-check
 neighbor 172.16.101.1 update-source Loopback0
 no auto-summary

!

Notice!

This option (disable-connected-check) does not increment TTL but relies on the fact that the routers ARE directly connected only peering between loopbacks is used. The difference between this and ebgp-multihop is that in the latter one we can tune TTL value allowing multiple transit routers between the two BGP peers. In the former option (disable-connected-check), the routers must be directly connected (1 hop since TTL=1).

Pic. 2 - Neighbor Details.

Notice!
Consider the topology (pic. 1). Assume there are three paths between R1 and R3 in the routing table via S0/0, S0/1 and F1/0. Both S0/0 and S0/1 are down. The remaining path from R1 to R3 loopback is via F1/0 (R2 is the next-hop).

• If I use the command: neighbor disable-connected-check, the BGP session is going to time out after 180 seconds (neighbor down).
• If I use the command: neighbor ebgp-multihop 2, the BGP session is going to survive.

Lab 85 - EBGP Multihop

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

 Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure EBGP between R1 and R3 in such a way that it can survive either Frame-Relay or HDLC link failure.

Lab Solution

Task 1
Configure EBGP between R1 and R3 in such a way that it can survive either Frame-Relay or HDLC link failure.

R1 Configuration:

!

ip route 172.16.103.0 255.255.255.0 10.1.0.3
ip route 172.16.103.0 255.255.255.0 10.1.13.3
!

router bgp 10
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 172.16.103.3 remote-as 30
 neighbor 172.16.103.3 ebgp-multihop 2
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

R3 Configuration:

!
ip route 172.16.101.0 255.255.255.0 10.1.0.1
ip route 172.16.101.0 255.255.255.0 10.1.13.1
!

router bgp 30
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 172.16.101.1 remote-as 10
 neighbor 172.16.101.1 ebgp-multihop 2
 neighbor 172.16.101.1 update-source Loopback0
 no auto-summary

!

Notice!

When EBGP sessions are configured it is assumed that the EBGP peer is directly connected. The TTL is automatically set to 1. This way, session between loopback would not work. EBGP-multihop command changes the TTL (here: 2 hops) allowing session to be established.

Verification:

Pic. 2 - BGP Session Established.

Pic. 3 - Neighbor Details.

Lab 84 - BGP Next-Hop on Broadcast and NBMA Networks

Prerequisites: CCNP level skills.

Topology

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure BGP on all routers according to the topology diagram. Advertise all loopbacks using 'network' statement. Check the next-hop behavior on LAN link connecting R1, R2 and R4.

Lab Solution

Task 1

Configure BGP on all routers according to the topology diagram. Advertise all loopbacks using 'network' statement. Check the next-hop behavior on LAN link connecting R1, R2 and R4.

R1 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 10.1.13.3 remote-as 13
 neighbor 10.1.13.3 next-hop-self
 neighbor 10.1.124.4 remote-as 40
 no auto-summary

!

R2 Configuration:

!

router bgp 20
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 network 172.16.102.0 mask 255.255.255.0
 neighbor 10.1.124.4 remote-as 40
 no auto-summary

!

R3 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.13.1 remote-as 13
 neighbor 10.1.13.1 next-hop-self
 neighbor 10.1.35.5 remote-as 50
 no auto-summary

!

R4 Configuration:

!

router bgp 40
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 network 172.16.104.0 mask 255.255.255.0
 network 172.16.144.0 mask 255.255.255.0
 neighbor 10.1.124.1 remote-as 13
 neighbor 10.1.124.2 remote-as 20
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 network 172.16.105.0 mask 255.255.255.0
 neighbor 10.1.35.3 remote-as 13
 no auto-summary

!

Verification:

Pic. 2 - R5' BGP Table.

Pic. 3 - R1's BGP Prefix from AS 20.

Notice!
Even though R1 receives the prefix over EBGP session the next-hop address is R2's address rather than R4's. This is the default behavior on Broadcast and NBMA networks. Pay a special attention to NBMA since the circuits may not be fully meshed and the reachability to the next-hop address may be a problem.

Pic. 4 - Prefix Details.

Notice!
Next-Hop Attribute: 10.1.124.2
Advertising Router: 10.1.124.4
Advertising Router ID: 4.4.4.4

Lab 83 - BGP Synchronization

Prerequisites: CCNP level skills.

Topology

Note!

Use Lab 82 configuration to complete this lab.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Enable BGP Synchronization on R1. Ensure R1 can reach 172.16.105.0/24.

Lab Solution

Task 1

Enable BGP Synchronization on R1. Ensure R1 can reach 172.16.105.0/24.

Notice!

Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.

BGP synchronization explained at:

http://docwiki.cisco.com/wiki/Internetworking_Case_Studies_--_Using_the_Border_Gateway_Protocol_for_Interdomain_Routing#Synchronization
  
R1 Configuration:

!

router bgp 13
 synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 172.16.103.3 remote-as 13
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

Verification:

Pic. 2 - BGP Table on R1.

Notice!
The code for the best path '>' has been removed since the prefix is not synchronized with with IGP (IBGP loop prevention mechanism). It takes about a minute to see the change in the BGP table. The result: no reachability to 172.16.105.0/24 (prefix will not be installed in the routing table).

Pic. 3 - Prefix Details.

R3 Configuration:

!

ip prefix-list BGP_PREFIX seq 5 permit 172.16.105.0/24

!

route-map BGP_TO_OSPF permit 10
 match ip address prefix-list BGP_PREFIX
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 redistribute bgp 13 subnets route-map BGP_TO_OSPF
 network 10.1.13.3 0.0.0.0 area 0
 network 172.16.103.3 0.0.0.0 area 0

!

Verification:

Pic. 4 - R1's OSPF Routing Table.

Pic. 5 - R1's BGP Details

Pic. 6 - Reachability's Restored.

Lab 82 - BGP External Session (EBGP) and Advertisements

Prerequisites: CCNP level skills.

Topology

Note!

Use Lab 81 configuration to complete this lab.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure EBGP session between R3 and R5.

Task 2
Advertise loopback addresses into BGP on R1, R3 and R5. On R5 do not use the 'network' statement. Ensure the reachability between the advertised subnets.

Lab Solution


Task 1
Configure EBGP session between R3 and R5.  

R3 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 13
 neighbor 172.16.101.1 update-source Loopback0
 no auto-summary

!

R5 Configuration:

!

router bgp 50
 no synchronization
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 neighbor 10.1.35.3 remote-as 13
 no auto-summary

!

Verification:

Pic. 2 - EBGP Session between R3 and R5.

Pic. 3 - Neighbor Details. 

Task 2

Advertise loopback addresses into BGP on R1, R3 and R5. On R5 don not use 'network' statement. Ensure the reachability between the advertised subnets.

R1 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 172.16.101.0 mask 255.255.255.0
 neighbor 172.16.103.3 remote-as 13
 neighbor 172.16.103.3 update-source Loopback0
 no auto-summary

!

Notice!
'Network' statement in BGP does advertise the networks (unlike in IGP protocols). The network/subnet must have the EXACT match in the routing table (network/network_mask). If the subnet is being advertised (not a major class), the 'mask' keyword must be used.

Verification:

Pic. 4 - R1's BGP Table.

Notice!
Subnets advertised locally always set the two BGP attributes as

• Next-Hop = 0.0.0.0
• Weight = 32768
• Path = empty

In addition to this, if the 'network' statement is used to advertise a network/subnet, origin code is set to 'i' = IGP.

Pic. 5 - R3 Receives the Prefix.

Notice!
R3 receives 172.16.101.0/24 but is marked as RIB-Failure. This is due to the fact that Administrative Distance of IBGP is 200, and the same prefix is advertised by OSPF with the Administrative Distance 110.  

Notice!

Next-hop attribute point to the source of BGP advertisements (R1's Loopback0): 172.16.101.1.


Notice!
R3 automatically assigns Local Preference: 100. The same Local Preference value is assigned by R1 (originator of the prefix). This can be seen on R1 using this command:

Pic. 6 - R1's BGP Prefix Details.

Pic 7 - R5 Receives the Prefix

Notice!
R3 advertising the prefix to an EBGP neighbor, prepends the AS (13).

R3 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 13
 neighbor 172.16.101.1 update-source Loopback0
 no auto-summary

!

R5 Configuration:

!

ip prefix-list LO seq 5 permit 172.16.105.0/24

!

route-map CONN_TO_BGP permit 10
 match ip address prefix-list LO
!

router bgp 50
 no synchronization
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 redistribute connected route-map CONN_TO_BGP
 neighbor 10.1.35.3 remote-as 13
 no auto-summary

!

Verification:

Pic. 8 - Prefix Redistributed into BGP on R5.

Notice!
The origin attribute for BGP redistributed prefixes is set to '?' = incomplete.

Notice!
R1 is going to have problem with the reachability to 172.16.105.0/24. The next-hop attribute set by EBGP peer (BGP neighbor) is not changed (except for connections in the same broadcast domain). R1 has no reachability to the next-hop 10.1.35.5.

Pic. 9 - R1's Next-Hop Inaccessible.

Pic. 10 - Detailed Output.

There's bunch of ways to resolve this issue. For now (some time later more on that), the 'next-hop-self' is going to be used.

R3 Configuration:

!

router bgp 13
 no synchronization
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 network 172.16.103.0 mask 255.255.255.0
 neighbor 10.1.35.5 remote-as 50
 neighbor 172.16.101.1 remote-as 13
 neighbor 172.16.101.1 update-source Loopback0
 neighbor 172.16.101.1 next-hop-self
 no auto-summary

!

Pic. 11 - Next-Hop Address Changed.

Pic. 12 - Proper Ping Test.