Lab 10 - BGP Bestpath Selection - Weight

This lab and the next several labs will focus on BGP the bestpath selection parameters used by BGP to choose the prefer path to a given prefix. This lab will focus on the WEIGHT attribute which is the first attribute look at by the best path algorithm.

Concepts covered

-BGP path selection

-BGP Weight

-Applying attributes to prefixes using route-maps

Topology

GNS3 files: Link

Solution

Let's being by setting up our basic BGP peering

R1(config)#router bgp 10

R1(config-router)#neighbor 192.168.21.2 remote

R1(config-router)#neighbor 192.168.21.2 remote-as 20

R1(config-router)#neighbor 192.168.13.3 remote-as 30

R2(config)#router bgp 20

R2(config-router)#neighbor 192.168.21.1 remote-as 10

R2(config-router)#neighbor 192.168.24.4 remote-as 40

R3(config)#router bgp 30

R3(config-router)#neighbor 192.168.13.1 remote-as 10

R3(config-router)#neighbor 192.168.34.4 remote-as 40

R4(config)#router bgp 40

R4(config-router)#neighbor 192.168.24.2 remote-as 20

R4(config-router)#neighbor 192.168.34.3 remote-as 30

Now let's advertise our loopback addresses

R1(config)#router bgp 10

R1(config-router)#network 11.11.11.0 mask 255.255.255.0

R2(config)#router bgp 20

R2(config-router)#network 22.22.22.0 mask 255.255.255.0

R3(config)#router bgp 30

R3(config-router)#network 33.33.33.0 mask 255.255.255.0

R4(config)#router bgp 40

R4(config-router)#network 44.44.44.0 mask 255.255.255.0

To apply the WEIGHT attribute to the AS 40 prefixes we will use an as-path access list in concert with a route map and apply that route map to the neighbor statement for our preferred path

R1(config)#ip as-path access-list 1 permit _40$

R1(config)#routerrouter bgp 10

R1(config-router)#neighbor 192.168.13.3 route-map PREFER_AS30 in

After clearing the BGP neighbors to flush the BGP RIB we get the following results.

R1#sh ip bgp

BGP table version is 5, local router ID is 11.11.11.11

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

 *>  11.11.11.0/24     0.0.0.0                        0         32768 i

 *>  22.22.22.0/24     192.168.21.2             0             0 20 i

 *                                   192.168.13.3                             0 30 40 20 i

 *   33.33.33.0/24      192.168.21.2                            0 20 40 30 i

 *>                                192.168.13.3              0             0 30 i

 *   44.44.44.0/24      192.168.21.2                            0 20 40 i

 *>                                  192.168.13.3                     1000 30 40 I

And when we trace

R1#traceroute 44.44.44.44 source loopback 10

Type escape sequence to abort.

Tracing the route to 44.44.44.44

VRF info: (vrf in name/id, vrf out name/id)

  1 192.168.13.3 28 msec 48 msec 24 msec

  2 192.168.34.4 32 msec *  72 msec

Sources:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Lab 9 - BGP Peer Groups

This small lab focuses on the use of Peer Groups to simplify BGP configuration

Complete the following tasks:

-Configure iBGP peerings between R2-R3, R2-R4, and R2-R1

-Configure R3,R4, and R1 and route reflector clients of R2

-Configure the iBGP peering using the peer group name PEER_iBGP

-Advertise the loopback addresses of R3 and R4 and ensure R1 can reach

the loopback addresses when packets are sourced from its loopback 0

address

-All BGP peers should authenticate with the password CISCO1

Topology

  

Concepts tested:

-Peer groups

-Prefix advertisement

-route reflectors

GNS3 files: Link

Solution

Let's begin with configuring our iBGP peering.

R1(config)#router bgp 100

R1(config-router)#neighbor 192.168.12.2 remote-as 100

R1(config-router)#neighbor 192.168.12.2 password CISCO1

Below we use the peer-group option to create a single configuration profile that we can then apply to multiple peers. In this case R1, R3, and R4.

R2(config)#router bgp 100

R2(config-router)#neighbor PEER_IBGP peer-group

R2(config-router)#neighbor PEER_IBGP remote-as 100

R2(config-router)#neighbor PEER_IBGP route-reflector-client

R2(config-router)#neighbor PEER_IBGP next-hop-self

R2(config-router)#neighbor PEER_IBGP password CISCO1

R2(config-router)#neighbor 192.168.23.3 peer-group PEER_IBGP

R2(config-router)#neighbor 192.168.12.1 peer-group PEER_IBGP

R2(config-router)#neighbor 192.168.24.4 peer-group PEER_IBGP

Also, we use the password option on the neighbor command to configure MD5 authentication between our peers.

R3(config)#router bgp 100

R3(config-router)#neighbor 192.168.23.2 remote-as 100

R3(config-router)#neighbor 192.168.23.2 password CISCO1

R4(config)#router bgp 100

R4(config-router)#neighbor 192.168.24.2 remote-as 100

R4(config-router)#neighbor 192.168.24.2 password CISCO1

Now let's advertise our loopback addresses

R1(config-if)#router bgp 100

R1(config-router)#network 1.1.1.0 mask 255.255.255.0

R3(config)#router bgp 100

R3(config-router)#network 172.16.0.0 mask 255.255.255.0

R3(config-router)#network 172.16.1.0 mask 255.255.255.0

R3(config-router)#network 172.16.2.0 mask 255.255.255.0

R3(config-router)#network 172.16.3.0 mask 255.255.255.0

R4(config)#router bgp 100

R4(config-router)#network 172.16.4.0 mask 255.255.255.0

R4(config-router)#network 172.16.5.0 mask 255.255.255.0

R4(config-router)#network 172.16.6.0 mask 255.255.255.0

R4(config-router)#network 172.16.7.0 mask 255.255.255.0

Now we should just have to advertise our loopback address on R1 and we should be good to go.

R1(config)#int lo 0

R1(config-if)#ip add 1.1.1.1 255.255.255.0

R1#ping 172.16.1.1 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, 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 = 36/46/68 ms

Lab 8 - Redistributing iBGP into IGP

This lab focuses on the use of the BGP redistribution-internal command and some of the pit falls of redistributing BGP into an IGP domain.

Concepts tested

-eBGP and IBGP peering

-Next hop path manipulation

-BGP/IGP redistsribution

-Administrative distance

Tasks to complete this lab:

-Configure a eBGP peering between R1 and PE1

-configure iBGP peering between R1, R3, and R3 in AS 200

-Configure R1 and R4 to be route reflector clients of R3

-Redistribute BGP into EIGRP on R4 and ensure that R5

can reach all the advertised prefixes of PE1 when sourced from its

loopback address

-Resolve all routing issues

Constraints

-BGP must be redistributed into EIGRP on R4 and no where else

Topology

GNS3 files: link

Solution

We begin by configuring our peering between our respective BGP speakers as required by the lab.

R1(config)#router bgp 200

R1(config-router)#neighbor 192.168.11.11 remote-as 100

R1(config-router)#neighbor 192.168.13.3 remote-as 200

R3(config)#router bgp 200

R3(config-router)#neighbor 192.168.13.1 remote-as 200

R3(config-router)#neighbor 192.168.13.1 route-reflector-client

R3(config-router)#neighbor 192.168.34.1 remote-as 200

R3(config-router)#neighbor 192.168.34.1 route-reflector-client

R4(config)#router bgp 200

R4(config-router)#neighbor 192.168.34.3 remote

R4(config-router)#neighbor 192.168.34.3 remote-as 200

We also need add the next-hop-self command on R1 when sending advertisements to R3 because that will provide a next hop prefix that can be recursively looked up by the downstream routers when routing to PE1's advertised prefixes.

R1(config)#router bgp 200

R1(config-router)#neighbor 192.168.13.3 next-hop-self

With that configuration in place let's look at R3's and R4's routing tables

R3#sh ip route

<snip>

Gateway of last resort is not set

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.1.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.2.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.3.0 [200/0] via 192.168.13.1, 00:13:57

<snip>

R4#sh ip route

<snip>

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.1.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.2.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.3.0 [200/0] via 192.168.13.1, 00:00:43

<snip>

R5#sh ip route

<snip>

      5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        5.5.5.0/24 is directly connected, Loopback0

L        5.5.5.5/32 is directly connected, Loopback0

D     192.168.13.0/24 [90/2172416] via 192.168.35.3, 00:44:22, Serial1/0

D     192.168.34.0/24 [90/2681856] via 192.168.45.4, 00:44:22, Serial1/1

                      [90/2681856] via 192.168.35.3, 00:44:22, Serial1/0

      192.168.35.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.35.0/24 is directly connected, Serial1/0

L        192.168.35.5/32 is directly connected, Serial1/0

      192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.45.0/24 is directly connected, Serial1/1

L        192.168.45.5/32 is directly connected, Serial1/1

As we can see from the output above R5 does not see any of PE1's prefixes yet. So we should redistribute BGP into EIGRP on R4 and make sure R5's loopback can reach PE1's prefixes, which just happens to be the next task to complete.

R4(config)#router eigrp 200

R4(config-router)#redistribute bgp 200 metric 1 1 1 1 1

Now let's look at the routing tables again.

R3#sh ip route

<snip>

Gateway of last resort is not set

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.1.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.2.0 [200/0] via 192.168.13.1, 00:13:57

B        172.16.3.0 [200/0] via 192.168.13.1, 00:13:57

<snip>

R4#sh ip route

<snip>

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.1.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.2.0 [200/0] via 192.168.13.1, 00:00:43

B        172.16.3.0 [200/0] via 192.168.13.1, 00:00:43

<snip>

R5#sh ip route

<snip>

      5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        5.5.5.0/24 is directly connected, Loopback0

L        5.5.5.5/32 is directly connected, Loopback0

D     192.168.13.0/24 [90/2172416] via 192.168.35.3, 00:44:22, Serial1/0

D     192.168.34.0/24 [90/2681856] via 192.168.45.4, 00:44:22, Serial1/1

                      [90/2681856] via 192.168.35.3, 00:44:22, Serial1/0

      192.168.35.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.35.0/24 is directly connected, Serial1/0

L        192.168.35.5/32 is directly connected, Serial1/0

      192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.45.0/24 is directly connected, Serial1/1

L        192.168.45.5/32 is directly connected, Serial1/1

Hmmm…the tables look the same as before. The problem here is that by default you cannot redistribute iBGP into an IGP. eBGP learned prefixes will redistribute by default but because we are doing the redistribution on R4 the prefixes are learned via an iBGP neighbor. To get around this we use the BGP redistribute-internal command. Be careful doing this in a production environment as this can lead to resource and looping issues if not done with careful consideration of its impact to the routing tables of your network.

R4(config)#router bgp 200

R4(config-router)#bgp redistribute-internal

OK, now let's examine the routing tables again.

R3#sh ip rout

<snip>

      172.16.0.0/24 is subnetted, 4 subnets

D EX     172.16.0.0 [170/2560512256] via 192.168.34.4, 00:00:34, Serial1/0

D EX     172.16.1.0 [170/2560512256] via 192.168.34.4, 00:00:34, Serial1/0

D EX     172.16.2.0 [170/2560512256] via 192.168.34.4, 00:00:34, Serial1/0

D EX     172.16.3.0 [170/2560512256] via 192.168.34.4, 00:00:34, Serial1/0

<snip>

R4#sh ip route

<snip>

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:01:04

B        172.16.1.0 [200/0] via 192.168.13.1, 00:01:04

B        172.16.2.0 [200/0] via 192.168.13.1, 00:01:04

B        172.16.3.0 [200/0] via 192.168.13.1, 00:01:04

<snip>

R5#sh ip route

<snip>      172.16.0.0/24 is subnetted, 4 subnets

D EX     172.16.0.0 [170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1

D EX     172.16.1.0 [170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1

D EX     172.16.2.0 [170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1

D EX     172.16.3.0 [170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1

<snip>

Ah, now we see PE1's prefixes in our global routing table. Now we just need to make sure PE1 can see R5's loopback address and we should be good…?

R5(config)#router eigrp 200

R5(config-router)#network 5.5.5.0 0.0.0.255

R1(config)#router bgp 200

R1(config-router)#network 5.5.5.0 mask 255.255.255.0

OK, lets ping and see what we get…

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:

Packet sent with a source address of 5.5.5.5

.....

Success rate is 0 percent (0/5)

Hhmm…

R5#traceroute 172.16.1.1 source loopback 0

Type escape sequence to abort.

Tracing the route to 172.16.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 192.168.45.4 24 msec 20 msec 24 msec

  2 192.168.34.3 16 msec 20 msec 44 msec

  3 192.168.34.4 64 msec 16 msec 48 msec

  4 192.168.34.3 64 msec 52 msec 60 msec

  5 192.168.34.4 48 msec 64 msec 84 msec

  6 192.168.34.3 80 msec 52 msec 88 msec

  7 192.168.34.4 128 msec 108 msec 108 msec

<snip>

Well that is not good, so what is going on here. Take a look at R5's routing table and specifically look at the next hop values for the PE1 routes. They all point back to R4 because that is where R3 learned the route from. So again there are usually multiple ways to resolve this but let's fix this by focusing on what the problem is. EIGRP has pre-empted the BGP routes in the routing table due to its lower administrative distance. So to solve that problem we can change the admin distance of external EIGRP routes.

R3(config)#router eigrp 200

R3(config-router)#distance eigrp 90 201

R3(config-router)#do sh ip route

<snip>

      172.16.0.0/24 is subnetted, 4 subnets

B        172.16.0.0 [200/0] via 192.168.13.1, 00:00:08

B        172.16.1.0 [200/0] via 192.168.13.1, 00:00:08

B        172.16.2.0 [200/0] via 192.168.13.1, 00:00:08

B        172.16.3.0 [200/0] via 192.168.13.1, 00:00:08

      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.13.0/24 is directly connected, FastEthernet0/0

L        192.168.13.3/32 is directly connected, FastEthernet0/0

      192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.34.0/24 is directly connected, Serial1/0

L        192.168.34.3/32 is directly connected, Serial1/0

Note: Unfortunately it's not possible at this time to conditional modify the EIGRP administrative distance for external routes. This is only possible for internal routes.

Now that looks better…

R5#traceroute 172.16.1.1 source loopback 0

Type escape sequence to abort.

Tracing the route to 172.16.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 192.168.45.4 24 msec 32 msec 36 msec

  2 192.168.34.3 20 msec 52 msec 52 msec

  3 192.168.13.1 52 msec 80 msec 84 msec

  4 192.168.11.11 80 msec *  88 msec

Obviously one my question why redistribute on R4 in the first place but this is a lab and we are intentionally not following best practices to create scenarios to test our knowledge of specific concepts.

Sources:

http://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/113153-adjust-ad-00.html

Lab 7 - BGP over GRE

Understanding how BGP operates over tunneling technology such as GRE tunnels can be helpful when studying more advanced concepts like MPLS. This lab hopes to help reinforce some of those basic concepts before we move on into those more advanced topics.

Concepts covered:

-eBGP peering

-Configuring GRE tunnels

-Modifying BGP next-hop parameters

-eBGP multi-hop

-BGP routing over non BGP clouds

Topology used

Tasks to complete this lab

-Establish eBGP peering between R1 and PE10

-Establish eBGP peering between R3 and PE20

-Establish eBGP peering between R1 and R3

-Advertise the loopback address of R1 and R3 into BGP

-Ensure R1 can reach the loopback address of PE20 and R3 can reach the loopback of PE10 when sourcing packets from their respective loopback interfaces

Constraints

-Use the subnet 99.9.9.0/24 for any tunnel interfaces

-Do not modify the IGP configuration

-Do not redistribute any addresses into the IGP

-Do not modify the configuration on PE10 and PE20

-Do not modify any configuration on R2

GNS3 lab files: link

Solution

Though there are alternative solutions to the approach I use, this one provides a better learning opportunity then some of the other options which I will mention at the end of the blog.

Let's begin by configuring our eBGP peering

R1(config-router)#router bgp 100

R1(config)#neighbor 192.168.1.10 remote-as 10

R1(config)#neighbor 192.168.3.3 remote-as 200

R1(config)#neighbor 192.168.3.3 ebgp-multihop 255

R3(config-router)#router bgp 100

R3(config)#neighbor 192.168.4.20 remote-as 20

R3(config)#neighbor 192.168.2.1 remote-as 100

R3(config)#neighbor 192.168.2.1 ebgp-multihop 255

With the eBGP peering established we move on to the next task which is to redistribute R1 and R2's loopback addresses

R1(config)#access-list 1 permit 1.1.1.1

R1(config)#route-map LOOPBACK_0 permit 10

R1(config-route-map)#match ip address 1

R1(config)#router bgp 100

R1(config-router)#redistribute connected route-map LOOPBACK_0

R3(config)#access-list 1 permit 3.3.3.3

R3(config)#route-map LOOPBACK_0 permit 10

R3(config-route-map)#match ip address 1

R3(config)#router bgp 200

R3(config-router)#redistribute connected route-map LOOPBACK_0

A network statement above would have also worked but I like to make things a little more complicated to keep my acl/route-map skills up.

So at this point we should see the loopback networks on PE10 and PE20.

PE10#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.1.1              0             0 100 ?

 *>  3.3.3.3/32       192.168.1.1                            0 100 200 ?

 *>  10.10.10.10/32   0.0.0.0                  0         32768 i

 *>  20.20.20.20/32   192.168.1.1                            0 100 200 20 i

PE20#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.4.3                            0 200 100 ?

 *>  3.3.3.3/32       192.168.4.3              0             0 200 ?

 *>  10.10.10.10/32   192.168.4.3                            0 200 100 10 i

 *>  20.20.20.20/32   0.0.0.0                  0         32768 i

And we do, so what do these prefixes look like on their peers R1 and R3

R1#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       0.0.0.0                  0         32768 ?

 *>  3.3.3.3/32       192.168.3.3              0             0 200 ?

 *>  10.10.10.10/32   192.168.1.10             0             0 10 i

 *>  20.20.20.20/32   192.168.3.3                              0 200 20 i

R3#sh ip bgp

<snip>

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       192.168.2.1              0             0 100 ?

 *>  3.3.3.3/32       0.0.0.0                  0         32768 ?

 *>  10.10.10.10/32   192.168.2.1                               0 100 10 i

 *>  20.20.20.20/32   192.168.4.20             0             0 20 i

OK, let's see if we can ping these networks source from the loopbacks on R1 and R3.

R1#ping 20.20.20.20 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

…..

Success rate is 0 percent (0/5)

R3#ping 10.10.10.10 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

.....

Success rate is 0 percent (0/5)

Well that is not good. The reason we cannot ping these addresses is because R2 has no knowledge of these networks.

R2#sh ip route

<snip>

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets

O        1.1.1.1 [110/2] via 192.168.2.1, 01:01:45, FastEthernet0/0

      2.0.0.0/32 is subnetted, 1 subnets

C        2.2.2.2 is directly connected, Loopback0

      3.0.0.0/32 is subnetted, 1 subnets

O        3.3.3.3 [110/2] via 192.168.3.3, 01:01:31, FastEthernet0/1

      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.2.0/24 is directly connected, FastEthernet0/0

L        192.168.2.2/32 is directly connected, FastEthernet0/0

      192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.3.0/24 is directly connected, FastEthernet0/1

L        192.168.3.2/32 is directly connected, FastEthernet0/1

Since we cannot modify R2 in any way or redistribute into IGP we are going to have to use the routing table on R2 as it exists. That means if we can tunnel the packets through R2 then we can solve our problem.

This requires essentially two steps, first create a GRE tunnel then modify the next-hop attributes on the BGP prefixes so that traffic for those prefixes go over the tunnel.

Let's start with creating the tunnels

R1(config)#interface Tunnel0

R1(config-if)#ip address 99.9.9.1 255.255.255.0

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360

R1(config-if)#tunnel source FastEthernet0/1

R1(config-if)#tunnel destination 192.168.3.3

R1(config)#interface Tunnel0

R1(config-if)#ip address 99.9.9.3 255.255.255.0

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360

R1(config-if)#tunnel source FastEthernet0/0

R1(config-if)#tunnel destination 192.168.2.1

Next we identify the traffic we want to modify  and then modify the next-hop attribute using a route-map

R1(config)#route-map CHANGE_NEXT_HOP permit 10

R1(config-route-map)# match as-path 1

R1(config-route-map)# set ip next-hop 99.9.9.1

R1(config-route-map)#route-map CHANGE_NEXT_HOP permit 999

R1(config-route-map)#exit

R3(config)#route-map CHANGE_NEXT_HOP permit 10

R3(config-route-map)# match as-path 1

R3(config-route-map)# set ip next-hop 99.9.9.3

R3(config-route-map)#route-map CHANGE_NEXT_HOP permit 999

R3(config-route-map)#exit

Now let's ping our IP addresses again and see the results

R1#ping 20.20.20.20 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.20.20.20, 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 = 48/72/84 ms

R3#ping 10.10.10.10 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, 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/97/120 ms

Success!

Keep in mind that there are several ways to approach solving this issue. Another approach could have been to simply establish the eBGP peering between R1 and R3 using the tunnel interfaces. This would have accomplish essentially the same thing because the next-hop address for the advertised prefixes would have been the update source address which is the tunnel interface. Another option could be use policy based routing to modify the next hop.

Lab 6 - BGP Aggregation

This lab is focused on the concept of aggregation and some of its optional features such as summary-only and as-set. To solve this lab properly focus on the constraints  and requirements.

Concepts tested:

-Aggregation and AS_PATH attributes

-Community attribute manipulation

-AS_PATH filtering

Topology used

Using the aggregate-address command complete the following tasks:

1. Configure eBGP on all routers per the diagram

2. Advertise all loopback addresses on R3 and R4 into BGP

3. Aggregate the loopbacks of R3 and R4 on R2 so that only a single prefix for those networks exist

R1

4. Modify the prefix 172.16.1.0/24 to include the no-export community when advertised to AS 200

- R3 and R4 should only see their own BGP prefixes in their local BGP RIB table

- R3 and R4 should not see the aggregate address in their local BGP RIB table

- R1 should only be able to see the aggregate address in its local BGP RIB table

- Do not use prefix filtering to accomplish this

- Any summarization should only contain R3 and R4 prefixes with no overlap with any other prefixes

GNS3 files: Link

Solution

To begin configure the neighbor sessions:

R1(config)#router bgp 100

R1(config-router)#neighbor 192.168.12.2 remote-as 200

R2(config)#router bgp 200

R2(config-router)#neighbor 192.168.12.1 remote-as 100

R3(config)#router bgp 300

R3(config-router)#neighbor 192.168.23.2 remote-as 200

R4(config)#router bgp

R4(config-router)#neighbor 192.168.24.2 remote-as 200

Then advertise the loopbacks on R3 and R4

R3(config-router)#network 172.16.1.0 mask 255.255.255.0

R3(config-router)#network 172.16.2.0 mask 255.255.255.0

R3(config-router)#network 172.16.3.0 mask 255.255.255.0

R3(config-router)#network 172.16.1.0 mask 255.255.255.0 ?

R4(config-router)#network 172.16.4.0 mask 255.255.255.0

R4(config-router)#network 172.16.5.0 mask 255.255.255.0

R4(config-router)#network 172.16.6.0 mask 255.255.255.0

R4(config-router)#network 172.16.7.0 mask 255.255.255.0

Then configure R3 to add and send the no-export community for the 172.16.1.0/24 prefix

R3(config)#ip prefix-list NET_172.16.1.0 permit 172.16.1.0/24

R3(config)#route-map NO_EXPORT permit

R3(config-route-map)#match ip address prefix-list NET_172.16.1.0

R3(config-route-map)#set community no-export

R3(config-route-map)#exit

Don't forget to enable R3 to send communities

R3(config-router)#neighbor 192.168.23.2 send-community both

R1 should now see all prefixes except 172.16.1.0/24

R1#sh ip bgp

BGP table version is 27, local router ID is 192.168.12.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

*> 172.16.0.0/24    192.168.12.2                           0 200 300 i

*> 172.16.2.0/24    192.168.12.2                           0 200 300 i

*> 172.16.3.0/24    192.168.12.2                           0 200 300 i

*> 172.16.4.0/24    192.168.12.2                           0 200 400 i

*> 172.16.5.0/24    192.168.12.2                           0 200 400 i

*> 172.16.6.0/24    192.168.12.2                           0 200 400 i

*> 172.16.7.0/24    192.168.12.2                           0 200 400 i

Now configure R2 to send an aggregate of the prefixes for R3 and R4 loopback addresses but with some constraints. First R3 and R4 should not see each other prefix advertisements or the aggregate address advertised by AS200. R1 should only see the aggregate address and not the sub-prefixes from R3 and R4.

So the R1 constraint is simple, just use the summary-only option with the aggregate command which tells BGP to only send the /21 prefix and filter all the sub-prefixes of R3 and R4. But how do we filter the prefixes from R3 and R4 without using prefix filtering. Well we use the as-set option. This option says to send the aggregate address but include the attributes of the included prefixes such as community values and includes the AS_SET information of the sub-prefixes as well.

So with this option enabled a couple of thisngs happen. First the AS_PATH information now includes the AS's from R3 and R4 as well as the community values. So this solves our filter problem because R3 and R4 will no longer accept the aggregate address because they will now see their AS in the AS_PATH information.

*> 172.16.0.0/21    192.168.12.2             0             0 200 {300,400} I

But this also creates a new problem. Because the aggregate inherits the attributes of the sub-prefixes it inherited the no-community attribute and is now no longer being advertised by R2. We solve that with the attribute-map command.

R2(config)#route-map NO_COMMUNITY permit

R2(config-route-map)#set community none

R2(config-route-map)#exit

R2(config-router)#aggregate-address 172.16.0.0 255.255.248.0 summary-only as-set attribute-map NO_COMMUNITY

Now everything look good

R1#sh ip bgp

<snip>

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.16.0.0/21    192.168.12.2             0             0 200 {300,400} i

R3#sh ip bgp

<snip>

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.16.0.0/24    0.0.0.0                  0         32768 i

*> 172.16.1.0/24    0.0.0.0                  0         32768 i

*> 172.16.2.0/24    0.0.0.0                  0         32768 i

*> 172.16.3.0/24    0.0.0.0                  0         32768 i

R4#sh ip bgp

<snip>

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.16.4.0/24    0.0.0.0                  0         32768 i

*> 172.16.5.0/24    0.0.0.0                  0         32768 i

*> 172.16.6.0/24    0.0.0.0                  0         32768 i

*> 172.16.7.0/24    0.0.0.0                  0         32768 i

Sources:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5441-aggregation.html#aggregatingwiththeassetargument