Chapter 10 Border Gateway Protocol
Lab 10-1: Establishing Neighbor Adjacencies
In the following labs, we will explore the deployment of the Border Gateway Protocol (BGP) in the network topology illustrated in Figure 10-1.
Figure 10-1 iBGP Lab Topology
We will begin by turning our focus toward iBGP peering relationships.
The initial configuration files used in this lab can be found by downloading the BGP-Lab-1.txt file and subsequently applying those configurations on a device- by-device basis.
Task 1
Configure routers R1–R4 in AS 100. These routers should create interior-BGP peer sessions between them in a full-mesh manner. Ensure that these routers advertise their loopback0 interface in this autonomous system (AS). Use their F0/0 interface for establishing an adjacency.
!On R1:
R1(config)# router bgp 100
R1(config-router)# neighbor 10.1.1.2 remote-as 100
R1(config-router)# neighbor 10.1.1.3 remote-as 100
R1(config-router)# neighbor 10.1.1.4 remote-as 100
R1(config-router)# network 1.0.0.0
!On R2:
R2(config)# router bgp 100
R2(config-router)# neighbor 10.1.1.1 remote-as 100
R2(config-router)# neighbor 10.1.1.3 remote-as 100
R2(config-router)# neighbor 10.1.1.4 remote-as 100
R2(config-router)# network 2.0.0.0
You should see the following console message stating that an adjacency is established with neighbor 10.1.1.1:
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
!On R3:
R3(config)# router bgp 100
R3(config-router)# neighbor 10.1.1.1 remote-as 100
R3(config-router)# neighbor 10.1.1.2 remote-as 100
R3(config-router)# neighbor 10.1.1.4 remote-as 100
R3(config-router)# network 3.0.0.0
You should see the following console messages:
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up
!On R4:
R1(config)# router bgp 100
R4(config-router)# neighbor 10.1.1.1 remote-as 100
R4(config-router)# neighbor 10.1.1.2 remote-as 100
R4(config-router)# neighbor 10.1.1.3 remote-as 100
R4(config-router)# network 4.0.0.0
You should also see these console messages:
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 10.1.1.3 Up
%BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*>i2.0.0.0 10.1.1.2 0 100 0 i
*>i3.0.0.0 10.1.1.3 0 100 0 i
*>i4.0.0.0 10.1.1.4 0 100 0 i
The following explains the output of the preceding show command:
The * means that the entry in the table is valid.
The > means that this is the best entry for a given prefix.
The i means that the entry was learned via an iBGP; this is the i to the right of the greater-than sign (>) in the network column. The letter i under the path column specifies the origin of the route.
The Network column identifies the prefix entry for the network(s). If the mask is omitted, the default mask is assumed.
The Next Hop column identifies the next hop’s IP address to reach the specified network address. If it’s set to 0.0.0.0, it identifies a prefix that the local router has advertised.
The Metric column identifies the inter-as metric, or the MED attribute, which is set to zero by default.
The LocPrf column identifies the “local preference” attribute. This is used in the route selection process carried out within the local AS only. With the local-pref attribute, the higher value has more preference. By default, the prefixes that are received from a peer AS are tagged with a local-pref value of 100; this behavior can be changed to influence the best-path-selection process. The changed value is only advertised to iBGP peers. When the local router advertises a prefix, no local-pref value is seen in the output of the show ip bgp command. The default value of 100 can be changed by the bgp default local-preference command.
The Weight column identifies the weight attribute. The prefixes that are received via a neighbor (iBGP or exterior Border Gateway Protocol [eBGP]) will have a weight attribute of 0, but the prefixes that are originated by the local router will have a weight value of 32768. This attribute overrides any other attribute for performing best-path determination.
The Path column identifies the path attribute. If the prefixes were originated or learned via an iBGP neighbor, the path column will have the letter i without any AS number (ASN). If the prefix was learned through another AS, then this column will have the AS number(s) followed by the letter i. The ASNs indicate which AS advertised the prefix. The maximum number of AS instances a prefix can traverse through is 255.
R4# show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 100 13 13 6 0 0 00:07:34 1
10.1.1.2 4 100 13 13 6 0 0 00:07:32 1
10.1.1.3 4 100 12 13 6 0 0 00:07:23 1
Task 2
Reconfigure the routers in AS 100 based on the following policy:
Authentication must be enabled between the peers using “cisco” as the password.
The peer session must be established based on the loopback0’s IP address.
These routers should only advertise their loopback1 interface in BGP.
Provide Network Layer Reachability Information (NLRI) to the loopback0 interface using RIPv2.
Use peer groups to accomplish this task.
Cisco’s implementation of BGP in IOS 12.0(5)T and earlier releases supports BGP versions 2, 3, and 4, with dynamic negotiation down to Version 2. However, in IOS version 12.0(6)T and later, Cisco routers only support version 4, and they do not support dynamic negotiation down to version 2.
!On R1:
R1(config)# no router bgp 100
R1(config)# router bgp 100
R1(config-router)# network 192.168.1.0
R1(config-router)# neighbor TST peer-group
R1(config-router)# neighbor TST remote-as 100
R1(config-router)# neighbor TST update-source loopback0
R1(config-router)# neighbor TST password cisco
R1(config-router)# neighbor 2.2.2.2 peer-group TST
R1(config-router)# neighbor 3.3.3.3 peer-group TST
R1(config-router)# neighbor 4.4.4.4 peer-group TST
R1(config-router)# router rip
R1(config-router)# no auto-summary
R1(config-router)# version 2
R1(config-router)# network 10.0.0.0
R1(config-router)# network 1.0.0.0
!On R2:
R2(config)# no router bgp 100
R2(config)# router bgp 100
R2(config-router)# network 192.168.2.0
R2(config-router)# neighbor TST peer-group
R2(config-router)# neighbor TST remote-as 100
R2(config-router)# neighbor TST update-source loopback0
R2(config-router)# neighbor TST password cisco
R2(config-router)# neighbor 1.1.1.1 peer-group TST
R2(config-router)# neighbor 3.3.3.3 peer-group TST
R2(config-router)# neighbor 4.4.4.4 peer-group TST
R2(config-router)# router rip
R2(config-router)# no auto-summary
R2(config-router)# version 2
R2(config-router)# network 10.0.0.0
R2(config-router)# network 2.0.0.0
You should see the following console message stating that an adjacency was established with 1.1.1.1 (R1):
%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
!On R3:
R3(config)# no router bgp 100
R3(config)# router bgp 100
R3(config-router)# network 192.168.3.0
R3(config-router)# neighbor TST peer-group
R3(config-router)# neighbor TST remote-as 100
R3(config-router)# neighbor TST update-source loopback0
R3(config-router)# neighbor TST password cisco
R3(config-router)# neighbor 1.1.1.1 peer-group TST
R3(config-router)# neighbor 2.2.2.2 peer-group TST
R3(config-router)# neighbor 4.4.4.4 peer-group TST
R3(config-router)# router rip
R3(config-router)# no auto-summary
R3(config-router)# version 2
R3(config-router)# network 10.0.0.0
R3(config-router)# network 3.0.0.0
You should see the following console messages stating that an adjacency was established with 1.1.1.1 (R1) and 2.2.2.2 (R2):
%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
!On R4:
R4(config)# no router bgp 100
R4(config)# router bgp 100
R4(config-router)# network 192.168.4.0
R4(config-router)# neighbor TST peer-group
R4(config-router)# neighbor TST remote-as 100
R4(config-router)# neighbor TST update-source loopback0
R4(config-router)# neighbor TST password cisco
R4(config-router)# neighbor 1.1.1.1 peer-group TST
R4(config-router)# neighbor 2.2.2.2 peer-group TST
R4(config-router)# neighbor 3.3.3.3 peer-group TST
R4(config-router)# router rip
R4(config-router)# no auto-summary
R4(config-router)# version 2
R4(config-router)# network 10.0.0.0
R4(config-router)# network 4.0.0.0
You should see the following console messages stating that an adjacency was established with 1.1.1.1 (R1), 2.2.2.2 (R2), and 3.3.3.3 (R3):
%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
To verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 0.0.0.0 0 32768 i
*>i192.168.2.0 2.2.2.2 0 100 0 i
*>i192.168.3.0 3.3.3.3 0 100 0 i
*>i192.168.4.0 4.4.4.4 0 100 0 i
Now let’s move to R1 and continue the verification process there.
!On R1:
R1# show ip bgp peer-group TST
BGP peer-group is TST, remote AS 100
BGP version 4
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP neighbor is TST, peer-group internal, members:
2.2.2.2 3.3.3.3 4.4.4.4
Index 0, Offset 0, Mask 0x0
Update messages formatted 0, replicated 0
Number of NLRIs in the update sent: max 0, min 0
Note The output of the show ip bgp peer-group TST command reveals the IP address of the members of the peer group. One of the major benefits of a peer group is that it can reduce the administrative overhead by cutting down redundant configuration on the routers.
Erase the startup configuration and reload the routers before proceeding to the next lab.
Lab 10-2: Router Reflectors
A route reflector is a BGP router that is allowed to ignore the iBGP loop avoidance rule and, as such, is allowed to advertise updates received from an iBGP peer to another iBGP peer under specific conditions. This means that the deployment of route reflectors can eliminate the BGP full-mesh requirement. Just this one simple change in behavior allows us to simplify the building of our iBGP networks. Plus, it makes them more readily scalable. RFC 4456 describes BGP route reflection. Route reflectors make all this possible, as follows:
By dividing iBGP routers into route reflectors, route reflector clients, and non-client peers.
Routes received from a route reflector client are reflected to both client and non-client neighbors.
Routes received from a non-client neighbor are reflected to route reflector clients only.
By setting the nontransitive Originator-ID attribute in the reflected update if it is not already set. The Originator-ID is set to the peer Router-ID that advertised the prefix to the router reflector.
By adding the Cluster-ID to the nontransitive Cluster-list attribute in the reflected update. By default, the Cluster-ID is set to the BGP Router-ID.
A route reflector will only reflect BGP best routes. If more than one update is received for the same destination, only the BGP best route will be reflected.
A route reflector is not allowed to change any of the following attributes of the reflected routes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
The issue with the deployment of route reflectors is the fact that route reflectors ignore the primary iBGP loop-prevention mechanism. This would be an untenable situation if route reflectors did not introduce their own loop-detection and -prevention mechanism:
If a router receives an iBGP route with the Originator-ID attribute set to its own Router-ID, the route is discarded.
If a route reflector receives a route with a Cluster-list attribute containing its Cluster-ID, the route is discarded.
Figure 10-2 illustrates the simple topology we will use to explore the configuration and benefits of employing route reflectors as a solution to prevent the administrative overhead associated with the full-mesh requirement for iBGP peers we explored in the previous lab.
The initial configuration files used in this lab can be found by downloading the BGP-Lab-2.txt file and subsequently applying those configurations on a device- by-device basis.
Task 1
Configure BGP AS 100 on all routers and ensure that the routers can successfully establish an iBGP peer session with each other. These routers should only advertise their loopback0 interface in BGP.
!On R1:
R1(config)# router bgp 100
R1(config-router)# network 1.0.0.0
R1(config-router)# neighbor 12.1.1.2 remote-as 100
R1(config-router)# neighbor 13.1.1.3 remote-as 100
!On R2:
R2(config)# router bgp 100
R2(config-router)# network 2.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 13.1.1.3 remote-as 100
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 100
R3(config-router)# network 3.0.0.0
R3(config-router)# neighbor 13.1.1.1 remote-as 100
R3(config-router)# neighbor 12.1.1.2 remote-as 100
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 13.1.1.1 Up
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*>i2.0.0.0 12.1.1.2 0 100 0 i
*>i3.0.0.0 13.1.1.3 0 100 0 i
R1# show ip route bgp | include B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
B 2.0.0.0/8 [200/0] via 12.1.1.2, 00:07:34
B 3.0.0.0/8 [200/0] via 13.1.1.3, 00:05:27
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 12.1.1.1 0 100 0 i
*> 2.0.0.0 0.0.0.0 0 32768 i
R2# show ip route bgp | include B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
B 1.0.0.0/8 [200/0] via 12.1.1.1, 00:08:56
Network 3.0.0.0 is not in the BGP table of R2. Let’s check the neighbor adjacency:
R2# show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
12.1.1.1 4 100 16 16 4 0 0 00:10:33 1
13.1.1.3 4 100 0 0 1 0 0 never Idle
The neighbor is in an idle state. Do we have reachability to this neighbor? Let’s verify using ping:
R2# ping 13.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.1.1.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Let’s check the routing table:
R2# show ip route 13.1.1.3
% Network not in table
We cannot see 13.1.1.3 in the routing table. This is one reason why an IGP should be configured within an AS. This IGP should provide reachability to the links within the AS. Let’s run Open Shortest Path First (OSPF) on the links that interconnect the routers:
!On R1:
R1(config)# router ospf 1
R1(config-router)# router-id 0.0.0.1
R1(config-router)# network 12.1.1.1 0.0.0.0 area 0
R1(config-router)# network 13.1.1.1 0.0.0.0 area 0
!On R2:
R2(config)# router ospf 1
R2(config-router)# router-id 0.0.0.2
R2(config-router)# network 12.1.1.2 0.0.0.0 area 0
!On R3:
R3(config)# router ospf 1
R3(config-router)# router-id 0.0.0.3
R3(config-router)# network 13.1.1.3 0.0.0.0 area 0
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.2 Up
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 13.1.1.1 0 100 0 i
*>i2.0.0.0 12.1.1.2 0 100 0 i
*> 3.0.0.0 0.0.0.0 0 32768 i
R3# ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R3# ping 2.2.2.2 source loopback0loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
Task 2
You receive an email from management stating that within the next 12 months, 20 additional routers will be added to this AS. In order to minimize the number of peer sessions within this AS, you decide to implement route reflectors.
Configure R1 as a route reflector for this AS:
!On R1:
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 route-reflector-client
R1(config-router)# neighbor 13.1.1.3 route-reflector-client
You should see that the adjacency resets itself and then it comes up:
%BGP-5-ADJCHANGE: neighbor 12.1.1.2 Down RR client config change
%BGP_SESSION-5-ADJCHANGE: neighbor 12.1.1.2 IPv4 Unicast topology base removed
from session RR client config change
%BGP-5-ADJCHANGE: neighbor 12.1.1.2 Up
%BGP-5-ADJCHANGE: neighbor 13.1.1.3 Down RR client config change
%BGP_SESSION-5-ADJCHANGE: neighbor 13.1.1.3 IPv4 Unicast topology base removed
from session RR client config change
%BGP-5-ADJCHANGE: neighbor 13.1.1.3 Up
Note Once the route reflector is configured, there is no need for R2 and R3 to establish an iBGP peer session. The route reflector (R1) will reflect the prefixes from one iBGP neighbor to another:
!On R2:
R2(config)# router bgp 100
R2(config-router)# no neighbor 13.1.1.3 remote-as 100
!On R3:
R3(config)# router bgp 100
R3(config-router)# no neighbor 12.1.1.2 remote-as 100
Let’s verify the configuration:
!On R3:
R3# show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
13.1.1.1 4 100 11 8 7 0 0 00:04:50 2
R3# show ip bgp | begin Net
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 13.1.1.1 0 100 0 i
*>i2.0.0.0 12.1.1.2 0 100 0 i
*> 3.0.0.0 0.0.0.0 0 32768 i
R3# ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
R3# ping 2.2.2.2 source loopback0loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
In order for all iBGP speakers in an AS to exchange routes with one another, they must be fully meshed (every router must establish a peer session with every other router). This is because of a rule called iBGP split-horizon, which states that when a BGP speaker receives an update from an iBGP peer, it will not advertise that update to another iBGP peer.
Route reflectors can be configured to reduce the number of peer sessions that must be established between the routers within a given AS. If a route reflector is used, all iBGP speakers need not be fully meshed. In this model, the router that is configured to be the route reflector must have a peer session established to every client, and the clients must establish a peer session with the route reflector only. The route reflector will reflect prefixes learned from one client to another client (or clients).
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*>i2.0.0.0 12.1.1.2 0 100 0 i
*>i3.0.0.0 13.1.1.3 0 100 0 i
The output of the following show commands reveal the fact that prefixes 2.0.0.0/8 and 3.0.0.0/8 were received from a route reflector client:
R1# show ip bgp 2.0.0.0
BGP routing table entry for 2.0.0.0/8, version 6
Paths: (1 available, best # 1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
Local, (Received from a RR-client)
10.1.12.2 from 10.1.12.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1# show ip bgp 3.0.0.0
BGP routing table entry for 3.0.0.0/8, version 9
Paths: (1 available, best # 1, table default)
Advertised to update-groups:
2
Local, (Received from a RR-client)
13.1.1.3 from 13.1.1.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
The output of the following show commands reveals the Originator-ID and the Cluster-list of prefix 3.0.0.0/8:
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 12.1.1.1 0 100 0 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*>i3.0.0.0 13.1.1.3 0 100 0 i
R2# show ip bgp 3.0.0.0
BGP routing table entry for 3.0.0.0/8, version 7
Paths: (1 available, best # 1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
13.1.1.3 (metric 128) from 12.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 3.3.3.3, Cluster list: 1.1.1.1
rx pathid: 0, tx pathid: 0x0
R2# ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-3: Conditional Advertisement and BGP Backdoor (Figure 10-3)
Figure 10-3 Conditional Advertisement and Backdoor Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-3.txt file and subsequently applying those configurations on a device- by-device basis.
Task 1
Configure R1 in AS 100 to establish an eBGP peer session with R2 and R3 in AS 200 and 300, respectively. R2 should not have a BGP peer session with R3. You should use their serial interface’s IP address to accomplish this task.
!On R1:
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 remote-as 200
R1(config-router)# neighbor 13.1.1.3 remote-as 300
!On R2:
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 remote-as 100
!On R3:
R3(config)# router bgp 300
R3(config-router)# neighbor 13.1.1.1 remote-as 100
Let’s verify the configuration:
!On R1:
R1# show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.12.2 4 200 3 3 1 0 0 00:00:39 0
10.1.13.3 4 300 3 3 1 0 0 00:00:32 0
Task 2
Configure R1, R2, and R3 to advertise their loopback0 interface in BGP:
!On R1:
R1(config)# router bgp 100
R1(config-router)# network 1.0.0.0
!On R2:
R2(config)# router bgp 200
R2(config-router)# network 2.0.0.0
!On R3:
R3(config)# router bgp 300
R3(config-router)# network 3.0.0.0
Let’s verify the configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 2.0.0.0 13.1.1.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Task 3
Configure RIPv2 and EIGRP 100 on the routers as follows:
Configure RIPv2 on networks 12.1.1.0/24 and 13.1.1.0/24; disable auto-summarization.
R2 and R3 should advertise their F0/0 and loopback1 interfaces in EIGRP AS 100.
!On R1:
R1(config)# router rip
R1(config-router)# no auto-summary
R1(config-router)# version 2
R1(config-router)# network 12.0.0.0
R1(config-router)# network 13.0.0.0
!On R2:
R2(config)# router rip
R2(config-router)# no auto-summary
R2(config-router)# version 2
R2(config-router)# network 12.0.0.0
R2(config)# router eigrp 100
R2(config-router)# network 23.1.1.2 0.0.0.0
R2(config-router)# network 10.1.2.2 0.0.0.0
!On R3:
R3(config)# router rip
R3(config-router)# no auto-summary
R3(config-router)# version 2
R3(config-router)# network 13.0.0.0
R3(config)# router eigrp 100
R3(config-router)# network 23.1.1.3 0.0.0.0
R3(config-router)# network 10.1.3.3 0.0.0.0
Let’s verify the configuration:
!On R2:
R2# show ip route eigrp | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.3.0/24 [90/156160] via 10.1.23.3, 00:00:52, FastEthernet0/0
R2# show ip route rip | begin Gate
Gateway of last resort is not set
13.0.0.0/24 is subnetted, 1 subnets
R 13.1.1.0 [120/1] via 12.1.1.1, 00:00:15, Serial1/1
Task 4
Because network 23.1.1.0/24 is not advertised in BGP, if the Ethernet link between R2 and R3 goes down, the loopback1 networks of these two routers won’t have reachability to each other, even though there is a redundant link between the two routers through BGP. Therefore, the administrator of R2 and R3 has decided that the loopback1 interfaces of R2 and R3 should be advertised in BGP to provide redundancy.
Configure these routers to accommodate this decision:
!On R2:
R2(config)# router bgp 200
R2(config-router)# network 10.1.2.0 mask 255.255.255.0
!On R3:
R3(config)# router bgp 300
R3(config-router)# network 10.1.3.0 mask 255.255.255.0
Let’s verify the configuration:
!On R2:
R2# show ip route bgp | begin Gate
Gateway of last resort is not set
B 1.0.0.0/8 [20/0] via 12.1.1.1, 00:16:27
B 3.0.0.0/8 [20/0] via 12.1.1.1, 00:15:57
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.1.3.0/24 [20/0] via 12.1.1.1, 00:00:13
!On R3:
R3# show ip route bgp | begin Gate
Gateway of last resort is not set
B 1.0.0.0/8 [20/0] via 13.1.1.1, 00:17:06
B 2.0.0.0/8 [20/0] via 13.1.1.1, 00:16:05
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.1.2.0/24 [20/0] via 13.1.1.1, 00:01:22
Task 5
After you implement the previous task, the administrator realizes that the traffic between networks 10.1.2.0/24 and 10.1.3.0/24 is taking a suboptimal path and is not using the direct path between R2 and R3.
Implement a BGP solution to fix this problem. You should not use the distance, PBR, or any global config mode command to accomplish this task.
Let’s look at the suboptimal path:
!On R3:
R3# traceroute 10.1.2.2 numeric
Type escape sequence to abort.
Tracing the route to 10.1.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 13.1.1.1 16 msec 16 msec 12 msec
2 12.1.1.2 32 msec * 28 msec
R3# show ip route 10.1.2.2
Routing entry for 10.1.2.0/24
Known via "bgp 300", distance 20, metric 0
Tag 100, type external
Last update from 13.1.1.1 00:07:02 ago
Routing Descriptor Blocks:
* 13.1.1.1, from 13.1.1.1, 00:07:02 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100
MPLS label: none
We can see that R2 and R3 are taking a suboptimal path to reach each other’s loopback1 interface.
The BGP backdoor option can help you accomplish this task. The backdoor keyword is added to the network statement. You should reference the network that is advertised to you and not the network that your local router is advertising:
!On R2:
R2(config)# router bgp 200
R2(config-router)# network 10.1.3.0 mask 255.255.255.0 backdoor
Let’s verify the configuration:
!On R2:
R2# show ip route 10.1.3.3
Routing entry for 10.1.3.0/24
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 10.1.23.3 on FastEthernet0/0, 00:00:56 ago
Routing Descriptor Blocks:
* 10.1.23.3, from 10.1.23.3, 00:00:56 ago, via FastEthernet0/0
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R2# traceroute 10.1.3.3 numeric
Type escape sequence to abort.
Tracing the route to 10.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 23.1.1.3 0 msec * 0 msec
We can see that R2 uses its direct connection (F0/0 interface) to reach the loopback1 interface of R3. The backdoor keyword causes BGP to use the administrative distance for BGP local routes, which by default is 200, instead of the administrative distance for BGP external routes. This allows the Routing Information Base (RIB) to select the IGP advertised route instead of eBGP’s advertisement.
Let’s look at the changes in the BGP table and table entry:
R2# show ip bgp
BGP table version is 6, local router ID is 10.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 12.1.1.1 0 100 300 i
*> 10.1.2.0/24 0.0.0.0 0 32768 i
r> 10.1.3.0/24 12.1.1.1 0 100 300 i
R2# show ip bgp 10.1.3.0
BGP routing table entry for 10.1.3.0/24, version 3
Paths: (1 available, best # 1, table default, RIB-failure(17) - next-hop mismatch)
Not advertised to any peer
Refresh Epoch 1
100 300
12.1.1.1 from 12.1.1.1 (1.1.1.1)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
R2# show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.1.3.0/24 12.1.1.1 Higher admin distance n/a
As you can see, the Routing Information Base rejected the router because it now has a higher administrative distance.
Let’s see the configured administrative distance for BGP local routes:
R2# show ip protocols | section bgp
Routing Protocol is "bgp 200"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
12.1.1.1
Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
12.1.1.1 20 00:16:39
Distance: external 20 internal 200 local 200
Now we need to test the redundancy. First, on R2, let’s shut down the F0/0 interface and verify reachability:
!On R2:
R2(config)# interface FastEthernet0/0
R2(config-if)# shutdown
R2# show ip route 10.1.3.3
Routing entry for 10.1.3.0/24
Known via "bgp 200", distance 200, metric 0
Tag 100, type locally generated
Last update from 12.1.1.1 00:00:42 ago
Routing Descriptor Blocks:
* 12.1.1.1, from 12.1.1.1, 00:00:42 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100
MPLS label: none
R2# traceroute 10.1.3.3 numeric
Type escape sequence to abort.
Tracing the route to 10.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.1 16 msec 16 msec 12 msec
2 13.1.1.3 32 msec * 28 msec
Next, let’s enable the F0/0 interface of R2 and configure the same on R3:
!On R2:
R2(config)# interface FastEthernet0/0
R2(config-if)# no shutdown
R2# show ip route 10.1.3.3
Routing entry for 10.1.3.0/24
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 10.1.23.3 on FastEthernet0/0, 00:00:33 ago
Routing Descriptor Blocks:
* 10.1.23.3, from 10.1.23.3, 00:00:33 ago, via FastEthernet0/0
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
!On R3:
R3(config)# router bgp 300
R3(config-router)# network 10.1.2.0 mask 255.255.255.0 backdoor
Let’s verify the configuration:
!On R3:
R3# show ip route eigrp | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.2.0/24 [90/156160] via 10.1.23.2, 00:00:20, FastEthernet0/0
!On R2:
R2# show ip route eigrp | begin Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.3.0/24 [90/156160] via 10.1.23.3, 00:07:07, FastEthernet0/0
Here’s a summary of what you learned:
R2 and R3 were receiving routing information for networks 10.1.2.0/24 and 10.1.3.0/24 from two different sources: BGP and EIGRP.
R2 and R3 were using the routing information from BGP because it had a lower administrative distance (20 for eBGP versus 90 for EIGRP).
The network statement with the backdoor option is a BGP solution to this problem. The BGP backdoor option assigns the BGP local route administrative distance of 200 to the advertised network, making the EIGRP-learned routes more attractive.
Task 6
Remove the IP address from the F0/0 interfaces of R2 and R3 and ensure that the F0/0 interfaces of both routers are in the administratively down state. You should also remove the loopback1 interface from these two routers.
!On R2 and R3:
Rx(config)# default interface FastEthernet0/0
Rx(config)# interface FastEthernet0/0
Rx(config-if)# shutdown
Rx(config)# no interface loopback 1
Task 7
Configure R1 based on the following policy:
If network 2.0.0.0/8 is up and it’s advertised to R1, R1 should not advertise its network 1.0.0.0/8 to R3.
R1 should advertise network 1.0.0.0/8 to R3 only if network 2.0.0.0/8 is down.
Before configuring this task, let’s verify the current BGP table of these routers:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 13.1.1.3 0 0 300 i
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 12.1.1.1 0 100 300 i
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 2.0.0.0 13.1.1.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
To implement conditional advertisement in BGP, the following reserved maps can be used:
advertise-map
non-exist-map
exist-map
inject-map
This situation calls for the use of the advertise-map and non-exist-map. Basically, using these two commands, we are saying, “Advertise network 1.0.0.0 only if network 2.0.0.0 is down; if network 2.0.0.0 is not down, then don’t advertise network 1.0.0.0.”
Step 1. Identify the prefixes using two access lists/prefix lists:
!On R1:
R1# sh access-lists
R1(config)# access-list 1 permit 1.0.0.0 0.255.255.255
R1(config)# access-list 2 permit 2.0.0.0 0.255.255.255
Step 2. Configure two route maps: one to reference access-list 1 and the second to reference access-list 2. To prevent confusion, you should choose meaningful names when configuring the route maps:
R1(config)# route-map Advertise permit 10
R1(config-route-map)# match ip address 1
R1(config-route-map)# exit
R1(config)# route-map NotThere permit 10
R1(config-route-map)# match ip address 2
R1(config-route-map)# exit
Step 3. The route maps are referenced by the advertise-map and non-exist-map options:
R1(config)# router bgp 100
R1(config-router)# neighbor 13.1.1.3 advertise-map Advertise non-exist-map NotThere
The neighbor command has the following route maps:
advertise-map: Specifies the name of the route map that will be advertised if the condition of the non-exist-map is met.
non-exist-map: Specifies the name of the route map that will be compared to the advertise-map. If the condition is met and no match occurs, the route will be advertised. If a match occurs, then the condition is not met and the route is withdrawn.
If network 2.0.0.0 is up, then network 1.0.0.0 should not be advertised to R3. Because all the networks are up and advertised, R1 should withdraw its network (1.0.0.0/8):
Note Network 2.0.0.0 is up, so network 1.0.0.0/8 should not be advertised to R3.
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 13.1.1.3 0 0 300 i
The following show command reveals that R1 does not advertise its network (1.0.0.0/8) to R3:
R1# show ip bgp neighbors 13.1.1.3 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.0.0.0 12.1.1.2 0 0 200 i
Let’s look at the status of the advertise-map:
R1# show ip bgp neighbor 13.1.1.3 | include map
Condition-map NotThere, Advertise-map Advertise, status: Withdraw
Now let’s verify this configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.0.0.0 13.1.1.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Now we need to test the condition:
!On R2:
R2(config)# interface loopback 0
R2(config-if)# shutdown
The output of the following show command reveals that network 2.0.0.0 is down and that R1 is advertising its network (1.0.0.0/8) to R3. It may take few seconds for this policy to be implemented.
!On R1:
R1# show ip bgp neighbors 13.1.1.3 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
Let’s see the status of the advertise-map:
R1# show ip bgp neighbor 13.1.1.3 | include map
Condition-map NotThere, Advertise-map Advertise, status: Advertise
Now let’s look at the test on R3:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Task 8
Remove the configuration commands entered in the previous task before you proceed to the next task. Ensure that the routers have the advertised networks in their BGP table:
!On R1:
R1(config)# no access-list 1
R1(config)# no access-list 2
R1(config)# no route-map Advertise
R1(config)# no route-map NotThere
R1(config)# router bgp 100
R1(config-router)# no neighbor 13.1.1.3 advertise-map Advertise non-exist-map NotThere
R1# clear ip bgp *
!On R2:
R2(config)# interface loopback 0
R2(config-if)# no shutdown
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 13.1.1.3 0 0 300 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 12.1.1.1 0 100 300 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 2.0.0.0 13.1.1.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Task 9
R1 should be configured based on the following policy:
1. If both networks (1.0.0.0/8 and 2.0.0.0/8) are up, then both networks should be advertised to R3.
2. If network 1.0.0.0/8 is down, R1 should not advertise network 2.0.0.0/8 to R3.
3. If network 2.0.0.0/8 is down, R1 should only advertise network 1.0.0.0/8 to R3.
The logic in the following configuration says, “Only advertise network 2.0.0.0/8 if network 1.0.0.0/8 is up, so if network 1.0.0.0/8 is not up, do not advertise network 2.0.0.0/8.”
Step 1. The following two access lists identify the two networks (1.0.0.0/8 and 2.0.0.0/8):
!On R1:
R1(config)# access-list 1 permit 1.0.0.0 0.255.255.255
R1(config)# access-list 2 permit 2.0.0.0 0.255.255.255
Step 2. The following route maps are configured to reference the two access lists from the previous step:
R1(config)# route-map Advertise permit 10
R1(config-route-map)# match ip address 2
R1(config)# route-map Exist permit 10
R1(config-route-map)# match ip address 1
Step 3. With the following configuration, we are instructing BGP for the conditions of the task’s requirements:
R1(config)# router bgp 100
R1(config-router)# neighbor 13.1.1.3 advertise-map Advertise exist-map Exist
To test the first condition, if both networks (1.0.0.0/8 and 2.0.0.0/8) are up, then both networks should be advertised to R3.
Note Both prefixes are up:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 13.1.1.3 0 0 300 i
Let’s see the prefixes that R1 is advertising to R3:
!On R1:
R1# show ip bgp neighbor 13.1.1.3 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
As you can see, both prefixes are being advertised to R3. Let’s look at the status of the advertise-map:
R1# show ip bgp neighbor 13.1.1.3 | include map
Condition-map Exist, Advertise-map Advertise, status: Advertise
Let’s check R3’s BGP table:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 2.0.0.0 13.1.1.1 0 100 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
To test the second condition, if network 1.0.0.0/8 is down, R1 should not advertise network 2.0.0.0/8 to R3.
Let’s shut down R1’s Lo0 interface:
!On R1:
R1(config)# interface loopback 0
R1(config-if)# shutdown
Now let’s force the change much faster:
!On R1:
R1# clear ip bgp *
Now we need to look at the prefixes that R1 is advertising to R3. You may have to wait for the changes to be implemented.
R1# show ip bgp neighbor 13.1.1.3 advertised-routes | begin Network
R1# show ip bgp 2.0.0.0
BGP routing table entry for 2.0.0.0/8, version 4
Paths: (1 available, best # 1, table default)
Not advertised to any peer
200
12.1.1.2 from 12.1.1.2 (10.1.2.2)
Origin IGP, metric 0, localpref 100, valid, external, best
Note The output of the preceding show command reveals that R1 is not advertising any prefixes to R3.
Let’s look at the status of the advertise-map:
R1# show ip bgp neighbor 13.1.1.3 | include map
Condition-map Exist, Advertise-map Advertise, status: Withdraw
Now let’s check R3’s BGP table to verify:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 0.0.0.0 0 32768 i
Now we need to test the third condition. If network 2.0.0.0/8 is down, R1 should only advertise network 1.0.0.0/8 to R3.
Let’s apply no shutdown to R1’s Lo0 and shutdown R2’s Lo0:
!On R1:
R1(config)# interface loopback 0
R1(config-if)# no shutdown
!On R2:
R2(config)# interface loopback 0
R2(config-if)# shutdown
Now let’s force the change much faster:
!On R1:
R1# clear ip bgp *
Let’s see which prefixes are advertised to R3 by R1. You may have to wait a little for the changes to be implemented:
R1# show ip bgp neighbor 13.1.1.3 advertised-routes | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
R1# show ip bgp neighbor 13.1.1.3 | include map
Condition-map Exist, Advertise-map Advertise, status: Advertise
Let’s verify the configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 13.1.1.1 0 0 100 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-4: Community Attribute
Figure 10-4 Community Attribute Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-4.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure BGP peering based on the topology shown in Figure 10-4. These routers should advertise their loopback0 interfaces in BGP. Ensure reachability between the loopback interfaces. Do not configure an IGP or default routes to accomplish this task.
The task states, “Ensure reachability between the loopback interfaces without configuring an IGP or default routes.” This is another way of asking you to establish BGP peering using the links that interconnect the routers. If the peering is configured based on the loopback0 interfaces, the peering will not come up because you need to have NLRI to those loopback0 IP addresses.
!On R1:
R1(config)# router bgp 100
R1(config-router)# network 1.0.0.0
R1(config-router)# no auto-summary
R1(config-router)# neighbor 12.1.1.2 remote-as 230
!On R2:
R2(config)# router bgp 230
R2(config-router)# network 2.0.0.0
R2(config-router)# no auto-summary
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 230
R2(config-router)# neighbor 23.1.1.3 next-hop-self
R2(config-router)# neighbor 24.1.1.4 remote-as 400
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 230
R3(config-router)# network 3.0.0.0
R3(config-router)# no auto-summary
R3(config-router)# neighbor 23.1.1.2 remote-as 230
R3(config-router)# neighbor 23.1.1.2 next-hop-self
R3(config-router)# neighbor 35.1.1.5 remote-as 500
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
!On R4:
R4(config)# router bgp 400
R4(config-router)# network 4.0.0.0
R4(config-router)# no auto-summary
R4(config-router)# neighbor 24.1.1.2 remote-as 230
And you should see this console message:
%BGP-5-ADJCHANGE: neighbor 24.1.1.2 Up
!On R5:
R5(config)# router bgp 500
R5(config-router)# network 5.0.0.0
R5(config-router)# no auto-summary
R5(config-router)# neighbor 35.1.1.3 remote-as 230
And this console message:
%BGP-5-ADJCHANGE: neighbor 35.1.1.3 Up
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 230 i
*> 3.0.0.0 12.1.1.2 0 230 i
*> 4.0.0.0 12.1.1.2 0 230 400 i
*> 5.0.0.0 12.1.1.2 0 230 500 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*>i3.0.0.0 23.1.1.3 0 100 0 i
*> 4.0.0.0 24.1.1.4 0 0 400 i
*>i5.0.0.0 23.1.1.3 0 100 0 500 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 23.1.1.2 0 100 0 100 i
*>i2.0.0.0 23.1.1.2 0 100 0 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*>i4.0.0.0 23.1.1.2 0 100 0 400 i
*> 5.0.0.0 35.1.1.5 0 0 500 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 24.1.1.2 0 230 100 i
*> 2.0.0.0 24.1.1.2 0 0 230 i
*> 3.0.0.0 24.1.1.2 0 230 i
*> 4.0.0.0 0.0.0.0 0 32768 i
*> 5.0.0.0 24.1.1.2 0 230 500 i
!On R5:
R5# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 35.1.1.3 0 230 100 i
*> 2.0.0.0 35.1.1.3 0 230 i
*> 3.0.0.0 35.1.1.3 0 0 230 i
*> 4.0.0.0 35.1.1.3 0 230 400 i
*> 5.0.0.0 0.0.0.0 0 32768 i
Now let’s test the configuration:
!On R1:
R1# ping 2.2.2.2 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms
R1# ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
R1# ping 4.4.4.4 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
R1# ping 5.5.5.5 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
!On R3:
R3# ping 4.4.4.4 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
!On R2:
R2# ping 5.5.5.5 source 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms
Task 2
Using the community attribute, configure R1 such that when it advertises network 1.0.0.0/8 to R2 in AS 230, the network is not advertised to any of R2’s iBGP or eBGP neighbors.
The community attribute is a numerical value that can be attached to a given prefix and advertised to a specific neighbor. Once the neighbor receives the prefix, it will examine the community value and will perform either filtering or use that value for the route-selection process.
By default, the community attribute is not sent to any neighbor. To specify that a community attribute should be sent to a BGP neighbor, the neighbor send-community command must be configured in the router config mode.
Here are the well-known communities:
local-as: If local-as is assigned to a network, that network should only be advertised within that AS.
no-advertise: If no-advertise is assigned to a network, that network should not be advertised to any BGP neighbor.
no-export: If no-export is assigned to a network, that network should not be advertised to any eBGP neighbor.
Step 1. An access list or a prefix list is configured to identify the network.
Note Before configuring an access list, always perform a show access-lists command to ensure that one does not exist.
!On R1:
R1# show access-lists
R1(config)# access-list 1 permit 1.0.0.0 0.255.255.255
Step 2. A route map is configured to reference the access list and sets the community to no-advertise. This well-known community attribute tells the receiving router not to advertise that prefix to any of its neighbors (iBGP or eBGP).
The route-map TEST permit 90 clause is the catchall route-map clause. It matches any network not referenced with the match keyword in route-map TST permit 10.
R1(config)# route-map TEST permit 10
R1(config-route-map)# match ip address 1
R1(config-route-map)# set community no-advertise
R1(config-route-map)# route-map TEST permit 90
Step 3. Send the community; this is done with the neighbor send-community command.
Once the community is sent, then the policy through the route map is configured. The direction of the route map specifies which neighbor/router’s decision should be influenced by this policy. If it should affect the neighbor’s decision, the direction of the route map should be “out,” but if the policy should affect the local router, the direction of the route map should be “in.”
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 send-community
R1(config-router)# neighbor 12.1.1.2 route-map TEST out
Let’s verify the configuration:
!On R2:
R2# show ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 18
Paths: (1 available, best # 1, table default, not advertised to any peer)
Not advertised to any peer
100
12.1.1.1 from 12.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-advertise
Because R2 does not advertise the network, R3 and the other eBGP and/or iBGP neighbors will not have any knowledge of this prefix.
!On R3:
R3# show ip bgp 1.0.0.0
% Network not in table
!On R4:
R4# show ip bgp 1.0.0.0
% Network not in table
!On R5:
R5# show ip bgp 1.0.0.0
% Network not in table
Task 3
Configure R5 such that when it advertises its network 5.0.0.0 to R3 in AS 230, the routers in AS 230 do not advertise that network to any of their eBGP peers. Do not configure filtering on R3 to accomplish this task.
Because in the previous task an access list was used, in this task a prefix list is configured to reference the prefix:
!On R5:
R5(config)# ip prefix-list NET5 permit 5.0.0.0/8
A route map is configured to reference the prefix list, and a policy of no-export is applied:
R5(config)# route-map TST permit 10
R5(config-route-map)# match ip address prefix-list NET5
R5(config-route-map)# set community no-export
R5(config-route-map)# route-map TST permit 90
The community and the policy are sent using the route map in the outbound direction:
R5(config)# router bgp 500
R5(config-router)# neighbor 35.1.1.3 send-community
R5(config-router)# neighbor 35.1.1.3 route-map TST out
This is another well-known community attribute. In this case, network 5.0.0.0 will only be advertised to the routers in AS 230. The routers in AS 230 will not advertise this network to any of their eBGP neighbors.
Note By default, routers will strip the community attribute when they send the community in the route map to a given neighbor (iBGP or eBGP). Therefore, in this case, R3 should be configured to send the community to R2; otherwise, R2 will advertise that network to its eBGP peers.
!On R3:
R3(config)# router bgp 230
R3(config-router)# neighbor 23.1.1.2 send-community
Let’s verify the configuration:
!On R3:
R3# show ip bgp 5.0.0.0
BGP routing table entry for 5.0.0.0/8, version 8
Paths: (1 available, best # 1, table default, not advertised to EBGP peer)
Advertised to update-groups:
10
500
35.1.1.5 from 35.1.1.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export
!On R2:
R2# show ip bgp 5.0.0.0
BGP routing table entry for 5.0.0.0/8, version 19
Paths: (1 available, best # 1, table default, not advertised to EBGP peer)
Not advertised to any peer
500
23.1.1.3 from 23.1.1.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
!On R4:
R4# show ip bgp 5.0.0.0
% Network not in table
!On R1:
R1# show ip bgp 5.0.0.0
% Network not in table
Task 4
Configure R3 in AS 230 to advertise network 3.0.0.0/8 to the routers in its own AS only. You must use a network command to accomplish this task.
To configure this task, a route map is configured to assign a local-as community and then the network command references the route map:
!On R3:
R3(config)# route-map TST permit 10
R3(config-route-map)# set community local-as
R3(config)# router bgp 230
R3(config-router)# network 3.0.0.0 route-map TST
R3(config-router)# neighbor 23.1.1.2 send-community
Let’s verify the configuration:
!On R3:
R3# show ip bgp 3.0.0.0
BGP routing table entry for 3.0.0.0/8, version 9
Paths: (1 available, best # 1, table default, not advertised outside local AS)
Advertised to update-groups:
10
Local
0.0.0.0 from 0.0.0.0 (3.3.3.3)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Community: local-AS
!On R5:
R5# show ip bgp 3.0.0.0
% Network not in table
!On R2:
R2# show ip bgp 3.0.0.0
BGP routing table entry for 3.0.0.0/8, version 20
Paths: (1 available, best # 1, table default, not advertised outside local AS)
Not advertised to any peer
Local
23.1.1.3 from 23.1.1.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: local-AS
!On R1:
R1# show ip bgp 3.0.0.0
% Network not in table
In this topology, no-export and local-as have the same behavior. The no-export community does not look at the BGP Confederation identifier command; therefore, it will keep the prefix(es) local in the AS number that the BGP router is configured in. On the other hand, the local-as community looks at the BGP Confederation identifier command first; if it’s configured, it will keep the prefix(es) within that AS, but if the BGP Confederation identifier is not configured, it will keep the prefix(es) local to the AS that the BGP is configured in.
Task 5
R1 is advertising network 1.0.0.0, which has an attached community attribute of no-advertise to R2 (see Task 2). R2 should be configured to advertise network 1.0.0.0 to all of its iBGP and eBGP peers. You should utilize a community attribute to accomplish this task.
Before configuring R2, we should display the prefix in the BGP table:
!On R2:
R2# show ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 18
Paths: (1 available, best # 1, table default, not advertised to any peer)
Not advertised to any peer
100
12.1.1.1 from 12.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-advertise
The output of the preceding show command reveals that network 1.0.0.0/8 is not going to be advertised to any of its peers, but you can configure R2 to override the set community by assigning the internet community to this network. With the internet community assigned, network 1.0.0.0/8 will be advertised to all peers.
!On R2:
R2# show access-lists
R2(config)# access-list 1 permit 1.0.0.0
R2(config)# route-map TST permit 10
R2(config-route-map)# match ip address 1
R2(config-route-map)# set community internet
R2(config)# router bgp 230
R2(config-router)# neighbor 12.1.1.1 route-map TST in
Let’s verify the configuration:
!On R2:
R2# clear ip bgp * in
R2# show ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 21
Paths: (1 available, best # 1, table default)
Advertised to update-groups:
6 7
100
12.1.1.1 from 12.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: internet
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 24.1.1.2 0 230 100 i
*> 2.0.0.0 24.1.1.2 0 0 230 i
*> 4.0.0.0 0.0.0.0 0 32768 i
!On R5:
R5# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 35.1.1.3 0 230 100 i
*> 2.0.0.0 35.1.1.3 0 230 i
*> 4.0.0.0 35.1.1.3 0 230 400 i
*> 5.0.0.0 0.0.0.0 0 32768 i
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-5: The AS-path Attribute
This lab demonstrates how to use AS-path manipulation to affect how an external AS will route traffic to networks into an internal AS. By prepending the autonomous system value of a prefix as it is advertised to an external AS, we can affect how traffic will enter the local AS. The shortest AS-path will be selected, and that path will be the path used by an external AS to reach a given prefix. This will be demonstrated in our lab topology when we apply an outbound policy, making the current path be selected by BGP via the topology illustrated in Figure 10-5.
Figure 10-5 AS-path Attribute Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-5.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure R2, R3, and R4 in AS 200; these routers should have a full-mesh peer session between them. R2 and R4 should have an eBGP peer session with R1 in AS 100. These routers should only advertise their loopback interfaces in BGP. Provide NLRI for the links using OSPF.
!On R1:
R1(config)# router bgp 100
R1(config-router)# no auto-summary
R1(config-router)# network 1.0.0.0
R1(config-router)# network 11.0.0.0
R1(config-router)# neighbor 12.1.1.2 remote-as 200
R1(config-router)# neighbor 14.1.1.4 remote-as 200
!On R2:
R2(config)# router bgp 200
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 200
R2(config-router)# neighbor 23.1.1.3 next-hop-self
R2(config-router)# neighbor 34.1.1.4 next-hop-self
R2(config-router)# neighbor 34.1.1.4 remote-as 200
R2(config)# router ospf 1
R2(config-router)# network 23.1.1.2 0.0.0.0 area 0
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 200
R3(config-router)# no auto-summary
R3(config-router)# network 3.0.0.0
R3(config-router)# neighbor 34.1.1.4 remote-as 200
R3(config-router)# neighbor 23.1.1.2 remote-as 200
R3(config)# router ospf 1
R3(config-router)# network 23.1.1.3 0.0.0.0 area 0
R3(config-router)# network 34.1.1.3 0.0.0.0 area 0
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/2 from LOADING to FULL, Loading Done
!On R4:
R4(config)# router bgp 200
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# neighbor 34.1.1.3 remote-as 200
R4(config-router)# neighbor 34.1.1.3 next-hop-self
R4(config-router)# neighbor 23.1.1.2 remote-as 200
R4(config-router)# neighbor 23.1.1.2 next-hop-self
R4(config-router)# neighbor 14.1.1.1 remote-as 100
R4(config)# router ospf 1
R4(config-router)# network 34.1.1.4 0.0.0.0 area 0
You should see this console message as well:
%BGP-5-ADJCHANGE: neighbor 34.1.1.3 Up
%BGP-5-ADJCHANGE: neighbor 14.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/3 from LOADING to FULL, Loading Done
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 i
* 14.1.1.4 0 200 i
*> 4.0.0.0 12.1.1.2 0 200 i
* 14.1.1.4 0 0 200 i
*> 11.0.0.0 0.0.0.0 0 32768 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0 34.1.1.4 0 100 0 100 i
*> 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*>i3.0.0.0 23.1.1.3 0 100 0 i
*>i4.0.0.0 34.1.1.4 0 100 0 i
* i11.0.0.0 34.1.1.4 0 100 0 100 i
*> 12.1.1.1 0 0 100 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 23.1.1.2 0 100 0 100 i
* i 34.1.1.4 0 100 0 100 i
*>i2.0.0.0 23.1.1.2 0 100 0 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*>i4.0.0.0 34.1.1.4 0 100 0 i
*>i11.0.0.0 23.1.1.2 0 100 0 100 i
* i 34.1.1.4 0 100 0 100 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0 23.1.1.2 0 100 0 100 i
*> 14.1.1.1 0 0 100 i
*>i2.0.0.0 23.1.1.2 0 100 0 i
*>i3.0.0.0 34.1.1.3 0 100 0 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* i11.0.0.0 23.1.1.2 0 100 0 100 i
*> 14.1.1.1 0 0 100 i
Task 2
Configure R1 in AS 100 such that routers in AS 200 use the link through R4–R1 to reach its network 1.0.0.0/8. Use the AS-path attribute to accomplish this task.
The AS-path attribute can be manipulated to accomplish this task. This attribute can be manipulated by prepending the AS number to existing AS paths one or more times. Typically, you perform an AS-path prepending on the outgoing eBGP updates over the undesired return path, making the AS-path over the undesired link become longer than the desired path, and as a result making the desired path the primary one.
!On R1:
R1# show access-lists
R1(config)# access-list 1 permit 1.0.0.0 0.255.255.255
R1(config)# route-map TST1 permit 10
R1(config-route-map)# match ip address 1
R1(config-route-map)# set as-path prepend 100
R1(config)# route-map TST1 permit 90
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 route-map TST1 out
Let’s enforce the policy:
R1# clear ip bgp * out
Let’s verify the configuration:
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 34.1.1.4 0 100 0 100 i
* 12.1.1.1 0 0 100 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*>i3.0.0.0 23.1.1.3 0 100 0 i
*>i4.0.0.0 34.1.1.4 0 100 0 i
* i11.0.0.0 34.1.1.4 0 100 0 100 i
*> 12.1.1.1 0 0 100 i
The following configuration injects a default route into AS 100; this is done for return traffic:
!On R2:
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 default-originate
R2# clear ip bgp * out
!On R4:
R4(config)# router bgp 200
R4(config-router)# neighbor 14.1.1.1 default-originate
R4# clear ip bgp * out
!On R2:
R2# traceroute 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 23.1.1.3 12 msec 12 msec 16 msec
2 34.1.1.4 28 msec 32 msec 28 msec
3 14.1.1.1 20 msec * 20 msec
!On R3:
R3# traceroute 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 34.1.1.4 16 msec 16 msec 12 msec
2 14.1.1.1 20 msec * 24 msec
!On R4:
R4# traceroute 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 14.1.1.1 0 msec * 0 msec
Note The AS-path attribute is used to influence the degree of preference in another AS. R2, R3, and R4 will go through R4 to reach network 1.0.0.0/8 because by going through R4, they traverse through fewer AS hops.
Task 3
Configure R1 in AS 100 such that the routers in AS 200 use the link through R2–R1 to reach network 11.0.0.0/8. Use the AS-path attribute and an IP Prefix-list to accomplish this task.
Even though a prefix list is used instead of an access list, the process and the steps are identical.
!On R1:
R1(config)# ip prefix-list NET11 permit 11.0.0.0/8
R1(config)# route-map TST11 permit 10
R1(config-route-map)# match ip address prefix-list NET11
R1(config-route-map)# set as-path prepend 100 100
R1(config)# route-map TST11 permit 90
R1(config-route-map)# router bgp 100
R1(config-router)# neighbor 14.1.1.4 route-map TST11 out
R1# clear ip bgp * out
Let’s verify the configuration:
!On R2:
R2# traceroute 11.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 11.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.1 16 msec * 12 msec
!On R3:
R3# traceroute 11.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 11.1.1.1
1 23.1.1.2 12 msec 12 msec 16 msec
2 12.1.1.1 28 msec * 28 msec
!On R4:
R4# traceroute 11.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 11.1.1.1
1 34.1.1.3 12 msec 12 msec 16 msec
2 23.1.1.2 28 msec 28 msec 32 msec
3 12.1.1.1 40 msec * 40 msec
Erase the startup configuration and reload the routers before proceeding to the next lab.
Lab 10-6: The Weight Attribute
There are two options to manipulate the Cisco proprietary weight attribute. It can be done on either a per-neighbor basis or on specific-prefix basis. Manipulating the weight attribute is only going to affect the best-path-selection process on an individual router; this alteration will not affect the other BGP speakers in the same AS. We will explore these mechanisms via the topology illustrated in Figure 10-6.
Figure 10-6 The weight Attribute Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-6.txt file and subsequently applying those configurations on a device-by- device basis.
Task 1
Configure R1 in AS 100 to establish an eBGP peer session with R2 in AS 200 and R4 in AS 400.
Router R2 should establish eBGP peer sessions with R1 in AS 100 and R3 in AS 300.
Router R3 should establish eBGP peer sessions with R2 in AS 200 and R4 in AS 400.
Router R4 should establish eBGP peer sessions with R1 in AS 100 and R3 in AS 300.
The BGP routers should only advertise their loopback(s) in BGP.
Do not use the loopback interfaces to establish BGP peer sessions.
!On R1:
R1(config-if)# router bgp 100
R1(config-router)# no auto-summary
R1(config-router)# network 1.0.0.0
R1(config-router)# network 11.0.0.0
R1(config-router)# neighbor 14.1.1.4 remote-as 400
R1(config-router)# neighbor 12.1.1.2 remote-as 200
!On R2:
R2(config)# router bgp 200
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 300
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 300
R3(config-router)# no auto-summary
R3(config-router)# network 3.0.0.0
R3(config-router)# neighbor 34.1.1.4 remote-as 400
R3(config-router)# neighbor 23.1.1.2 remote-as 200
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
!On R4:
R4(config)# router bgp 400
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# neighbor 34.1.1.3 remote-as 300
R4(config-router)# neighbor 14.1.1.1 remote-as 100
You should see this console message as well:
%BGP-5-ADJCHANGE: neighbor 14.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 34.1.1.3 Up
Let’s verify the configuration:
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 2.0.0.0 34.1.1.3 0 300 200 i
*> 14.1.1.1 0 100 200 i
* 3.0.0.0 14.1.1.1 0 100 200 300 i
*> 34.1.1.3 0 0 300 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* 11.0.0.0 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
* 3.0.0.0 14.1.1.4 0 400 300 i
*> 12.1.1.2 0 200 300 i
*> 4.0.0.0 14.1.1.4 0 0 400 i
*> 11.0.0.0 0.0.0.0 0 32768 i
Task 2
Configure R1 in AS 100 to use AS 200 to reach all the prefixes within this topology. You must use the weight attribute to accomplish this task.
The weight attribute is a Cisco-defined attribute that is local to the router. This attribute is not advertised to any BGP neighbors. If there is more than one route for a given destination, the weight attribute can decide which path is the best path. The higher the value, the better the preference.
The following assigns a weight attribute of 40000 to all existing and future prefixes:
!On R1:
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 weight 40000
R1# clear ip bgp *
Let’s verify and test the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 400 300 200 i
*> 12.1.1.2 0 40000 200 i
* 3.0.0.0 14.1.1.4 0 400 300 i
*> 12.1.1.2 40000 200 300 i
* 4.0.0.0 14.1.1.4 0 0 400 i
*> 12.1.1.2 40000 200 300 400 i
*> 11.0.0.0 0.0.0.0 0 32768 i
You can see that R1 has to traverse through R2 to reach all the prefixes within this topology. To test this configuration, RIPv2 is configured on all routers to advertise the links that interconnect the routers. This is done for return traffic for pings and traceroutes.
R1(config)# router rip
R1(config-router)# no auto-summary
R1(config-router)# version 2
R1(config-router)# network 12.0.0.0
R1(config-router)# network 14.0.0.0
!On R2:
R2(config)# router rip
R2(config-router)# no auto-summary
R2(config-router)# version 2
R2(config-router)# network 12.0.0.0
R2(config-router)# network 23.0.0.0
!On R3:
R3(config)# router rip
R3(config-router)# no auto-summary
R3(config-router)# version 2
R3(config-router)# network 23.0.0.0
R3(config-router)# network 34.0.0.0
!On R4:
R4(config)# router rip
R4(config-router)# no auto-summary
R4(config-router)# version 2
R4(config-router)# network 34.0.0.0
R4(config-router)# network 14.0.0.0
Let’s verify the configuration:
!On R1:
R1# show ip route rip | begin Gate
Gateway of last resort is not set
23.0.0.0/24 is subnetted, 1 subnets
R 23.1.1.0 [120/1] via 12.1.1.2, 00:00:23, Serial1/2
34.0.0.0/24 is subnetted, 1 subnets
R 34.1.1.0 [120/1] via 14.1.1.4, 00:00:08, FastEthernet0/0
R1# traceroute 4.4.4.4 numeric
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 52 msec 16 msec 16 msec
2 23.1.1.3 28 msec 28 msec 32 msec
3 34.1.1.4 16 msec * 16 msec
R1# traceroute 3.3.3.3 numeric
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 16 msec 12 msec 16 msec
2 23.1.1.3 32 msec * 28 msec
R1# traceroute 2.2.2.2 numeric
Type escape sequence to abort.
Tracing the route to 2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 16 msec * 12 msec
Task 3
Configure the following loopback interface on R3 and advertise it in BGP:
loopback1: 33.3.3.3/24
!On R3:
R3(config)# interface loopback 1
R3(config-if)# ip address 33.3.3.3 255.255.255.0
R3(config)# router bgp 300
R3(config-router)# network 33.3.3.0 mask 255.255.255.0
Note The preceding network statement has to include the mask option because auto-summary is disabled. When auto-summary is disabled, the network must be advertised using the exact mask, but if auto-summary is enabled, all subsets of a given major network can be advertised by simply advertising the major network.
Let’s verify the configuration:
!On R3:
R3# show ip bgp 33.3.3.0/24
BGP routing table entry for 33.3.3.0/24, version 11
Paths: (1 available, best # 1, table default)
Advertised to update-groups:
2
Local
0.0.0.0 from 0.0.0.0 (3.3.3.3)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 400 300 200 i
*> 12.1.1.2 0 40000 200 i
* 3.0.0.0 14.1.1.4 0 400 300 i
*> 12.1.1.2 40000 200 300 i
* 4.0.0.0 14.1.1.4 0 0 400 i
*> 12.1.1.2 40000 200 300 400 i
*> 11.0.0.0 0.0.0.0 0 32768 i
*> 33.3.3.0/24 12.1.1.2 40000 200 300 i
* 14.1.1.4 0 400 300 i
Note The weight attribute configured in Task 3 affected the existing and the future prefixes within the topology.
Let’s verify this information:
R1# traceroute 33.3.3.3 numeric
Type escape sequence to abort.
Tracing the route to 33.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 12 msec 16 msec 16 msec
2 23.1.1.3 28 msec * 28 msec
Task 4
Reconfigure R1 based on the following policy; this policy may override the previously implemented policy:
R1 in AS 100 should use R4 in AS 400 to reach network 33.0.0.0/8 and network 4.0.0.0/8.
R1 in AS 100 should use R2 in AS 200 to reach network 3.0.0.0/8, as well as existing and future prefixes advertised in AS 200.
Let’s remove the weight configuration that was implemented in Task 3:
!On R1:
R1(config)# router bgp 100
R1(config-router)# no neighbor 12.1.1.2 weight 40000
R1# clear ip bgp *
To configure this task, we configure two access lists: the first access list identifies networks 4.0.0.0/8 and 33.3.3.0/24, and the second one identifies network 3.0.0.0/8.
But how do we identify the existing and future prefixes advertised in AS 200? The easiest way to accomplish this is to configure an AS-path access list identifying the AS number, because the AS number remains the same for existing and future routes in AS 200.
The following access list identifies networks 33.3.3.0/24 and 4.0.0.0/8:
R1# show access-list
R1(config)# access-list 1 permit 33.3.3.0 0.0.0.255
R1(config)# access-list 1 permit 4.0.0.0 0.255.255.255
The following access list identifies networks 3.0.0.0/8:
R1(config)# access-list 2 permit 3.0.0.0 0.255.255.255
With access lists or prefix lists, IP addresses are identified. Using ip as-path access-list, we can identify the AS (in this case, AS 200):
R1(config)# ip as-path access-list 1 permit ^200$
Once the prefixes are all identified, they are referenced in a route map and the weight attribute is assigned to them based on the requirements of this task.
The following route map (TST) assigns a weight attribute of 45000 to the networks identified in access-list 1:
R1(config)# route-map TST permit 10
R1(config-route-map)# match ip address 1
R1(config-route-map)# set weight 45000
R1(config)# route-map TST permit 90
The following route map (TEST) assigns a weight attribute of 50000 to the networks identified in access-list 2 and AS 200:
R1(config)# route-map TEST permit 10
R1(config-route-map)# match as-path 1
R1(config-route-map)# set weight 50000
R1(config)# route-map TEST permit 20
R1(config-route-map)# match ip address 2
R1(config-route-map)# set weight 50000
R1(config)# route-map TEST permit 90
R1(config)# router bgp 100
R1(config-router)# neighbor 14.1.1.4 route-map TST in
R1(config-router)# neighbor 12.1.1.2 route-map TEST in
The preceding commands assign the attributes to neighbors R2 and R4:
R1# clear ip bgp *
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 400 300 200 i
*> 12.1.1.2 0 50000 200 i
* 3.0.0.0 14.1.1.4 0 400 300 i
*> 12.1.1.2 50000 200 300 i
*> 4.0.0.0 14.1.1.4 0 45000 400 i
* 12.1.1.2 0 200 300 400 i
*> 11.0.0.0 0.0.0.0 0 32768 i
*> 33.3.3.0/24 14.1.1.4 45000 400 300 i
* 12.1.1.2 0 200 300 i
Note Network 3.0.0.0/8 and networks that originated with and are advertised by AS 200 are assigned a weight value of 50000, and networks 4.0.0.0/8 and 33.3.3.0/24 are assigned a weight value of 45000. Therefore, R1 goes through R4 to reach networks 33.3.3.0/24 and 4.0.0.0/8. R1 also goes through R2 for all existing and future prefixes that originated in AS 200 and network 3.0.0.0/8. Let’s verify:
R1# traceroute 4.4.4.4 numeric
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 14.1.1.4 0 msec * 0 msec
R1# traceroute 33.3.3.3 numeric
Type escape sequence to abort.
Tracing the route to 33.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 14.1.1.4 4 msec 0 msec 0 msec
2 34.1.1.3 12 msec * 12 msec
R1# traceroute 2.2.2.2 numeric
Type escape sequence to abort.
Tracing the route to 2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 32 msec * 12 msec
R1# traceroute 3.3.3.3 numeric
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 16 msec 16 msec 16 msec
2 23.1.1.3 28 msec * 28 msec
Do not erase the configuration; instead, proceed to the next lab.
Lab 10-7: Multi-Exit Discriminator Attribute
One other BGP attribute we can use to manipulate how an external AS will enter our local AS is the multiple exit discriminator, which is very useful in this scenario. However, for this to work, the external AS must be configured to accept the MED attribute. Additionally, by default, MED will only work in scenarios where the local AS is multihomed to the same external AS, as illustrated in Figure 10-7.
The initial configuration files used in this lab can be found by downloading the BGP-Lab-7.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure routers R2, R3, and R4 in AS 200; these routers should have a full-mesh peer session between them. R2 and R4 should have an eBGP peer session with R1 in AS 100. BGP routers should only advertise their loopback interface(s) in BGP.
!On R1:
R1(config-if)# router bgp 100
R1(config-router)# no auto-summary
R1(config-router)# network 11.0.0.0
R1(config-router)# network 1.0.0.0
R1(config-router)# neighbor 14.1.1.4 remote-as 200
R1(config-router)# neighbor 12.1.1.2 remote-as 200
!On R2:
R2(config)# router bgp 200
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# network 22.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 200
R2(config-router)# neighbor 23.1.1.3 next-hop-self
R2(config-router)# neighbor 34.1.1.4 remote-as 200
R2(config-router)# neighbor 34.1.1.4 next-hop-self
You should see the following console messages:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 200
R3(config-router)# no auto-summary
R3(config-router)# network 3.0.0.0
R3(config-router)# network 33.0.0.0
R3(config-router)# neighbor 34.1.1.4 remote-as 200
R3(config-router)# neighbor 23.1.1.2 remote-as 200
You should also see these console messages:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
!On R4:
R4(config)# router bgp 200
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# neighbor 34.1.1.3 remote-as 200
R4(config-router)# neighbor 34.1.1.3 next-hop-self
R4(config-router)# neighbor 23.1.1.2 remote-as 200
R4(config-router)# neighbor 23.1.1.2 next-hop-self
R4(config-router)# neighbor 14.1.1.1 remote-as 100
You should see these console messages as well:
%BGP-5-ADJCHANGE: neighbor 14.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 34.1.1.3 Up
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
* 3.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 200 i
* 4.0.0.0 12.1.1.2 0 200 i
*> 14.1.1.4 0 0 200 i
*> 11.0.0.0 0.0.0.0 0 32768 i
* 22.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
* 33.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 200 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0 34.1.1.4 0 100 0 100 i
*> 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*>i3.0.0.0 23.1.1.3 0 100 0 i
*>i4.0.0.0 34.1.1.4 0 100 0 i
* i11.0.0.0 34.1.1.4 0 100 0 100 i
*> 12.1.1.1 0 0 100 i
*> 22.0.0.0 0.0.0.0 0 32768 i
*>i33.0.0.0 23.1.1.3 0 100 0 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0 34.1.1.4 0 100 0 100 i
* i 23.1.1.2 0 100 0 100 i
*>i2.0.0.0 23.1.1.2 0 100 0 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*>i4.0.0.0 34.1.1.4 0 100 0 i
*>i11.0.0.0 34.1.1.4 0 100 0 100 i
* i 23.1.1.2 0 100 0 100 i
*>i22.0.0.0 23.1.1.2 0 100 0 i
*> 33.0.0.0 0.0.0.0 0 32768 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0 23.1.1.2 0 100 0 100 i
*> 14.1.1.1 0 0 100 i
*>i2.0.0.0 23.1.1.2 0 100 0 i
*>i3.0.0.0 34.1.1.3 0 100 0 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* i11.0.0.0 23.1.1.2 0 100 0 100 i
*> 14.1.1.1 0 0 100 i
*>i22.0.0.0 23.1.1.2 0 100 0 i
*>i33.0.0.0 34.1.1.3 0 100 0 i
Task 2
Configure AS 200 such that R1 in AS 100 takes R4 to reach any prefix advertised in AS 200. You should manipulate MED to accomplish this task.
MED is used as a suggestion to an external AS regarding the preferred path into the AS that is advertising the metric. This suggestion is used here because the AS receiving the MED attribute could use another attribute such as weight that overrides the MED attribute. As far as MED is concerned, the lower value has better preference.
!On R2:
R2(config)# route-map TST permit 10
R2(config-route-map)# set metric 100
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 route-map TST out
R2# clear ip bgp * out
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 14.1.1.4 0 200 i
* 12.1.1.2 100 0 200 i
*> 3.0.0.0 14.1.1.4 0 200 i
* 12.1.1.2 100 0 200 i
* 4.0.0.0 12.1.1.2 100 0 200 i
*> 14.1.1.4 0 0 200 i
*> 11.0.0.0 0.0.0.0 0 32768 i
*> 22.0.0.0 14.1.1.4 0 200 i
* 12.1.1.2 100 0 200 i
*> 33.0.0.0 14.1.1.4 0 200 i
* 12.1.1.2 100 0 200 i
R1# traceroute 2.2.2.2 source 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 14.1.1.4 0 msec 4 msec 0 msec
2 34.1.1.3 16 msec 16 msec 16 msec
3 23.1.1.2 20 msec * 20 msec
Note R1 receives a MED value of 100 for all prefixes from R2 because R1 does not receive a MED value from R4. R1 considers the MED value coming from R4 to be zero. When R1 compares the two MED values coming from the same AS, it takes the path with a lower MED value, which is R4.
Task 3
Remove the configuration command from the previous task before proceeding to the next task:
!On R2:
R2(config)# no route-map TST
R2(config)# router bgp 200
R2(config-router)# no neighbor 12.1.1.1 route-map TST out
R2# clear ip bgp *
Task 4
Configure the appropriate router(s) in AS 200 such that AS 100 goes through R4 to reach network 33.0.0.0/8 and R2 to reach network 3.0.0.0/8. You should utilize MED to accomplish this task.
The following output shows the existing BGP table of R1 before the MED attribute is manipulated:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
* 3.0.0.0 12.1.1.2 0 200 i
*> 14.1.1.4 0 200 i
* 4.0.0.0 12.1.1.2 0 200 i
*> 14.1.1.4 0 0 200 i
*> 11.0.0.0 0.0.0.0 0 32768 i
* 22.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
* 33.0.0.0 12.1.1.2 0 200 i
*> 14.1.1.4 0 200 i
Note R1 goes through R4 to reach both networks.
On R2, configure the following two prefix lists (NET3 and NET33), which reference prefixes 3.0.0.0/8 and 33.0.0.0/8, respectively:
Note It is very easy to remember that prefix list NET3 is referencing network 3.0.0.0/8 and prefix list NET33 is referencing network 33.0.0.0/8. If possible, though, you should choose a meaningful name.
R2# show ip prefix-list
R2(config)# ip prefix-list NET3 permit 3.0.0.0/8
R2(config)# ip prefix-list NET33 permit 33.0.0.0/8
The following configuration sets the metric, which is the MED value, to 50 for network 3.0.0.0/8 and to 100 for network 33.0.0.0/8. On R4, the MED values are reversed, meaning that the MED value for network 3.0.0.0/8 is set to 100 and for network 33.0.0.0/8 it is set to 50.
R2(config)# route-map TST permit 10
R2(config-route-map)# match ip address prefix-list NET3
R2(config-route-map)# set metric 50
R2(config)# route-map TST permit 20
R2(config-route-map)# match ip address prefix-list NET33
R2(config-route-map)# set metric 100
R2(config)# route-map TST permit 90
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 route-map TST out
R2# clear ip bgp *
!On R4:
R4# sh ip prefix-list
R4(config)# ip prefix-list NET3 permit 3.0.0.0/8
R4(config)# ip prefix-list NET33 permit 33.0.0.0/8
R4(config)# route-map TST permit 10
R4(config-route-map)# match ip address prefix-list NET3
R4(config-route-map)# set metric 100
R4(config)# route-map TST permit 20
R4(config-route-map)# match ip address prefix-list NET33
R4(config-route-map)# set metric 50
R4(config)# route-map TST permit 90
R4(config)# router bgp 200
R4(config-router)# neighbor 14.1.1.1 route-map TST out
R4# clear ip bgp *
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
* 2.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
* 3.0.0.0 14.1.1.4 100 0 200 i
*> 12.1.1.2 50 0 200 i
* 4.0.0.0 12.1.1.2 0 200 i
*> 14.1.1.4 0 0 200 i
*> 11.0.0.0 0.0.0.0 0 32768 i
* 22.0.0.0 14.1.1.4 0 200 i
*> 12.1.1.2 0 0 200 i
*> 33.0.0.0 14.1.1.4 50 0 200 i
* 12.1.1.2 100 0 200 i
Note Network 3.0.0.0/8 is reachable via R2, and network 33.0.0.0/8 is reachable via R4.
Let’s test the configuration:
!On R1:
R1# traceroute 3.3.3.3 source 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 12.1.1.2 16 msec 16 msec 12 msec
2 23.1.1.3 24 msec * 20 msec
R1# traceroute 33.3.3.3 source 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 33.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 14.1.1.4 4 msec 0 msec 0 msec
2 34.1.1.3 12 msec * 12 msec
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-8: Filtering Using Access Lists and Prefix Lists
Figure 10-8 BGP Filtering Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-8.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure the BGP peering based on Figure 10-8:
!On R1:
R1(config)# router bgp 100
R1(config-router)# no auto-summary
R1(config-router)# network 1.1.0.0 mask 255.255.255.0
R1(config-router)# network 1.1.1.0 mask 255.255.255.0
R1(config-router)# network 1.1.2.0 mask 255.255.255.0
R1(config-router)# network 1.1.3.0 mask 255.255.255.0
R1(config-router)# network 1.1.4.0 mask 255.255.255.0
R1(config-router)# neighbor 12.1.1.2 remote-as 200
R1(config-router)# neighbor 14.1.1.4 remote-as 400
!On R2:
R2(config)# router bgp 200
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# network 22.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 300
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 300
R3(config-router)# no auto-summary
R3(config-router)# network 3.0.0.0
R3(config-router)# network 33.0.0.0
R3(config-router)# neighbor 23.1.1.2 remote-as 200
R3(config-router)# neighbor 34.1.1.4 remote-as 400
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
!On R4:
R4(config)# router bgp 400
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# neighbor 14.1.1.1 remote-as 100
R4(config-router)# neighbor 34.1.1.3 remote-as 300
You should see the following console message as well:
%BGP-5-ADJCHANGE: neighbor 14.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 34.1.1.3 Up
Let’s verify the configuration:
Note If you don't see all the entries in the BGP table, run clear ip bgp *.
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.0.0/24 0.0.0.0 0 32768 i
*> 1.1.1.0/24 0.0.0.0 0 32768 i
*> 1.1.2.0/24 0.0.0.0 0 32768 i
*> 1.1.3.0/24 0.0.0.0 0 32768 i
*> 1.1.4.0/24 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
* 14.1.1.4 0 400 300 200 i
* 3.0.0.0 12.1.1.2 0 200 300 i
*> 14.1.1.4 0 400 300 i
* 4.0.0.0 12.1.1.2 0 200 300 400 i
*> 14.1.1.4 0 0 400 i
*> 22.0.0.0 12.1.1.2 0 0 200 i
* 14.1.1.4 0 400 300 200 i
* 33.0.0.0 12.1.1.2 0 200 300 i
*> 14.1.1.4 0 400 300 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.1.0.0/24 23.1.1.3 0 300 400 100 i
*> 12.1.1.1 0 0 100 i
* 1.1.1.0/24 23.1.1.3 0 300 400 100 i
*> 12.1.1.1 0 0 100 i
* 1.1.2.0/24 23.1.1.3 0 300 400 100 i
*> 12.1.1.1 0 0 100 i
* 1.1.3.0/24 23.1.1.3 0 300 400 100 i
*> 12.1.1.1 0 0 100 i
* 1.1.4.0/24 23.1.1.3 0 300 400 100 i
*> 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 23.1.1.3 0 0 300 i
* 12.1.1.1 0 100 400 300 i
* 4.0.0.0 23.1.1.3 0 300 400 i
*> 12.1.1.1 0 100 400 i
*> 22.0.0.0 0.0.0.0 0 32768 i
*> 33.0.0.0 23.1.1.3 0 0 300 i
* 12.1.1.1 0 100 400 300 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.1.0.0/24 34.1.1.4 0 400 100 i
*> 23.1.1.2 0 200 100 i
* 1.1.1.0/24 34.1.1.4 0 400 100 i
*> 23.1.1.2 0 200 100 i
* 1.1.2.0/24 34.1.1.4 0 400 100 i
*> 23.1.1.2 0 200 100 i
* 1.1.3.0/24 34.1.1.4 0 400 100 i
*> 23.1.1.2 0 200 100 i
* 1.1.4.0/24 23.1.1.2 0 200 100 i
*> 34.1.1.4 0 400 100 i
* 2.0.0.0 34.1.1.4 0 400 100 200 i
*> 23.1.1.2 0 0 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
* 23.1.1.2 0 200 100 400 i
* 22.0.0.0 34.1.1.4 0 400 100 200 i
*> 23.1.1.2 0 0 200 i
*> 33.0.0.0 0.0.0.0 0 32768 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.1.0.0/24 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 1.1.1.0/24 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 1.1.2.0/24 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 1.1.3.0/24 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 1.1.4.0/24 34.1.1.3 0 300 200 100 i
*> 14.1.1.1 0 0 100 i
* 2.0.0.0 34.1.1.3 0 300 200 i
*> 14.1.1.1 0 100 200 i
*> 3.0.0.0 34.1.1.3 0 0 300 i
* 14.1.1.1 0 100 200 300 i
*> 4.0.0.0 0.0.0.0 0 32768 i
* 22.0.0.0 34.1.1.3 0 300 200 i
*> 14.1.1.1 0 100 200 i
*> 33.0.0.0 34.1.1.3 0 0 300 i
* 14.1.1.1 0 100 200 300 i
Task 2
Configure R2 to filter network 1.1.4.0/24. Use distribute-list and access-list to accomplish this task.
Let’s see the existing entry for this network:
!On R2:
R2# show ip bgp 1.1.4.0/24
BGP routing table entry for 1.1.4.0/24, version 57
Paths: (2 available, best # 2, table default)
Advertised to update-groups:
2
Refresh Epoch 1
300 400 100
23.1.1.3 from 23.1.1.3 (33.3.3.3)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
100
12.1.1.1 from 12.1.1.1 (1.1.4.1)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
To filter the prefix, an access list is configured to deny the prefix that needs to be filtered and to permit everything else:
R2# show access-lists
R2(config)# access-list 4 deny 1.1.4.0 0.0.0.255
R2(config)# access-list 4 permit any
Two distribute lists are configured to filter the prefix inbound from both neighbors, R1 and R3:
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 distribute-list 4 in
R2(config-router)# neighbor 23.1.1.3 distribute-list 4 in
The tricky part here is to understand the topology. If you do not understand the topology, silly mistakes can occur, which can cost you points in the CCIE lab. Particularly tricky is blocking the prefix from both neighbors.
Let’s verify the configuration:
!On R2:
R2# clear ip bgp * in
R2# show ip route 1.1.4.0
% Subnet not in table
R2# show ip bgp 1.1.4.0
% Network not in table
Task 3
Remove the configuration command from the previous task and then accomplish the same objective using prefix-list and distribute-list:
!On R2:
R2(config)# no access-list 4
R2(config)# router bgp 200
R2(config-router)# no neighbor 12.1.1.1 distribute-list 4 in
R2(config-router)# no neighbor 23.1.1.3 distribute-list 4 in
R2# clear ip bgp * in
Let’s verify the configuration:
!On R2:
R2# show ip bgp 1.1.4.0
BGP routing table entry for 1.1.4.0/24, version 11
Paths: (2 available, best # 2, table default)
Advertised to update-groups:
2
300 400 100
23.1.1.3 from 23.1.1.3 (33.3.3.3)
Origin IGP, localpref 100, valid, external
100
12.1.1.1 from 12.1.1.1 (1.1.4.1)
Origin IGP, metric 0, localpref 100, valid, external, best
R2# show ip route 1.1.4.0
Routing entry for 1.1.4.0/24
Known via "bgp 200", distance 20, metric 0
Tag 100, type external
Last update from 12.1.1.1 00:00:57 ago
Routing Descriptor Blocks:
* 12.1.1.1, from 12.1.1.1, 00:00:57 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
MPLS label: none
R2# show ip prefix-list
R2(config)# ip prefix-list TST seq 5 deny 1.1.4.0/24
R2(config)# ip prefix-list TST seq 10 permit 0.0.0.0/0 le 32
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 prefix-list TST in
R2(config-router)# neighbor 23.1.1.3 prefix-list TST in
R2# clear ip bgp * in
Note There are multiple ways to accomplish a given task—understanding and remembering the different ways can be the key to success.
Let’s verify the configuration:
!On R2:
R2# show ip bgp 1.1.4.0
% Network not in table
R2# show ip route 1.1.4.0
% Subnet not in table
Task 4
Configure R3 in AS 300 to filter network 22.0.0.0/8. Do not use distribute-list or prefix-list. Instead, route-map and access-list should be used to accomplish this task.
Let’s verify the existing entry in the BGP table:
!On R3:
R3# show ip bgp 22.0.0.0
BGP routing table entry for 22.0.0.0/8, version 8
Paths: (2 available, best # 2, table default)
Advertised to update-groups:
1
400 100 200
34.1.1.4 from 34.1.1.4 (4.4.4.4)
Origin IGP, localpref 100, valid, external
200
23.1.1.2 from 23.1.1.2 (22.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external, best
You can see that the local router is learning the prefix (22.0.0.0/8) from two neighbors: R2 and R4.
To filter the prefix, an access list is configured to deny the prefix that needs to be filtered and to allow the rest:
R3# show access-lists
R3(config)# access-list 22 deny 22.0.0.0 0.255.255.255
R3(config)# access-list 22 permit any
A route map is configured to reference the access list:
R3(config)# route-map TST permit 10
R3(config-route-map)# match ip address 22
A neighbor route-map command is used for each neighbor:
R3(config)# router bgp 300
R3(config-router)# neighbor 23.1.1.2 route-map TST in
R3(config-router)# neighbor 34.1.1.4 route-map TST in
R3# clear ip bgp * in
Let’s verify the configuration:
!On R3:
R3# show ip route 22.0.0.0
% Network not in table
R3# show ip bgp 22.0.0.0
% Network not in table
Task 5
Remove the access-list and route-map configuration from the previous task. Use a minimum number of lines in the access list to filter network 22.0.0.0/8. You should use access-list and route-map to accomplish this task.
!On R3:
R3(config)# no access-list 22
R3(config)# no route-map TST
R3(config)# access-list 22 permit 22.0.0.0 0.255.255.255
R3(config)# route-map TST deny 10
R3(config-route-map)# match ip address 22
R3(config)# route-map TST permit 90
Note Remember that the neighbor command is already configured.
Let’s verify the configuration:
!On R3:
R3# clear ip bgp * in
R3# show ip route 22.0.0.0
% Network not in table
R3# show ip bgp 22.0.0.0
% Network not in table
When you are asked to configure an access list with a minimum number of lines, you should always see whether the task can be accomplished using a single statement in the access list. Sometimes a single line can accomplish the task, and sometimes more lines are required in the access list to accomplish the given task.
Task 6
R4 should not see networks 1.1.0.0/24–1.1.4.0/24 in its BGP or routing table; you should configure a prefix list to accomplish this task. Do not use a route map or configure the solution on R4.
Let’s verify the existing BGP table of R4 for all the prefixes that originated in AS 100 (the regular expression will be covered in the next lab):
R4# show ip bgp regexp ^100$
BGP table version is 11, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.0.0/24 14.1.1.1 0 0 100 i
*> 1.1.1.0/24 14.1.1.1 0 0 100 i
*> 1.1.2.0/24 14.1.1.1 0 0 100 i
*> 1.1.3.0/24 14.1.1.1 0 0 100 i
*> 1.1.4.0/24 14.1.1.1 0 0 100 i
Because R4 cannot be configured to accomplish this task, R4’s neighbors are configured to filter the prefixes outbound toward R4:
!On R1 and R3:
Rx# show ip prefix-list
Rx(config)# ip prefix-list TST seq 5 deny 1.1.0.0/24
Rx(config)# ip prefix-list TST seq 10 deny 1.1.1.0/24
Rx(config)# ip prefix-list TST seq 15 deny 1.1.2.0/24
Rx(config)# ip prefix-list TST seq 20 deny 1.1.3.0/24
Rx(config)# ip prefix-list TST seq 25 deny 1.1.4.0/24
Rx(config)# ip prefix-list TST seq 30 permit 0.0.0.0/0 le 32
!On R1:
R1(config)# router bgp 100
R1(config-router)# neighbor 14.1.1.4 prefix-list TST out
R1# clear ip bgp * out
!On R3:
R3(config)# router bgp 300
R3(config-router)# neighbor 34.1.1.4 prefix-list TST out
R3# clear ip bgp * out
To verify the configuration:
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 2.0.0.0 34.1.1.3 0 300 200 i
*> 14.1.1.1 0 100 200 i
*> 3.0.0.0 34.1.1.3 0 0 300 i
* 14.1.1.1 0 100 200 300 i
*> 4.0.0.0 0.0.0.0 0 32768 i
*> 22.0.0.0 14.1.1.1 0 100 200 i
*> 33.0.0.0 34.1.1.3 0 0 300 i
* 14.1.1.1 0 100 200 300 i
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-9: Regular Expressions (Figure 10-9)
Figure 10-9 BGP Regular Expression Lab Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-9.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure BGP peering based on the following policy:
R1 in AS 100 should establish eBGP peer sessions with R2 in AS 200.
R2 should establish eBGP peer sessions with R1 and R3 in AS 100 and 300, respectively.
R3 should establish eBGP peer sessions with R2 and R4 in AS 200 and 400, respectively.
R4 should establish eBGP peer sessions with R3 in AS 300.
Advertise the loopback interfaces in BGP.
Do not use loopback interfaces for peering.
!On R1:
R1(config)# router bgp 100
R1(config-router)# no auto-summary
R1(config-router)# network 1.0.0.0
R1(config-router)# neighbor 12.1.1.2 remote-as 200
!On R2:
R2(config)# router bgp 200
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 100
R2(config-router)# neighbor 23.1.1.3 remote-as 300
You should see the following console message:
%BGP-5-ADJCHANGE: neighbor 12.1.1.1 Up
!On R3:
R3(config)# router bgp 300
R3(config-router)# no auto-summary
R3(config-router)# network 3.0.0.0
R3(config-router)# neighbor 23.1.1.2 remote-as 200
R3(config-router)# neighbor 34.1.1.4 remote-as 400
You should also see this console message:
%BGP-5-ADJCHANGE: neighbor 23.1.1.2 Up
!On R4:
R4(config)# router bgp 400
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# neighbor 34.1.1.3 remote-as 300
You should see the following console message as well:
%BGP-5-ADJCHANGE: neighbor 34.1.1.3 Up
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 23.1.1.3 0 0 300 i
*> 4.0.0.0 23.1.1.3 0 300 400 i
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 23.1.1.2 0 200 100 i
*> 2.0.0.0 23.1.1.2 0 0 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 34.1.1.3 0 300 200 100 i
*> 2.0.0.0 34.1.1.3 0 300 200 i
*> 3.0.0.0 34.1.1.3 0 0 300 i
*> 4.0.0.0 0.0.0.0 0 32768 i
R1# ping 4.4.4.4 source loopback0Loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/86/88 ms
Task 2
Configure R1 such that it filters all the prefixes that have originated in AS 300.
Table 10-1 translates the meaning of the parts of the regular expression used in this task.
Table 10-1 Regular Expression Used in Task 2
Basically, you are referencing the first AS number in the path. Another way of looking at this is to say that you don’t care about the prefixes that have been advertised by any other AS instances in the path, but you want to match the prefix that has been advertised or originated by the last ASN in the path. In this task, you are asked to filter prefixes that have originated from and not traversed through AS 300. Let’s look at the difference.
First, we’ll look at the prefixes that have traversed through AS 300:
R1# show ip bgp regexp _300_
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Now let’s see the prefixes that have originated in AS 300:
R1# show ip bgp regexp _300$
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 12.1.1.2 0 200 300 i
An ip as-path access-list is configured to deny any prefixes that have originated in AS 300 and to permit everything else:
!On R1:
R1(config)# ip as-path access-list 1 deny _300$
R1(config)# ip as-path access-list 1 permit .*
The ip as-path access-list is referenced in the neighbor filter-list command inbound through the neighbor 12.1.1.2 (R2):
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp regexp _300$
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Task 3
Remove the configuration from the previous task before proceeding to the next task:
!On R1:
R1(config)# no ip as-path access-list 1
R1(config)# router bgp 100
R1(config-router)# no neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Task 4
Configure R1 such that it blocks all the prefixes that have AS 300 in their AS-path list.
Let’s see all the prefixes that have traversed or have AS 300 in their AS-path list:
R1# show ip bgp regexp _300_
BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
!On R1:
R1(config)# ip as-path access-list 1 deny _300_
R1(config)# ip as-path access-list 1 permit .*
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
Task 5
Remove the configuration from the previous task before proceeding to the next task.
!On R1:
R1(config)# no ip as-path access-list 1
R1(config)# router bgp 100
R1(config-router)# no neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Task 6
Configure R3 such that it doesn’t advertise the prefixes that have originated in its own AS to any of its neighbors.
Let’s translate and test the regular expression shown in Table 10-2 before we start the configuration. Remember that the prefixes that originated in the local AS will not have their own ASN in the AS-path. The prefixes are only prepended when they are advertised to an eBGP neighbor. This method is used so the upstream AS instances will not use the local AS as a transit AS.
Table 10-2 Regular Expression Used in Task 6
Let’s test the regular expression:
!On R3:
R3# show ip bgp regexp ^$
BGP table version is 7, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 0.0.0.0 0 32768 i
Now that we know the regular expression works, we can perform the configuration:
!On R3:
R3(config)# ip as-path access-list 1 deny ^$
R3(config)# ip as-path access-list 1 permit .*
R3(config)# router bgp 300
R3(config-router)# neighbor 23.1.1.2 filter-list 1 out
R3(config-router)# neighbor 34.1.1.4 filter-list 1 out
R3# clear ip bgp * out
Let’s verify the configuration:
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 34.1.1.3 0 300 200 100 i
*> 2.0.0.0 34.1.1.3 0 300 200 i
*> 4.0.0.0 0.0.0.0 0 32768 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 23.1.1.3 0 300 400 i
Task 7
Remove the configuration from the previous task before proceeding to the next task:
!On R3:
R3(config)# no ip as-path access-list 1
R3(config)# router bgp 300
R3(config-router)# no neighbor 23.1.1.2 filter-list 1 out
R3(config-router)# no neighbor 34.1.1.4 filter-list 1 out
R3# clear ip bgp * out
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
!On R2:
R2# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 12.1.1.1 0 0 100 i
*> 2.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 23.1.1.3 0 0 300 i
*> 4.0.0.0 23.1.1.3 0 300 400 i
!On R4:
R4# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 34.1.1.3 0 300 200 100 i
*> 2.0.0.0 34.1.1.3 0 300 200 i
*> 3.0.0.0 34.1.1.3 0 0 300 i
*> 4.0.0.0 0.0.0.0 0 32768 i
Task 8
Configure R3 such that it blocks all the prefixes that have originated in the neighboring AS 200.
You know that ^ means the start of the string or a directly connected AS; therefore, the regular expression can start with ^, followed by the ASN, and then end with $, which indicates the end of the string. Let’s test this:
R3# show ip bgp regexp ^200$
BGP table version is 7, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.0.0.0 23.1.1.2 0 0 200 i
!On R3:
R3(config)# ip as-path access-list 1 deny ^200$
R3(config)# ip as-path access-list 1 permit .*
R3(config)# router bgp 300
R3(config-router)# neighbor 23.1.1.2 filter-list 1 in
R3# clear ip bgp * in
Let’s verify the configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 23.1.1.2 0 200 100 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
Task 9
Remove the configuration from the previous task before proceeding to the next task:
!On R3:
R3(config)# no ip as-path access-list 1
R3(config)# router bgp 300
R3(config-router)# no neighbor 23.1.1.2 filter-list 1 in
R3# clear ip bgp * in
Let’s verify the configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 23.1.1.2 0 200 100 i
*> 2.0.0.0 23.1.1.2 0 0 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
Task 10
Configure R3 such that it blocks all the prefixes from its existing directly connected neighbors.
Use Table 10-3 to translate the parts of the regular expression used in this task.
Table 10-3 Regular Expression for Task 10
Therefore, the regular expression (regexp) used in this solution means any AS number as long as it’s directly connected.
Let’s test the solution before implementing it:
R3# show ip bgp regexp ^[0-9]+$
BGP table version is 9, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.0.0.0 23.1.1.2 0 0 200 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
!On R3:
R3(config)# ip as-path access-list 1 deny ^[0-9]+$
R3(config)# ip as-path access-list 1 permit .*
R3(config)# router bgp 300
R3(config-router)# neighbor 23.1.1.2 filter-list 1 in
R3(config-router)# neighbor 34.1.1.4 filter-list 1 in
R3# clear ip bgp * in
Let’s verify the configuration:
!On R3:
R3# show ip bgp | beginBegin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 23.1.1.2 0 200 100 i
*> 3.0.0.0 0.0.0.0 0 32768 i
Task 11
Remove the configuration from the previous task before proceeding to the next task:
!On R3:
R3(config)# no ip as-path access-list 1
R3(config)# router bgp 300
R3(config-router)# no neighbor 23.1.1.2 filter-list 1 in
R3(config-router)# no neighbor 34.1.1.4 filter-list 1 in
R3# clear ip bgp * in
Let’s verify the configuration:
!On R3:
R3# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 23.1.1.2 0 200 100 i
*> 2.0.0.0 23.1.1.2 0 0 200 i
*> 3.0.0.0 0.0.0.0 0 32768 i
*> 4.0.0.0 34.1.1.4 0 0 400 i
Task 12
Configure R1 such that it blocks all the prefixes that have originated in AS 300 and traversed through AS 200.
Let’s test the regular expression:
R1# show ip bgp regexp _200_300$
BGP table version is 13, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3.0.0.0 12.1.1.2 0 200 300 i
!On R1:
R1(config)# ip as-path access-list 1 deny _200_300$
R1(config)# ip as-path access-list 1 permit .*
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Task 13
Remove the configuration command from the previous task before proceeding to the next task:
!On R1:
R1(config)# no ip as-path access-list 1
R1(config)# router bgp 100
R1(config-router)# no neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Task 14
Configure R1 in AS 100 to filter prefixes from the directly connected AS 200 if their AS number has been prepended multiple times.
Before writing and applying the as-path access-list, you should issue a show ip bgp regexp command. If the desired output is displayed, the as-path access-list should be written and applied.
Note In the following regular expression, the (_1) section can be thought of as the memory button in a calculator; basically, the expression before it, ^([0-9]+), is what you are putting in memory location 1, and the asterisk (*) specifies zero or more occurrences of the expression in memory location 1.
!On R1:
R1# show ip bgp regexp ^([0-9]+)(_1)*$
BGP table version is 19, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.0.0.0 12.1.1.2 0 0 200 i
Because the * before the $ means zero or more occurrences, the preceding regular expression will reference the prefixes regardless of whether or not the neighboring AS 200 has prepended its ASN. Therefore, let’s replace * with +, which will only match if AS 200 has prepended its ASN.
R1# show ip bgp regexp ^([0-9]+)(_1)+$
Obviously AS 200 is not prepending its AS number, and that’s why we don’t see any prefixes in the AS-path. Let’s configure and test this:
R1(config)# ip as-path access-list 1 deny ^([0-9]+)(_1)+$
R1(config)# ip as-path access-list 1 permit .*
There are two ways to test the regular expression before applying it to a given neighbor:
1. show ip bgp regexp
2. show ip bgp filter-list
The next step is to apply the regular expression to the neighbor(s):
R1(config)# router bgp 100
R1(config-router)# neighbor 12.1.1.2 filter-list 1 in
The following uses the refresh messages so the changes can apply to the existing and new prefixes:
R1# clear ip bgp * in
Let’s verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
To properly test this, let’s configure R2 to prepend its AS number multiple times:
R2(config)# ip prefix-list NET permit 2.0.0.0/8
R2(config)# route-map TST permit 10
R2(config-route-map)# match ip address prefix-list NET
R2(config-route-map)# set as-path prepend 200
R2(config-route-map)# route-map TST permit 90
R2(config)# router bgp 200
R2(config-router)# neighbor 12.1.1.1 route-map TST out
R2# clear ip bgp * out
Let’s verify and test the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
R1# show ip bgp filter-list 1
BGP table version is 18, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Because R2 is prepending its AS number multiple times, R1 filters the prefix. Let’s remove the filtering configuration from R1 and verify:
!On R1:
R1(config)# no ip as-path access-list 1
R1(config)# router bgp 100
R1(config-router)# no neighbor 12.1.1.2 filter-list 1 in
R1# clear ip bgp * in
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Let’s remove the configuration from R2:
!On R2:
R2(config)# no ip prefix-list NET
R2(config)# no route-map TST
R2(config)# router bgp 200
R2(config-router)# no neighbor 12.1.1.1 route-map TST out
R2# clear ip bgp * out
Let’s test and verify the configuration:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 12.1.1.2 0 0 200 i
*> 3.0.0.0 12.1.1.2 0 200 300 i
*> 4.0.0.0 12.1.1.2 0 200 300 400 i
Erase the startup config and reload the routers before proceeding to the next lab.
Lab 10-10: BGP Confederation
BGP confederations are designed to help manage iBGP meshing. They can be used instead of or in combination with route reflectors, which we discussed in detail in Lab 10-2. The most basic functionality of BGP confederations is to split up the autonomous system into smaller, more manageable autonomous systems, which are represented as one single autonomous system to eBGP peers outside the confederation. BGP confederations were originally defined in RFC 3065 (currently RFC 5065).
By creating smaller autonomous system domains—or sub-AS domains, as they are often called—it is possible to restrict the number of iBGP sessions required to create a full mesh. This is made possible by only requiring the full mesh configuration within each independent sub-AS. We illustrate this in our working environment by creating three distinct sub-autonomous systems. We will use the private AS range to accomplish this. The autonomous system numbers within the range 64,512 through 65,535 are reserved for private use. Confederations often employ these private AS numbers. At this juncture of our conversation, we will utilized the autonomous system numbers 65511, C65522, and 65534 to apply confederations under AS 100. The first stage will be to create the topology outlined in Figure 10-10.
Figure 10-10 BGP Confederation Topology
The initial configuration files used in this lab can be found by downloading the BGP-Lab-10.txt file and subsequently applying those configurations on a device-by-device basis.
Task 1
Configure BGP peering on the routers as follows:
Configure routers R1–R4 in a confederation with a public AS number of 100.
R1 in sub-AS 65511 should establish an eBGP peer session with R2 in sub-AS 65522.
R2 in sub-AS 65522 should establish eBGP peer sessions with R1 and R3 in sub-AS 65511 and sub-AS 65534, respectively.
R3 in sub-AS 65534 should establish an eBGP peer session with R2 in sub-AS 65522 and an iBGP peer session with R4 in AS 65534.
R4 in sub-AS 65534 should establish an iBGP peer session with R3 and an eBGP peer session with R5 in AS 500.
R5 in AS 500 should establish an eBGP peer session with R4 in AS 100.
These routers should advertise their loopback interface in BGP.
AS 100 should use OSPF for the links within the AS.
!On R1:
R1(config)# router ospf 1
R1(config-router)# network 12.1.1.1 0.0.0.0 area 0
R1(config)# router bgp 65511
R1(config-router)# no auto-summary
R1(config-router)# network 1.0.0.0
R1(config-router)# neighbor 12.1.1.2 remote-as 65522
R1(config-router)# bgp confederation identifier 100
The BGP confederation identifier command is used to configure a single AS number to identify a group of smaller autonomous systems as a single confederation. This command must be configured on all the routers within the confederation.
A confederation can be used to reduce the iBGP mesh by dividing a large single AS into multiple sub-AS instances and then grouping them into a single confederation.
R1(config-router)# bgp confederation peers 65522
The preceding command is used to identify the directly connected eBGP sub-confederation peers.
!On R2:
R2(config)# router ospf 1
R2(config-router)# network 12.1.1.2 0.0.0.0 area 0
R2(config-router)# network 23.1.1.2 0.0.0.0 area 0
R2(config)# router bgp 65522
R2(config-router)# no auto-summary
R2(config-router)# network 2.0.0.0
R2(config-router)# neighbor 12.1.1.1 remote-as 65511
R2(config-router)# neighbor 23.1.1.3 remote-as 65534
R2(config-router)# bgp confederation identifier 100
R2(config-router)# bgp confederation peers 65511 65534
!On R3:
R3(config)# router ospf 1
R3(config-router)# network 34.1.1.3 0.0.0.0 area 0
R3(config-router)# network 23.1.1.3 0.0.0.0 area 0
R3(config)# router bgp 65534
R3(config-router)# no auto-summary
R3(config-router)# neighbor 34.1.1.4 remote-as 65534
R3(config-router)# neighbor 23.1.1.2 remote-as 65522
R3(config-router)# network 3.0.0.0
R3(config-router)# bgp confederation identifier 100
Note R3 did not configure R4 (AS 65534) as a confederation peer because the local router (R3) is in the same sub-confederation as R4.
R3(config-router)# bgp confederation peers 65522
Note R4 runs OSPF on the external link (45.1.1.0/24). This is configured so the routers within AS 100 can have reachability to the next-hop IP address for all the prefixes advertised by R5 in AS 500. Also, passive-interface fastethernet0/0 is configured so that if R5 runs OSPF on the same link, it will not be able to establish an OSPF adjacency with R4 and have information on all the private IP addresses advertised in AS 100.
R4(config)# router ospf 1
R4(config-router)# network 34.1.1.4 0.0.0.0 area 0
R4(config-router)# network 45.1.1.4 0.0.0.0 area 0
R4(config-router)# passive-interface fastethernet0FastEtherenet0/0
R4(config)# router bgp 65534
R4(config-router)# no auto-summary
R4(config-router)# network 4.0.0.0
R4(config-router)# bgp confederation identifier 100
R4(config-router)# neighbor 45.1.1.5 remote-as 500
R4(config-router)# neighbor 34.1.1.3 remote-as 65534
Note R4 does not have any directly connected eBGP sub-confederation peers. Therefore, the bgp confederation peers command is not configured.
!On R5:
R5(config)# router bgp 500
R5(config-router)# no auto-summary
R5(config-router)# network 5.0.0.0
R5(config-router)# neighbor 45.1.1.4 remote-as 100
Let’s verify the configuration:
!On R5:
R5# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 45.1.1.4 0 100 i
*> 2.0.0.0 45.1.1.4 0 100 i
*> 3.0.0.0 45.1.1.4 0 100 i
*> 4.0.0.0 45.1.1.4 0 0 100 i
*> 5.0.0.0 0.0.0.0 0 32768 i
From R5’s perspective, all the prefixes are from AS 100:
!On R1:
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0 0.0.0.0 0 32768 i
*> 2.0.0.0 10.1.12.2 0 100 0 (65522) i
*> 3.0.0.0 10.1.23.3 0 100 0 (65522 65534) i
*> 4.0.0.0 10.1.34.4 0 100 0 (65522 65534) i
*> 5.0.0.0 10.1.45.5 0 100 0 (65522 65534) 500 i
Note The AS paths in parentheses are the private AS numbers within the confederation; AS 500 is outside of the parentheses because it’s not part of the confederation.
Erase the startup config and reload the routers before proceeding to the next lab.