Pages

CCNP Route: BGP Lab - eBGP, iBGP, next-hop-self, update-source, communities

Lab from http://www.digitaltut.com/bgp-next-hop-self-community-no-export-send-community-gns3-lab

Resolved Lab in GNS3 https://db.tt/i8MsBZ9S

Aliases used
conf t
alias exec rou sh run | s router
alias exec ro sh run | s router
alias exec router sh run | s router
alias exec bgp sh ip bgp | beg Network
alias exec bgps sh ip bgp summary | beg Neighbor
BGP session establishment
R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 12.12.12.1 255.255.255.0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
! We do have 1.1.1.0/24 in RIB so we could annouce route with network command
 network 1.1.1.0 mask 255.255.255.0
 neighbor 12.12.12.2 remote-as 23
! loopback IP address as source for BGP session
 neighbor 12.12.12.2 update-source Loopback0
 no auto-summary
!
R2
!
interface FastEthernet0/0
 ip address 12.12.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 23.23.23.2 255.255.255.0
!
! We need to know how to reach 1.1.1.1 address as we dont have this route is local RIB
ip route 1.1.1.1 255.255.255.255 FastEthernet0/0
!
router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
! Neighbor 1.1.1.1 is 2 hops away (as its loopback interface), so we need multihop
 neighbor 1.1.1.1 ebgp-multihop 100
 neighbor 23.23.23.3 remote-as 23
 no auto-summary
!
R3
!
interface FastEthernet0/0
 ip address 34.34.34.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 23.23.23.3 255.255.255.0
!
router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 23.23.23.2 remote-as 23
 neighbor 34.34.34.4 remote-as 4
 no auto-summary
!
 R4
!
interface FastEthernet0/0
 ip address 34.34.34.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 23.23.23.3 255.255.255.0
!
router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 23.23.23.2 remote-as 23
 neighbor 34.34.34.4 remote-as 4
 no auto-summary
!

Basic Verification

! R1 knows about 1.1.1.0/24 via Locally originated (next-hop = 0.0.0.0)
R1#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i

! R2 knows about 1.1.1.0/24 via eBGP
R2#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       1.1.1.1                  0             0 1 i
! R3 knows about 1.1.1.0/24 via iBGP from iBGP session, but is is not used because it's inaccessable (next-hop not valid)
R3#bgp
   Network          Next Hop            Metric LocPrf Weight Path
* i1.1.1.0/24       1.1.1.1                  0    100      0 1 i
R3#sh ip bgp 1.1.1.0
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (1 available, no best path)
  Not advertised to any peer
  1
    1.1.1.1 (inaccessible) from 23.23.23.2 (23.23.23.2)
      Origin IGP, metric 0, localpref 100, valid, internal
R3#sh ip route 1.1.1.1
% Network not in table

! R4 does not know 1.1.1.0/24, because R3 doesnot announce it
R4#bgp
----none----
BGP next-hop-self
To resolv this issue, there a solutions:
1) on R2 use “next-hop-self” option (R2 will send its own IP address as the next hop instead of sending the EBGP next hop)
R2(config-router)#neighbor 23.23.23.3 next-hop-self
R3#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.0/24       23.23.23.2               0    100      0 1 i
2)  Or R2 use "redistribute static" in BGP, with static route added to R1's loopback interface, BUT we loose AS_PATH (1.1.1.1 will be originated locally)
R2(config-router)#redistribute static

R3#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.0/24       1.1.1.1                  0    100      0 1 i
*>i1.1.1.1/32       23.23.23.2               0    100      0    <- AS_Path lost, because its locally originated
Anyway, in both cases ping to 1.1.1.1 fails, because R2 didnt announce any networks to eBGP neighbor (R1 does not know how to reach R3)
R3#ping 1.1.1.1
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
..
R3# debug ip icmp
R3#traceroute 1.1.1.1 num
Tracing the route to 1.1.1.1
  1 23.23.23.2 16 msec 16 msec 24 msec
  2 * * *
Apr 28 13:54:02.051: ICMP: time exceeded rcvd from 23.23.23.2
Solution:
Make R2 announce connected routes to eBGP router (R1)
R2(config-router)#network 12.12.12.0 mask 255.255.255.0
R2(config-router)#network 23.23.23.0 mask 255.255.255.0
R1#sh ip bgp 23.23.23.0/24 lo
   Network          Next Hop            Metric LocPrf Weight Path
*> 23.23.23.0/24    12.12.12.2               0             0 23 i
OR
R2(config-router)# aggregate-address 23.23.0.0 255.255.192.0
! At least one route from aggregate 23.23.0.0/18 is needed in BGP topology (now is not presented as Connected exists in RIB), so lets add it
R2(config-router)# redistribute connected
R1#sh ip bgp 23.0.0.0/8 lo
   Network          Next Hop            Metric LocPrf Weight Path
*> 23.23.0.0/18     12.12.12.2               0             0 23 i
*> 23.23.23.0/24    12.12.12.2               0             0 23 ?

! To announce network 23.23.23.0 without mask option, static route to Null0 is needed, or BGP auto-summarization activated
R2(config-router)#ip route 23.23.23.0 255.255.255.0 null0
OR
 auto-summary
R2(config-router)#auto
R2(config-router)#network 23.0.0.0  
R2(config-router)#network 23.23.23.0   <-will not work

Now ping from R3 works:
R3#ping 1.1.1.1
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Make AS 23 not a transit AS
This is an important problem in real life. Suppose your company (with R2 & R3 routers) wants the connection to the Internet must be available in any time so your administrators hired two internet lines from two separate ISPs (R1 & R4). But improper configuration can make traffic flow from R1 -> R2 -> R3 -> R4 and your company becomes a transit AS. Surely your company does not want to receive this traffic as it takes much bandwidth of the company. We need to filter out this type of traffic.

The purpose of this task is opposite to task 2. We will make AS 23 not a transit AS by not advertising network 1.1.1.0 to R4. To do this, we will create a route-map for 1.1.1.0/24 and set the “no-export” attribute to this route.

R4 before any changes
R4#bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       34.34.34.3                             0 23 1 i
*> 12.12.12.0/24    34.34.34.3                             0 23 i
*> 23.23.0.0/18     34.34.34.3                             0 23 i
*> 23.23.23.0/24    34.34.34.3                             0 23 ?

R3 apply community route-map on IN direction (BEFORE R3 adds route to BGP topology)
! R3 route-map could be done both with ACL or Prefix-list
ip access-list extended ACLNOEXP
 permit ip 1.1.1.0 0.0.0.255 any
! OR
ip prefix-list PREFNOEXP seq 5 permit 1.1.1.0/24
!
route-map MAPNOEXP permit 10
 match ip address ACLNOEXP
 set community no-export
route-map MAPNOEXP permit 20
!
router bgp 23
 neighbor 23.23.23.2 route-map MAPNOEXP in
!
R3#sh ip bgp 1.1.1.0
  Not advertised to any peer
  1
    23.23.23.2 from 23.23.23.2 (23.23.23.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export
R4#sh ip bgp 1.1.1.0
% Network not in table
Appliyng route-map to out (on R3 to R4) will not work, as routes are not tagged with communities in BGP topology in R3, but on R4 istead.
ip access-list extended ACLNOEXP
 permit ip 1.1.1.0 0.0.0.255 any
!
ip prefix-list PREFNOEXP seq 5 permit 1.1.1.0/24
!
route-map MAPNOEXP permit 10
 match ip address ACLNOEXP
 set community no-export
route-map MAPNOEXP permit 20
!
! R4 will receive routes, but will not announce to anyone because no-export community set
! We need to activate community sending, which is by default not enabled
R3#  neighbor 34.34.34.4 send-community both
R4#sh ip bgp 1.1.1.0
  Not advertised to any peer
  23 1
    34.34.34.3 from 34.34.34.3 (34.34.34.3)
      Origin IGP, localpref 100, valid, external, best
      Community: no-export

No-export means, do not export to any eBGP neighbor.
No-advertise means, do not export to any BGP neighbor at all.
You can use send-community on both iBGP and eBGP. Without it no communities will be sent.

NO-EXPORT is commonly used within an AS to instruct routers not to export a prefix to eBGP neighbors. For instance, subnets of a larger block can be advertised to influence external AS best-path selection, and those not required for this traffic engineering purpose may be tagged NO-EXPORT to prevent them from being leaked to the Internet (and thus contributing to unnecessary global routing table growth). If a neighboring AS accepts this community, it can be used to selectively leak more specifics for traffic engineering but limit their propagation to just one AS.

NO-ADVERTISE instructs a BGP-speaking router not to send the tagged prefix to any other neighbor, including other iBGP routers.