Networking-Blog

My WordPress Blog

CISCO BGP COMMUNITY

I’ve got a bit of confusion about how to prevent an eBGP peer from redistributing an announced route
to outside AS’s.

What I want to do is advertise a single route to an eBGP peer, and somehow ensure that they will
not advertise it to any of its external peers. (I don’t want them to become a transit for me).

Is this somewhat close to being correct?:

router bgp 14270
bgp log-neighbor-changes
network 208.70.104.0 mask 255.255.248.0
neighbor 208.70.111.70 remote-as xxxxx
neighbor 208.70.111.70 send-community
neighbor 208.70.111.70 prefix-list REMOTE-IN in
neighbor 208.70.111.70 route-map COMMUNITY out
neighbor 208.70.111.70 maximum-prefix 1
!
!
ip prefix-list REMOTE-IN seq 5 permit x.x.x.x/24
ip prefix-list REMOTE-IN seq 10 deny 0.0.0.0/0 le 32
!
ip prefix-list IPV4-OUT seq 5 permit 208.70.104.0/21
ip prefix-list IPV4-OUT seq 10 deny 0.0.0.0/0 le 32
!
route-map COMMUNITY permit 10
match ip address IPV4-OUT
set community no-export 

ROUTE_REFLECT_OUT

router bgp 34790
bgp router-id 80.74.16.119
bgp log-neighbor-changes
network 85.234.89.128/26
redistribute static route-map WW-LON-RS0-OUT
neighbor 80.74.16.174 remote-as 34790
neighbor 80.74.16.174 description ww-lon-rs0
neighbor 80.74.16.174 update-source eth0
neighbor 80.74.16.174 next-hop-self
neighbor 80.74.16.174 soft-reconfiguration inbound
neighbor 80.74.16.174 maximum-prefix 20
neighbor 80.74.16.174 route-map WW-LON-RS0-OUT out
!
ip route 10.171.5.0/24 10.200.0.1
ip route 10.171.8.0/24 10.200.0.1
ip route 10.171.17.0/24 10.200.0.1
ip route 10.171.31.0/24 10.200.0.1
ip route 10.171.40.0/24 10.200.0.1
ip route 85.234.89.129/32 10.200.0.1
ip route 85.234.89.133/32 10.200.0.1
ip route 85.234.89.136/32 10.200.0.1
ip route 85.234.89.144/32 10.200.0.1
ip route 85.234.89.162/32 10.200.0.1
!
ip prefix-list ROUTE_REFLECT_OUT seq 5 permit 85.234.89.162/32
ip prefix-list ROUTE_REFLECT_OUT seq 10 permit 85.234.89.133/32
ip prefix-list ROUTE_REFLECT_OUT seq 15 permit 85.234.89.136/32
ip prefix-list ROUTE_REFLECT_OUT seq 20 permit 85.234.89.144/32
ip prefix-list ROUTE_REFLECT_OUT seq 25 permit 85.234.89.129/32
!
route-map WW-LON-RS0-OUT permit 10
match ip address prefix-list ROUTE_REFLECT_OUT
!
ip forwarding
!

CISCO – IBGP vs EBGP

Lab Challenge IBGP vs EBGP :

R1/2/3/4 establish internal routing using OSPF.

R1 & R4 are to be set within IBGP using AS 5500. Establish peering & advertise there internal loopback
addresses. R4 & R5 establish connectivity and filter R5 loopback address over to R4 with Route-Maps.

 

R1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.12.1 255.255.255.252
!
interface FastEthernet1/0
ip address 10.1.13.1 255.255.255.252
!
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.1.12.0 0.0.0.3 area 0
network 10.1.13.0 0.0.0.3 area 0
!
router bgp 5500
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 5500
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

 

R2

interface FastEthernet0/0
ip address 10.1.12.2 255.255.255.252
!
interface FastEthernet1/0
ip address 10.1.24.1 255.255.255.252
!
router ospf 1
log-adjacency-changes
network 10.1.12.0 0.0.0.3 area 0
network 10.1.24.0 0.0.0.3 area 0

 

R3

interface FastEthernet0/0
ip address 10.1.13.2 255.255.255.252
!
router ospf 3
log-adjacency-changes
network 10.1.13.2 0.0.0.0 area 0

 

R4

interface Loopback4
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.24.2 255.255.255.252
!
interface FastEthernet1/0
ip address 10.1.45.1 255.255.255.252
!
router ospf 1
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 0
network 10.1.24.2 0.0.0.0 area 0
network 10.1.45.1 0.0.0.0 area 0
!
router bgp 5500
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 5500
neighbor 1.1.1.1 update-source Loopback4
neighbor 5.5.5.5 remote-as 6500
neighbor 5.5.5.5 ebgp-multihop 3
neighbor 5.5.5.5 update-source Loopback4
no auto-summary
!
ip classless
ip route 5.5.5.5 255.255.255.255 10.1.45.2

 

R5

interface Loopback1
ip address 200.1.1.1 255.255.255.0
!
interface Loopback2
ip address 200.1.2.1 255.255.255.0
!
interface Loopback3
ip address 200.1.3.1 255.255.255.0
!
interface Loopback4
ip address 200.1.4.1 255.255.255.0
!
interface Loopback5
ip address 5.5.5.5 255.255.255.255
!
interface Loopback6
ip address 200.1.6.1 255.255.255.0
!
interface Loopback50
ip address 50.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.45.2 255.255.255.252
!
router bgp 6500
no synchronization
bgp log-neighbor-changes
network 50.1.1.0 mask 255.255.255.0
redistribute connected route-map FILTER
neighbor 4.4.4.4 remote-as 5500
neighbor 4.4.4.4 ebgp-multihop 3
neighbor 4.4.4.4 update-source Loopback5
no auto-summary
!
ip classless
ip route 4.4.4.4 255.255.255.255 10.1.45.1
!
!
ip access-list standard REDISTRIBUTE
permit 200.1.1.0
permit 200.1.3.0
permit 200.1.2.0
deny 200.1.5.0
permit 200.1.4.0
deny 200.1.6.0
!
route-map FILTER permit 10
match ip address REDISTRIBUTE

BGP – Route-map filtering configuration

Using route-map, you can control in/outbound BGP announcement and apply various attributes :

router bgp 65535
network z.z.z.z
neighbor y.y.y.y remote-as 65500
neighbor y.y.y.y route-map ISP-out out
!
route-map ISP-out permit 10
match ip address 100
!
access-list 100 permit z.z.z.0 0.0.0.255

Recommended to use ip prefix-list since it is lower on cpu/memory resources :

ip prefix-list IPV4-OUT seq 5 permit z.z.z.0/21
ip prefix-list IPV4-OUT seq 10 deny 0.0.0.0/0 le 32
!
route-map ISP-out permit 10
match ip address IPV4-OUT
!
neighbor y.y.y.y route-map ISP-out out

How to configure secure BGP?

How to configure secure BGP?

There are few ways to make robust BGP session. Keep it in your mind, ISP doesn’t provide all
below commands (Don’t wasting time). They would configure MD5 hash for your link. 

1. Using MD5 password

MD5 setting is common and easy to implement.

router bgp 300
neighbor x.x.x.x password cisco

How to hide private BGP ASN from ISP

We know how to change peer ASN without changing BGP processor ID which might be private ASN.
That is local-as commands is the one to replace ASN for outside of world. However, your BGP peer
keep on sending private ASN or current BGP processor ID. Here is the magic command to fix it. 

“neighbor x.x.x.x local-as yyy no-prepend replace-as“

CISCO – LAB CHALLENGE – BASIC BGP

Complete the following tasks:

– Configure R1 for basic BGP with ISP1 and ISP2. 
– Use the existing WAN IP addressing and provided ASNs 
– Advertise 10.1.3.0/24 to both providers equally
– Advertise 10.1.4.0/24 to both providers equally

 

R1 :

interface Loopback0
ip address 10.1.3.1 255.255.255.0
!
interface Loopback4
ip address 10.1.4.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.1.2.2 255.255.255.252
duplex auto
speed auto
!
router bgp 300
no synchronization
bgp log-neighbor-changes
network 10.1.3.0 mask 255.255.255.0
network 10.1.4.0 mask 255.255.255.0
neighbor 10.1.1.1 remote-as 100
neighbor 10.1.2.1 remote-as 200
no auto-summary
!
ip route 10.1.3.0 255.255.255.0 Null0
ip route 10.1.4.0 255.255.255.0 Null0

 

ISP1 :

interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.252
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 300
no auto-summary

 

ISP2 :

interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.252
!
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 10.1.2.2 remote-as 300
no auto-summary

 

CISCO – BGP ROUTING

CISCO BGP SUMMARY

I have seen static route pointing towards a null0 interface in BGP. Can I know why it is used for?

The static route to null 0 is needed to advertise networks into BGP,

BGP would advertise Networks using any of the bellow methods:

1– with the Network command set.
2– Redistribution into BGP.
3– Aggregate address command.

All of these methods needs an exact match in the routing table , except for the aggregation which
needs at least one route part of the aggregate address exist.

However, doesn’t need the (network command under bgp) as long as the aggregate address along with
one part of the aggregate address exist in the IP routing table.

EG :

ip route 196.196.1.0 255.255.255.0 Null0

router bgp myASN
network 196.196.1.0 mask 255.255.255.0

…

(((
modern way

router bgp myASN
aggregate-address 196.196.0.0 255.255.252.0 summary-only

))))

it is a way to create an aggregate = a summary route

 

Route Reflectors

Another solution for the explosion of iBGP peering within an AS is Route Reflectors (RRs).
As the iBGP section demonstrates, a BGP speaker does not advertise a route that the BGP speaker
learned via another iBGP speaker to a third iBGP speaker.
You can relax this restriction a bit and provide additional control, which allows a router to
advertise, or reflect, iBGP learned routes to other iBGP speakers. This route reflection reduces the
number of iBGP peers within an AS.

neighbor route-reflector-client

The router with this command is the RR, and the neighbors at which the command points are
the clients of that RR.

 

Tuning BGP Transport

Tuning BGP transport mechanism is a very important factor for improving BGP performance in
the cases where purely BGP-based re-convergence process is in use. TCP is the underlying transport
used for propagating BGP UPDATE messages,and optimizing TCP performance directly benefits BGP.

If you take the full Internet routing table, which is above 300k prefixes (Y2010), then simply transporting
the prefixes alone will consume over 10 Megabytes, not to count the path attributes and other
information. Tuning TCP transport performance includes the following:

Enabling TCP Path MTU discovery for every neighbor, to allow the TCP selecting optimum MSS size.
Notice that this requires that no firewall blocks the ICMP unreachable messages used during the
discovery process Tuning the router’s ingress queue size to allow for successful absorption of large
amount of TCP ACK messages. When a router starts replicating BGP UPDATES to its peers, every peer
responds with TCP ACK message to normally every second segment sent (TCP Delayed ACK).
The more peers router has, the higher will be the pressure on the ingress queue.

Cisco OSPF Summary

Configuring OSPF on a Cisco router

router(config)#router ospf 1
router(config-router)#network 10.130.0.0 0.0.255.255 area 130

The command turns on the OSPF routing protocol with a process id of 1.
The network line must be added to tell the router which networks will be
participating in OSPF.

This command can be expanded to include stub areas and not so stubby areas.
That is how Cisco refers to it. You can run multiple processes of OSPF using
different
process ids.

Related commands:
show ip ospf neighbor
show ip ospf interface

Router-Id

The OSPF router-id will be, in order:

The one configured by the router-id command, if available and configured.
The highest IP loopback interface when OSPF starts, if a loopback exists.
The highest IP on a non-loopback interface.

Objectives :

1. Configure OSPF. R1 will act as an ASBR by redirecting a series of static routes
into the OSPF network. These Routes should NOT increment their metrics as they
pass through the network and should have an intial
OSPF cost of 200
.

All routers should have a router-id reflecting their hostname, you should be able to
ping this router-id throughout the entire OSPF network.

R1:

router ospf 1
network 172.16.30.1 0.0.0.0 areaO
router i.d 1.1.1.1
redistribute static subnets metric 200 metric-type 2

!

E1 routes increase their metrics.
E2 is default and do not increment their metrics.

!
!

R2:

router ospf 1
network 172.16.31.2 0.0.0.0 areaO
router i.d 2.2.2.2

!
!

Router-id should be set before configuring routing protocol network.
If Router-id is set after configuring routing protocol then router interface
ip address would take precedence.

For router-id the take precedence . run this command to clear the OSPF process :

clear ip ospf process

!

int loopback 1
ip address 10.10.0.1 255.255.25.0
ip ospf network point-to-point

Router OSPF will advertise a /32 loopback 1 since it will see it a /32 due to being
a loopback interface.

ip ospf network point-to-point will see it as a real network /24

BGP Communities

The only mechanism to set BGP community in Cisco IOS is the set community command
in a route-map.

BGP has default 4 well known communities that can be used to mark prefixes; listed as follows :

  • Internet: advertise these routes to all neighbors.
  • Local-as: prevent sending routes outside the local As within the confederation.
  • No-Advertise: do not advertise this route to any peer, internal or external.
  • No-Export: do not advertise this route to external BGP peers.

To implement communities we have to follow this process :
!
  • First need to identify traffic and policies for traffic.
  • Then we have to define a community and apply to particular prefixes by using route-maps.
  • Then configure neighbor ip address send community for particular neighbors.
  • As the routing update will received by other neighbors, that time router will look the associated
    community and on the basis of that policy will be applied.
Processing of Communities :
!
  • Prefixes are tagged with route-map with defined community values.
  • Prefixes are advertised with communities to neighbors.
  • As neighboring router will see the route associated with community, it will apply policies as
    per configurations. Ex: Community 100:10 will say that the local preference of route should be
    lowered to 50 as per configured policy.
Configuration Steps of BGP communities :
!
  • Configure communities and tag the prefixes using route-map.
  • Configure BGP community advertisement to particular neighbors. Since communities will be not
    advertised to all neighbors with updates
  • Configure BGP community access-lists to match BGP communities on receiving routers.
  • Configure route-maps and define policies for particular receiving communities as per requirement.
  • Apply the route-map to incoming or outgoing updates.

The BGP communities are transitive BGP attribute, meaning that they should be propagated to
all BGP neighbors.

Why using BGP communities?

Communities can be used to mark a set of prefixes that share a common property.
Upstream providers can use these marks to apply a common routing policy such as filtering or assigning
a specific local preference.

As a service provider you can make an agreement with your customers on a specific policy to be
applied to their prefixes using communities; this gives your customers the freedom to change the policy
of a prefix just by changing the community attribute value with no support from your side.

Using BGP communities to influence routing :

Our service provider, AS 65001, allows us to use the communities attribute of BGP to influence
how they route our traffic. In this (simplified) example, there are three different communities
we can use:

  • 200: set local preference to 200
  • 500: set local preference to 500


!
We are the customer (AS 65065) and R1 is our router. We are multi-homed to our service provider
(AS 65001) with a 100 Mbit/s connection to R2 and a T-1 connection to R3.
R2 and R3 are connected over a 100 Mbit/s connection as well.

If we send routes to AS 65001 with a community of 65001:200, the SP’s routers will set the
local preference on those routes to 200.

If we send routes to AS 65001 with a community of 65001:500, the SP’s routers will set the
local preference on those routes to 500. How handy is that?

Because of how the BGP best path selection algorithm works, we want our SP’s routers to assign a higher
local preference to the routes it receives from us over that 100 Mbit/s connection, so we’ll send
those routes with a community of 65001:500.

Just for good measure, we’ll attach community 65001:200 to the routers
we send to 172.16.13.3 over the T-1 connection as well.

Let’s go ahead and set up BGP, but don’t start advertising any routes just yet :

R1(config)# ip bgp-community new-format
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 next-hop-self
R1(config-router)# neighbor 172.16.12.2 send-community
R1(config-router)# neighbor 172.16.13.3 remote-as 65001
R1(config-router)# neighbor 172.16.13.3 next-hop-self
R1(config-router)# neighbor 172.16.13.3 send-community

We are all set to begin advertising our routes, with the appropriate communities attached.

The next thing we need to do is create a pair of route maps. We’ll apply these route maps outbound to the
BGP peers and these are what we will use to attach our communities to the routes:

R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500

Lookin’ good so far, right? Let’s apply those route map to our BGP peers :

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# neighbor 172.16.13.3 route-map LOCAL_PREF_200 out

That was easy enough. Now, let’s advertise those loopbacks :

R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0

Let’s take a look at how the SP sees our routes :

R2# sh ip bgp | in 65065
*> 172.31.0.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    500      0 65065 i
R3# sh ip bgp | in 65065
*>i172.31.0.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.1.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.2.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.3.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i

If we ping/traceroute from R3 to one of R1′s loopbacks, we should see that traffic first passes to
R2 before being sent to R1 (which is our goal):

R3# ping 172.31.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/36 ms
R3# traceroute 172.31.0.1

Type escape sequence to abort.
Tracing the route to 172.31.0.1

  1 172.16.23.2 4 msec 12 msec 16 msec
  2 172.16.12.1 16 msec *  32 msec

Success !

Suppose you want router Albany to set metrics for routes that it forwards to router Boston based
on the communities to which the routes belong
. You can create community lists and filter the routes
with a route map that matches on the community list.

To configure router Albany :

host1(config)#router bgp 293
host1(config-router)#neighbor 10.5.5.2 remote-as 32
host1(config-router)#neighbor 10.2.2.1 remote-as 451
host1(config-router)#neighbor 10.2.2.4 remote-as 17
host1(config-router)#neighbor 10.2.2.4 route-map commtrc out
!
host1(config)#route-map commtrc permit 1
host1(config-route-map)#match community 1
host1(config-route-map)#set metric 20
!
host1(config)#route-map commtrc permit 2
host1(config-route-map)#match community 2
host1(config-route-map)#set metric 75
!
host1(config)#route-map commtrc permit 3
host1(config-route-map)#match community 3
host1(config-route-map)#set metric 85
!
host1(config)#ip community-list 1 permit 25
host1(config)#ip community-list 2 permit 62
host1(config)#ip community-list 3 permit internet

Show commands for monitoring  Communities :
!
Show ip bgp prefix
Show ip bgp community – display all community associated routes
Show ip bgp community as:nn – display the particular prefixes with that community.
Show ip bgp community-list – display community list.