BGP Part 2
Scalability Mechanisms
Private AS
16 bit number 65536 Private range [64512;65535] Extension - 32bit number Private range [4200000000; 4294967294]
Peer Groups
- for smaller configuration file
- for performance improvement
Neighbor inherit all of the peer-group staff and we even can give neighbor specific configuration, that peer group doesn’t have.
Configuration for peer group and then add neighbor to peer group
Dynamic Update Peer-Groups
Can be splited into two parts; Dynamic Update Peer-Groups are more efficeent then peer groups. And exclude each other (you can’t have both) Inheretance approach
- Session Templates
- Policy Templates
Session Templates
Anything relevant to the session timers; remote-as; update-source; ebgp-miltihop
template peer-session MYNAME
inherit peer-session MYOTHERNAME
remote-as 100
update-source 100
exit-peer-session
neighbor <ip address> inherit peer-session MYNAME
Policy Templates
Anything relevant to policy next-hop-self, distribute list, filter-list, route-map Inheritense is more flexible - inherit from up to 7 templates directly
template peer-policy MYNAME
inherit peer-policy MYOTHERNAME
next-hop-self
route-map MYMAP out
exit-peer-policy
neighbor <ip address> inherit peer-policy MYNAME
iBGP Scalability Issues
- iBGP split horizon (we will not advertise prefix that we get from iBGP)
- full-mesh for NH reachability, if we have many devices, it will make impact on perfomence
Route Reflectors
All devices consists in a cluster; there is 32bit cluster id on a route reflector; Other device RR Clients are completly unaware of configuration. Everything is done on RR, including 32 bit clustet id. The best practice for the cluster id is to pull it from a Router Id of RR.
Prefix advertisement that comes from route reflector client, RR will flood it to RR peers and it also sends it to it’s non RRC peers. Update from R4 will be available on the other devices and we don’t have full mesh :)
If non RR client will send an update, the RR will sent it to RR clients, but it will follow iBBP rule and will not send update to other iBGP non RR client. So we will need to have a peering beetween R1 and R2.
Configuration command:
neighbor <ip> route-reflector-client
Advanced Route Reflector Designs
The previous chapter showed one point failure. So we create second RR. There will be 2 clusters with 2 clusters id.
Another design is nested RR , but it can create loops (inter and intra, as RRC have no idea they in cluster, and if two RRC have peering session, loop can appear. So attributes Cluster_List and ORIG_id are used.
Confederations
Inside AS there are several private AS. And now we manipulating eBGP behavior, as we now have confederation eBGP peerings. They are not gonna follow to same rules as a standart eBGP. For outside world this would look like AS100. Next Hop behavior have to change.
- Next Hop doesn’t change.
- Local Preference is going to be maintained.
- The MED is going to be passed between confederations.
For loop prevention 2 new attributes are creates:
- AS_CONFED_SEQ
- AS_CONFED_SET
Configuring a Confederation
R1
router bgp 65501
bgp confederation identifier 100
bgp confederation peers 65503
neighbor 192.168.0.2 remote-as 65503
neighbor 192.168.0.2 update-source lo0
neighbor 192.168.0.2 ebgp-multihop 3
R2
router bgp 65503
bgp confederation identifier 100
bgp confederation peers 65501
neighbor 192.168.0.1 remote-as 65503
neighbor 192.168.0.1 update-source lo0
neighbor 192.168.0.1 ebgp-multihop 3
R3
router bgp 65503
bgp confederation identifier 100
neighbor 192.168.0.2 remote-as 65503
neighbor 192.168.0.2 update-source lo0
exit
ip route 172.16.3.0 255.255.255.0 null0
router bgp 65503
network 172.16.3.0 mask 255.255.255.0
Result:
BGP communities
- 32 bit identifier ;
- by attributes we identifier prefixes;
- 1 prefix can have many communities
Communities can be
- meaningful to 1 AS
- meaningful to a set of AS
Format
- older format
- Decimal 0 - 4294967200
- Hex - Ox0 - 0xffffffa0
- Newer format AA:NN , AA - AS number
Well-Known Communities
- No-export - prefixes are not gonna be advertised outside of AS; if we have non-export attribute associated with a prefix, prefix will not be advertised outside AS; exception: we can send this prefix with no-export attribute and our AS neighbor will not send it outside AS (we can influence other AS behavior)
- Local-AS - NEVER advertised to an eBGP peer
- No-advertise - no advertise to anyone (no iBGP, no eBGP), keep prefix only on local device
Extended Communities
- 64 bit value
- Type field - 1 octet - 8 bit
- Can be set to be transitive or non-transitive Example: common use is MPLS VPN RT (route-target) community
Configuring Communities (Do NOT FORGET send community)
On R4 we have prefixes that we configured on R1. The goal: to configure no-export (well-known community) so we will no longer see these prefixes on R4.
R1
ip prefix-list MYLIST permit 172.16.0.0/16 le 32
route-map COMM permit 10
match ip address prefix-list MYLIST
set community no export
route-map COMM permit 20
router bgp 100
neighbor 10.12.12.2 route-map COMM out
neighbor 10.12.12.2 send-community
clear ip bgp * soft out
but prefixes are still visible, cause we should send community on R3 too.