Monthly Archives: May 2014

BGP Basics – modifying attributes

The previous post in this series looked at the exchange of routes between BGP peers, and this post takes this a step further by looking at two BGP attributes that can be modified to influence how a router decides which routes to place in it’s routing table – WEIGHT and LOCAL PREFERENCE

Here’s our example network and initial BGP configs:

BGP Basics - Modifying Attributes

R1#sh run | s router 
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

R2#sh run | s router
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 4.4.4.4 remote-as 4
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0
 no auto-summary

R3#sh run | s router
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 network 192.168.3.0
 neighbor 1.1.1.1 remote-as 123
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 4.4.4.4 remote-as 4
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0
 no auto-summary

R4#sh run | s router
router bgp 4
 no synchronization
 bgp log-neighbor-changes
 network 192.168.4.0
 neighbor 2.2.2.2 remote-as 123
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 123
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

We can see that R1 has 2 valid paths to the 192.168.4.0/24 network and the best route (via R2) has been placed in it’s routing table:

R1#sh ip bgp
BGP table version is 4, 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
*>i192.168.4.0      2.2.2.2                  0    100      0 4 i
* i                 3.3.3.3                  0    100      0 4 i

R1#sh ip route bgp
B    192.168.4.0/24 [200/0] via 2.2.2.2, 00:05:48

WEIGHT

WEIGHT is an attribute local to the router it is configured on, and is set per neighbour. As we can see from R1′s BGP table above, the default value for WEIGHT is 0. In this example we’ll set R1′s WEIGHT attribute for R3 to 100 so that R3 becomes the preferred path to the 192.168.4.0/24 network:

R1(config)#router bgp 123               
R1(config-router)#neighbor 3.3.3.3 weight 100

Reset the peers to see the effect of this on R1′s BGP table:

R1#clear ip bgp *

R1#sh ip bgp      
BGP table version is 2, 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
*>i192.168.4.0      3.3.3.3                  0    100    100 4 i
* i                 2.2.2.2                  0    100      0 4 i

The Weight for R3 is now 100, so the best path is now via R3. R1 places this route in it’s routing table:

R1#sh ip route bgp
B    192.168.4.0/24 [200/0] via 3.3.3.3, 00:00:14

LOCAL PREFERENCE

This can be advertised from a router to other routers within same (local) AS, and has a value of 100 by default. In this example we’ll configure a local preference on R3 of 200, to achieve the same end result as before.

First we’ll remove the WEIGHT config from the first example:

R1(config)#router bgp 123
R1(config-router)#no neighbor 3.3.3.3 weight 100
R1(config-router)#do clear ip bgp * 

Next, we’ll configure R3 so it has a LOCAL PREFERENCE of 200:

R3(config)#router bgp 123                  
R3(config-router)#bgp default local-preference 200
R3(config-router)#do clear bgp *

Remember that this attribute is local to the AS (123 in this case) so to verify this we can check R1′s bgp and routing tables:

R1#sh ip bgp      
BGP table version is 9, 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
*>i192.168.4.0      3.3.3.3                  0    200      0 4 i

R1#sh ip route bgp
B    192.168.4.0/24 [200/0] via 3.3.3.3, 00:01:36

From the output above we can see that R1 now only has 1 valid and best path to 192.168.4.0/24, and it is via R3.

I hope this has been a useful explanation. Thanks for reading, and good luck with your CCNP studies!

Rich

Follow Rich on Twitter

BGP Basics – advertising networks into BGP

The first post in this BGP mini-series looked at setting up BGP peering between routers. Now we’ll take things a step further and actually exchange some routing information between those peers. Here’s the network:
bgp basics - exchanging routes

The basic BGP config on each router looks like this:

R1#sh run | s router
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 23
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 23
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

R2#sh run | s router
router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 23
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

R3#sh run | s router
router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2.2.2.2 remote-as 23
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

We’ve now got peering between all three routers, but no routes are being learned yet via BGP. So far only static and connected routes are shown in the routing tables and we can see this on R1:

R1#sh ip bgp neighbors | i BGP
BGP neighbor is 2.2.2.2,  remote AS 23 external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 05:17:02
  BGP table version 1, neighbor version 1/0
  External BGP neighbor may be up to 2 hops away.
BGP neighbor is 3.3.3.3,  remote AS 23 external link
  BGP version 4, remote router ID 3.3.3.3
  BGP state = Established, up for 05:16:57
  BGP table version 1, neighbor version 1/0
  External BGP neighbor may be up to 2 hops away.

R1#sh ip route
{output omitted}

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 10.0.12.2
     3.0.0.0/32 is subnetted, 1 subnets
S       3.3.3.3 [1/0] via 10.0.13.3
     10.0.0.0/29 is subnetted, 2 subnets
C       10.0.12.0 is directly connected, FastEthernet0/0
C       10.0.13.0 is directly connected, FastEthernet1/0

There are two main methods of advertising routes into BGP – network statements and redistribution.

Network Statements

On R2 we will use a network statement to advertise the 192.168.2.0 /24 network into BGP (note that bgp network statements use subnet masks rather than wildcard masks):

R2(config)#router bgp 23
R2(config-router)#network 192.168.2.0 mask 255.255.255.0

If we check R1′s BGP table we see that it has learned of 192.168.2.0/24 route, also that the best route is via R2, and that the path is through AS23:

R1#sh ip bgp             
BGP table version is 36, 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
*  192.168.2.0      3.3.3.3                                0 23 i
*>                  2.2.2.2                  0             0 23 i

The best route is now also in R1′s routing table (note the administrative distance of 20 for external BGP):

R1#sh ip route bgp
B    192.168.2.0/24 [20/0] via 2.2.2.2, 00:25:55

Redistribution

On R3 we will redistribute connected networks so that we advertise the 192.168.3.0 /24 network into BGP:

R3(config)#router bgp 23         
R3(config-router)#redistribute connected

This works but is a little clumsy. We can now see the 192.168.3.0 /24 network in R1′s routing table, but we also see the 10.0.23.0 /29 transit network between R2 and R3:

R1#show ip route bgp
     10.0.0.0/29 is subnetted, 3 subnets
B       10.0.23.0 [20/0] via 3.3.3.3, 00:01:22
B    192.168.2.0/24 [20/0] via 2.2.2.2, 00:20:27
B    192.168.3.0/24 [20/0] via 3.3.3.3, 00:01:22

Plus we also get some RIB failure messages relating to R3′s other connected networks:

R1#sh ip bgp                                                       
BGP table version is 8, 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
r  3.3.3.3/32       2.2.2.2                                0 23 ?
r>                  3.3.3.3                  0             0 23 ?
r  10.0.13.0/29     2.2.2.2                                0 23 ?
r>                  3.3.3.3                  0             0 23 ?
*  10.0.23.0/29     2.2.2.2                                0 23 ?
*>                  3.3.3.3                  0             0 23 ?
*  192.168.2.0      3.3.3.3                                0 23 i
*>                  2.2.2.2                  0             0 23 i
*  192.168.3.0      2.2.2.2                                0 23 ?
*>                  3.3.3.3                  0             0 23 ?

This is because R1 already has a static route to 3.3.3.3/32 and is directly connected to 10.0.13.0/29.

To tidy this up we’ll filter routes using a route map that references an access list to match only the 192.168.3.0/24 network:

R3(config)#route-map R3RouteMap permit 10
R3(config-route-map)#match ip address 10

R3(config)#access-list 10 permit 192.168.3.0 0.0.0.255

R3(config)#router bgp 23 
R3(config-router)#redistribute connected route-map R3RouteMap

Now R1 only learns the route to 192.168.3.0/24 from R3, as the route map is preventing the other networks from being advertised:

R1#sh ip bgp
BGP table version is 17, 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
*  192.168.2.0      3.3.3.3                                0 23 i
*>                  2.2.2.2                  0             0 23 i
*  192.168.3.0      2.2.2.2                                0 23 ?
*>                  3.3.3.3                  0             0 23 ?
 

R1#sh ip route bgp
B    192.168.2.0/24 [20/0] via 2.2.2.2, 02:20:54
B    192.168.3.0/24 [20/0] via 3.3.3.3, 02:16:40

As well being less clumsy, this is much more like a real-world scenario where an ISP would be filtering the routes it advertises to a customer or vice versa.

I hope this has been a useful explanation. The next post in this series looks at modifying BGP attributes to inlfuence route selection.

Thanks for reading, and good luck with your CCNP studies!

Rich

Follow Rich on Twitter

BGP Basics – iBGP and eBGP peering

This is the first post in a mini-series on BGP basics, and looks at setting up internal and external BGP neighbours using loopback interfaces. The advantage loopbacks have over physical interfaces is that they are always up and reachable.

iBGP configuration:

ibgp peering

The routers must be able to reach each others loopback IP’s and we don’t have any dynamic routing protocols running yet, so we add static routes:

R1#sh run | i ip route
ip route 2.2.2.2 255.255.255.255 10.0.0.2

R2#sh run | i ip route 
ip route 1.1.1.1 255.255.255.255 10.0.0.1
R2#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms

Next, configure the BGP process on each router to use the same AS number, then specify the neighbour, and tell BGP to establish the TCP connection (BGP uses tcp/179) using the loopback 0 interface:

R1#sh run | s router 
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

R2#sh run | s router
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

Verify the configuration:

R1#show ip bgp neighbors | include BGP
BGP neighbor is 2.2.2.2,  remote AS 100, internal link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:04:10
  BGP table version 1, neighbor version 1/0

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   100       9       9        1    0    0 00:05:21        0

eBGP configuration:

ebgp peering

First, configure the BGP process on each router under the local AS number. Then configure the neighbour with the remote AS number, using loopbacks to connect:

R1#sh run | s router            
router bgp 111
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 222
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

R2#sh run | s router
router bgp 222
 no synchronization
 bgp log-neighbor-changesre 
 neighbor 1.1.1.1 remote-as 111
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

At this point we still don’t have established neighbours:

R2#sh ip bgp summary 
BGP router identifier 2.2.2.2, local AS number 222
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   111       0       0        0    0    0 never    Idle
 
R2#sh ip bgp neighbors | i BGP
BGP neighbor is 1.1.1.1,  remote AS 111, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Idle
  BGP table version 1, neighbor version 0/0
  External BGP neighbor not directly connected.

The reason for this is that eBGP neighbours using an interface that is not directly connected need an extra command that sets the TTL value for the packet to a value that allows it to reach the loopback interface (in this case 2 hops):

R1(config)#router bgp 111
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2

R2(config)#router bgp 222
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

Verify the configuration:

R1#sh ip bgp summary 
BGP router identifier 1.1.1.1, local AS number 111
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   222       8       8        1    0    0 00:04:10        0

R1#sh ip bgp neighbors | i BGP
BGP neighbor is 2.2.2.2,  remote AS 222, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:04:46
  BGP table version 1, neighbor version 1/0
  External BGP neighbor may be up to 2 hops away.

I hope this has been a useful explanation. The next post in this series looks at advertising networks into BGP.

Thanks for reading, and good luck with your CCNP studies!

Rich

Follow Rich on Twitter