BGP

• Only EGP in major use today.
• Point-to-Poing Peering
• Application Level Protocol
• TCP (179)
• Path Vector (not metric)

BGP Path Attributes

• Well-Known, Mandatory (mandatory by RFC4271, will be included in every update)
  • AS-Path
  • Next-Hop
  • Origin Can be incomplete
• Well-Known, Discretionary (well-known: means industry standart, every router supports this attributes; Discretionary: means I am allowed not to use them; if I use then -> I pass them)
  • Local Preference
  • Atomic Aggregate
• Optional, Transitive (Optional: if you design software, you option add or not to add this attribute, you can also add proprietary attribute; Transitive: the attribute will be passed to another router)
  • Aggregator
  • Community
• Optional, Non-Transitive
  • MED (Metric)
  • Originator ID
  • Cluster

#show ip bgp

Loop Prevention Mechanism: AS-PATH Let the loop, as soon as it’s duplicated AS - the route will be dropped.

### The Origin Attribute (well-known, mandatory)

• attemt to record where from that prefic come from
• i - IGP (network command,
• e - EGP
• ? - incomplete

### The next-hop attribute (AS to AS, instead of router to touter logic) If next hop is unreachable, best past selection algorithm will not be applyed Is not changed inside iBGP, can result that we will not have route to the next-hop inside iBGP. solution: On edge iBGP router set: neighbor next-hop-self

### BGP Weight (Specific to Cisco) A number from 0 to 65 535 The higher vlaue - the higher preference Only on the router, information is not passed to any other router When a prefix is locally generated it will get value 32 768 weight, otherwise (if not locally generated) the default value is 0.

ex: a router have route to the prefix through 2 different as, you’ll need just to choose a higher weight value

BGP Neighbors

There are 2 types of neighbors

• EBGP (between diffent AS)
• iBGP (between the same AS, if there is a need to distribute some routes in our network from internet)

TCP - 179 Simple communications:

• OPEN - starts the session
• KEEPALIVE - maintains the session (doesn’t rely on tcp)
• UPDATE - take some time, cause lot’s updates are on the internet, shouldn’t react immediately
• NOTIFICATION - smth is broken, before to break the session
• (Route Refresh - not in the original standart, updating routes without affecting peering)

Neighbor can be not directly connected, can have neighbors on top of other routers. The more specific route beats everything. By getting some routes from iBGP we can choose more specific route.

Before creating neighborship, you put all kind of filters, so the neighbor will not mess your routes. Same from other side.

## BGP Header

• Marker field - deprecated, field with all 1, was made fore synchronization beetwen peers and authentication, still there if there is an old bgp device
• Length
• Type - indicates of what type of bgp message we are dealing with ** 1 - open ** 2 - update ** 3 - notification ** 4 - keepalive ** 5 - route refresh behavior

OPEN Message Format

• Version - we expect future versions of bgp
• My As
• Hold Time - 0 or at least 3 seconds, between two the lowest will be chossen
• BGP Identifier - bgp router id, distinguish your system uniquely in the bgp peering
• Optional Parameter Length
• Optional Parameters

BGP UPDATE Message Format

• Withdrawn routes length
• Withdrawn Routes
• Total Path Attribute Length
• Path Attributes
• NLRI

BGP Keepalive Message (just header, no data)

• Marker
• Length
• Type

BGP Notification Message

• Error Code - general type of error
• Error Subcode ex. 3 3 update message error, missing well-known attribute
• Data

## BGP Neighbor Relationship Process (6 states)

• Idle (neighbor configured, if stuck in idle chances are good that they can’t reach each other, all roads lead to idle)
• Connect ( trying to form TCP relationship, to check #show tcp br)
• Active (also tcp)
• OpenSent (BGP version, autonomous system is correct? , router id, passwords)
• OpenConfirm (the open message comes back)
• Established, number - represents how many prefixes it receives from other side, neighbor established

to check #show ip bgp summary

## BGP Best Path Algorithm , CISCO, BGP Decision path Attributes

1. WEIGTH (Cisco Proprietary) - higher is better (example if route comes from big net, I want to put higher weight on this route then from the smaller net, using route map) , as it’s chosen, will not look to other part of the list
2. Local Prefenrence - somethimg that travels through yours autonomous system
3. Locally Originated
4. Accumulated IGP (AIGP) - can take the metric of interior protocol
5. Shortest AS-PATH
6. Origin Type
7. Lowest multi-exit discriminator (MED/Metric)
8. eBGP over iBGP
9. Oldest route
10. Lowest Peer Router-Id
11. Lowesr Cluster List Length
12. Lowest Next Hop Address

## BGP Best Path Algorithm , Juniper, BGP Decision path

1. Highest Local Preference
2. Lowest IGP
3. Shortest AS-PATH
4. Lowest origin type
5. Lowest MED
6. Prefer Locally Originated
7. Prefer eBGP over iBGP
8. Lowest IGP metric to the BGP NEXT_HOP
9. Active Path
10. Primary Route
11. Lowest Router ID source
12. Minimum cluster lenght list
13. Lowest neighbor address

### Looking Glass Way to look at the global bgp table #show ip bgp routes detail

## eBGP Peerings Basic Configuration Requirements

• directly connected, ttl = 1 (only in basic config)
• live on the same subnet
• TCP ports (fiwerwalls should permit source or destination of 179)

Example: Cisco

As neighbor on the other side is not configured yet, it will fail.

/#u all (to turn off debug Foreign port 179

Example: Peering with ipv6 addresses, but sharing ipv4 nlri.

eBGP Juniper Configuration

/# show bgp group /# show bgp summary

iBGP Peerings

iBGP Split Horizon Rule

When we have an iBGP prefix, we will not pass this prefix on to another iBGP speaker. This rule forces us into full-mesh iBGP peerings.

Cisco iBGP example configuration

1. Configure iGP on all three devices
2. Configure iBGP on loopbacks

Juniper iBGP example configuration

#show config

eBGP multihop

If devices are not directly connected. There is one common condition

• same network, directly connected
• TTL = 1

But it doesn’t solve ttl problem Juniper

BGP Authentication

This will be displayed in clear text in your configuration, md5 authentication

service password encryption command

Logging neighbor state; router-id config

BGP network command

create ip route in ip route table, the classfull mask will be used

    int lo0
      ip address 1.1.1.1 255.0.0.0
   router bgp <AS>
   network 1.0.0.0

example without classfull mask

   int lo1
      ip address 11.11.11.1 255.255.255.0
   router bgp <AS>
   network 1.1.1.0 mask 255.255.255.0

to check result, AD for eBGP (CISCO) is showed 20:

   show ip bgp

BGP NLRI redistribution

In case of a redistribution the origin attribute value will be ‘?’ Example redistributing routes from eigrp

   router bgp <AS>
   redistribute eigrp <id>

BGP RIB Failure

Example: if we have same route from EIGRP and eBGP, route will be marked as ‘r - RIB failure’ in bgp table and will not be transfered to routing table to check the reason of the mark ‘r - RIB failure’

show ip bgp rib-failure

To cancel propagation of inactive prefix the command:

   router bgp <AS>
   bgp supress-inactive

BGP Synchronyzation (History)

Cisco automatically will generate commands

router bgp <AS>
  no synchronyzation
  bgp log-neighbor-changes
  no auto-summary

Syncronyzation rule: BGP speaker will not install prefix into the BGP table or advertise the prefix if there is no synchronizayion beetween IGP protocol and BGP.

No is not used, as we can use full mesh or RR.

BGP Juniper NLRI Advertisement

To check peerings

show bgp summary

check if we receive any bgp prefixes

show route protocol bgp

Juniper approach is policy based, set route from lo0.0 and

edit
edit policy-options policy-statement <NAME>
set term 1 from interface lo0.0
set term 1 then accept

show
term 1 {
    from interface lo0.0
    then accept;
}

tying to bgp config

top
set protocols bgp group EXTERNAL export BGPADV

edit protocols bgp
show
group EXTERNAL {
  type external;
  export BGPADV;
  peer-as 65111;
  neighbor 10.12.12.1
}

Using static routes in a multi-homed environment

If we have several provides and use static route to them it can cause

• inefficency ( wrong provider choosing, non-optimal routing
• assimetrics and etc.

iBGP

We have two routes here from R8. But traffic will go only through one, as all attrubutes are equel, but R2 has smaller router-id.

Advertising default route from R2

router bgp <as>
  neighbor 10.26.26.6 default-originate

Aggregation: aggregate-address, summary-only, as-set

The first way to aggregate: static route to null and network command; the second is on screenshots

If we’re doing aggregation on R2 without AS set for the networks on R1, then AS300 will be lost. For keeping we have ‘as-set’ option.

CISCO BGP Routing Policy Mechanism

RIB consists of 3 parts

1. Adj-RIB-IN
2. Local-RIB
3. Adj-RIB-OUT Can set incoming policy to prevent stuff from showing in table 1. And you can create an out policy to stop stuff from sending out. Record in Adj-RIB-IN we will consider as candidate prefixes to Local-RIB. They are updates that made up through our policy and gonna be analyzed for inclusion in Local-RIB. Once the are in Local-RIB, the will be considered for advertising.

This happens through 3 phases:

1. Degree of preference. Candidates are analyzed, example: if we have prefix from BGP and route in RIB from IGP, toute from BGP will not be inserted into RIB.
2. Once they are analyzed, we will have best route injection and loop prevention in RIB.

3. Routes are added and aggregation perform.

   BGP Best Path Selection Algorith is between Phase 1 and 2.

   Commands to check:

   show ip bgp
   show ip route
   show ip bgp neighbors <neighbor> advertised-route
   debug ip routing
   

R6
route-map RM-ORIGIN permit 10
set origin incomplete

We will be poisoning prefixes by this map. As incomplete attribute is worse then i,e.

router bgp 200
neighbot 10.26.26.2 route-map RM-origin in

All prefixes received from this neighbor will be poisoned. In R8 all prefixes will be removed and we will have second path through R7 available.

show ip bgp neighbor 10.26.26.2 policy detail

InQ and OutQ

Adj-RIB-IN ans Adj-RIB-OUT are not the physical tables that can be checked. Instead Cisco implements it’s behavior as InQ and Out Q. If we see numbers there means that smth has gone wrong and there is instability in Bgp infrastracture.

BGP Processes

show processes cpu | include BGP

• Scheduler
• Router
• I/O

• Scanner

  BGP I/O is responsible for moving prefixes into the Queu and out of the Queu. BGP Router - policy, best path decision and etc. BGP Scanner - changes: prefixes becomes unreacheble and need to be removed. Also validated prefixes in case of network commans or redistibute command.

  debug ip bgp events
  

  Scanner runs every 16 seconds by default.

  router bgp <as>
  bgp scan-time <5-60>
  

  

  Other BGP processes

  Depending on software or vendor there can be other bgp processes, that are unique. BMP server, event BGP BMP server stands for BGP Monitor Server Protocol. Monitoring of neighborship. NHT (Next Hop Tracker Service) Event - responds to things like new network state or a new redistribute state. Import Scanner - assists scanning process with things like labels, MPLS type environment. Open - process when we establish new peering.

  Table Version Concepts

  If we are running show ip bgp table, there is gonna be main BGP table version and routing table version. If there is an update, the version is incremented. We’ve the prefix to the router, the version of the bgp table has been increased. Critical number for the syncronyzation of the structures: bgp table and routing table. Also show how stable is bgp environment.

We can see version of the table for specific prefix entry.

Clear BGP session (Don’t do it in production)

If we create policy and neighborship has already been established, the policy will not be applyed.

clear ip bgp ?

Soft Reconfiguration

neighbor <neig> soft-reconfiguration inbound
or if any changes after first command in policy: 
clear ip bgp <neighbor> soft in

For outboung soft reconfiguration we don’t have to any neighbor manipulation, Soft recongiguration if we are doing it inbound we are creating little database of adjecencies in there and we are going to be consuming memmory in order to do it on the device. And this memmory consumption can be pretty ginomous. So Cisco wanted to implement it the way it wouldn’t take so much memmory. And this capabilities called route resresh.

Using Cisco vIRL AutoNetKit

To enter pre-configurations into a topology

Route Refresh

Only necessery one command, some device can not support route refresh though, that’s why we went through soft reconfiguration.

clear ip bgp <neighbor> soft in

Using Distribute list

R1 gets from R2 3 prefixes. We want to get only one prefix. Ditribute list uses access list.

conf t
access-list 1 permit 192.168.0.2 0.0.0.0
router bgp 1
address-family ipv4
neighbor 192.168.0.2 ditribute-list in
exit
clear ip bgp 192.168.0.2 soft in

Extending access-liss

Previously

All the same as in previous chapter If the prefix begins exactly 100.100 and if the prefix list is 16 bits or greater, we will permit the entry

access list 100 permit ip 100.100.0.0 0.0.255.255 255.255.0.0 0.0.255.255

Prefix List

Create a prefix list named MYLIST that permits 100.0.0.0 255.0.0.0 and masks that are 24 bits or longer.

ip prefix-list MYLIST permit 100.0.0.0/8 ge 24
router bgp 1
address-family ipv4
neighbor 192.168.0.2 prefix-list MYLIST in
clear ip bgp * soft

next example: accept all except 192.168.0.2/32 prefix

AS_PATH

The logic in AS_PATH is regular expression

^ start of string
$ end of string
[] range of characters
- used to specify range
() logical grouping
. any single character
* zero or more instances
+ one or more instances
? zero or more instances
_ coma, open or close brace, start or end of string, or space

Examples

.* anything
^$ locally originates routes (no as, empty
^100_ learning from AS100
_100$  originated in AS100
_100_       any instane of AS100
       directly connected as
^[0-9]+$

Deny evrything originated from As 300, else permit

conf t
ip access-path list <1-500> deny _300$
ip access-path list <1-500> permit .*
router bgp <as>
neighbor <neig> filter-list 1 in
clear ip bgp * soft

### Route Map if then else logic structure

route-map MP_SAMPLE permit 10
match ip address <number of access list>
set <smthing, for example origin>

LOCAL_PREF

Shared inside iBGP, not communicated to other autonomous systems Default values, higher is better. R5 is getting prefix from R3 and R4, but R4 has bigger local preference 110 > 100, so the answer will be send to R4.

We are going to manipulate local-preference inbound. Now there is no local preference value in the bgp table, so it’s default 100.

!!! don’t forget permit 20 to not deny other prefixes Results:

MED Attribute

We advertise prefixes from AS100 to AS200. And by using MED we can control which path will AS200 will use to get to these prefixes. Which exit point will they use. Two prefixes are being advertised. Using MED let’s select .3 as best path (currently .2 as router-id is lower) We are going to manipulate MED on R2 and R3. The lower MED is better.

Same on R3 with lower metric. Results:

AS_PATH Prepending

Before the best path through R3 AS300: Configuration Result (before/after)

---

<

Previous Post

Markdown Format File

>

Next Post

Hardware Networking