BGP Basics

-









Inbound path 

Neighbor → IN policy -> RIB-IN → best-path-selection→ LOC-RIB → Routing Table

Outbound path 

LOC-RIB → OUT policy->Update-generation -> RIB-OUT(per neighbor) → Neighbor


1.Attributes
Optional = may or may not exist
Non-Transitive = “don’t carry forward if you don’t understand”

Real Example
MED (Multi Exit Discriminator) → Optional Non-Transitive
If a router doesn’t support MED: It gets removed at that hop (old routers may not support MED,RR)

** origin attributes carried on BGP updates (i,? info)
** MED is compared when routes coming from same AS by default. we can override by 'always compare MED' option




iBGP & eBGP what attributes will change


R1------eBGP-------R2--------iBGP---------R3


From eBGP → iBGP, R2 sends the following attributes to R3:

AS_PATH → unchanged  (note:-if a route originates within AS. then its EMPTY)

NEXT_HOP → unchanged (R1’s IP)

LOCAL_PREF → added by R2

ORIGIN → carried

MED → carried

COMMUNITIES → carried

Atomic Aggregate / Aggregator → carried

Only LOCAL_PREF is added. Nothing else is modified.


From R2 (iBGP) → R1 (eBGP):

R2 inserts its AS in AS_PATH

R2 sets NEXT_HOP to itself

Local Preference is removed

MED, ORIGIN, Communities, Aggregator attributes are carried normally



BGP policy & control tool

** Prefix-lists decide what, route-maps decide how, and BGP attributes decide which path wins.


CategoryPolicy ToolUsed ForWhere Applied
Prefix ControlPrefix-listFast, scalable prefix filteringInbound / Outbound
Distribute-listBasic filtering (older method)Inbound (mostly IGP/BGP)
ACLLegacy match (less flexible than prefix-list)Inbound / Redistribution
Route-filterAdvanced prefix matching (Juniper style)Policy framework
RPKIValidate route legitimacy (origin validation)Inbound
Maximum-prefixProtect against route leaksNeighbor-level
Attribute ControlRoute-mapModify attributes (LP, MED, AS-path, etc.)Inbound / Outbound
Policy-statementModern structured policy (Junos equivalent)Inbound / Outbound
BGP CommunityTag routes for policy decisionsBoth
Extended CommunityMPLS VPN / EVPN controlBoth
Local PreferenceInfluence outbound traffic (inside AS)Inbound
MEDInfluence inbound traffic (between ASes)Outbound
AS-Path prependTraffic engineering (make path less preferred)Outbound
Next-hop selfEnsure reachability in iBGPOutbound
AS ControlAS-Path filterLoop prevention / path-based filteringInbound / Outbound
Allowas-inAccept own AS (special cases)Inbound
Remove-private-ASClean private AS numbersOutbound
RedistributionRoute tagPrevent routing loops during redistributionIGP ↔ BGP boundary
Route-map (again)Control what gets redistributedRedistribution
Traffic SteeringPBR (Policy-Based Routing)Override routing table decisionData plane (not BGP control)
BGP PIC / ECMPFast failover / load sharingForwarding plane

How a Route Reflector Works in This Flow

A Route Reflector DOES NOT change the BGP flow.
It only changes the advertisement rules, so iBGP clients can learn routes from each other.

Let’s break it down:

RR: Ingress Path (when RR receives a route from a client)

1. Client → RR (iBGP)

RR receives an update from a client.

2. RR RIB-IN

Route stored in RIB-IN.

3. Inbound policy on RR

RR applies inbound route-map / policy if configured.

4. Loc-RIB

RR puts the selected (best-path) into its Loc-RIB.

RR does not change NEXT-HOP for EVPN or iBGP unless configured.
For normal IPv4, RR keeps next-hop "unchanged by default".

RR: Egress Path (RR sending the route out)

RR checks route-reflector rules:

RR reflects the route to:

Learned fromRR sends toWhy
1.Client         All other Clients + Non-clients (iBGP)             Route reflection rule
2.Non-client       Only Clients             Route reflection rule
3.eBGP       Both Clients + Non-clients              Normal behavior

Then same steps continue:

RR Loc-RIB → Outbound Policy → RIB-OUT → BGP Update to neighbors


Detailed Flow on RR

1. RR receives a route from a client
C1 → RR

2. RR puts route in RIB-IN → inbound policy → Loc-RIB

3. RR decides to reflect it (because it was learned from a client)

At this moment, RR injects:
ORIGINATOR-ID: C1's router ID (if not already present)
CLUSTER-LIST: RR’s own cluster ID appended to list

4. THEN outbound-policy is applied
Outbound policy can still:
change next-hop (if configured)
modify MED, LP, community, etc.

BUT cannot control or stop:
ORIGINATOR-ID insertion
CLUSTER-LIST update
These are protocol-mandated.

RR behavior depends on the source of the route

1.If the RR RECEIVES a route from a client
RR will reflect it to:   All other clients & All non-clients (iBGP peers)
AND it adds: Originator-ID & Cluster-List

2.If the RR RECEIVES a route from a non-client
RR will reflect it to: Only clients & NOT to other non-clients
(because that would violate iBGP loop prevention)
AND it adds: Cluster-List & Originator-ID (only if missing)

Cluster-List is always appended.

Multi-tier RRs, Nested RR clusters, RR hierarchy

Rule 1
An RR treats another RR as a normal client if configured as client.
Rule 2
Cluster-List grows at every RR hop (loop prevention)
Rule 3
Originator-ID stays the same unless the route originated on that RR.
Rule 4
Reflection logic remains consistent regardless of the device type
(Client route = reflect to all;
Non-client route = reflect only to clients)



AttributeApplied        Used by
LOCAL_PREF                   Inbound            Your AS
MEDOutbound            Neighbor AS
AS-PATH prependOutbound             Internet
Weight (Cisco)Inbound            Local router
 
**
MED- when you have 2 ebgp neighbors to same ISP & want to influence incoming traffic then use MED (lower the better)  


Route Refresh is only for inbound policy changes.
There is NO route-refresh equivalent for outbound changes.

#hard-rest vs soft-reset vs route-refresh

ActionSessionTCPRoute exchange
Hard resetDown / UpResetFull re-advertise
Soft reset (in)Stays upNoRe-evaluate routes
Soft reset (out)Stays upNoRe-send routes
Route RefreshStays upNoAsk peer to re-send

soft-reset-in

What it does

  • Re-applies inbound policy

  • Uses stored Adj-RIB-In

  • No re-advertisement from peer

Requirement

👉 Router must store received routes

Downsides

❌ High memory usage
❌ Old-school method




Adj-RIB-In  →  Local-RIB (many paths)
                         ↓
                   Best Path only
                         ↓
                    Adj-RIB-Out  (we need to go for add-path for ecmp)

Comments

Post a Comment

Popular posts from this blog

gNMI_with_grafana on containerlabs

-
Image
  root@digi-oss:/home/labadmin/mohan/2jan26_grafana# cat sr_lab.clab.yml name: sr_lab topology:   nodes:     sr1 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr1.cfg}     sr2 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr2.cfg}     # gNMIc Collector     gnmic:       kind: linux       image: ghcr.io/openconfig/gnmic:latest       binds: [gnmic-config.yml:/app/gnmic-config.yml:ro]       cmd: "--config /app/gnmic-config.yml subscribe"     # Prometheus TSDB     prometheus:       kind: linux       image: prom/prometheus:latest       binds: [prometheus.yml:/etc/prometheus/prometheus.yml:ro]       ports: ["9090:9090"]     # Grafana Visualization     grafana:       kind: linux       image: grafa...
Read more

EVPN Route type-1 & type-4 in action

-
Image
 Route Type 1: Ethernet Auto-Discovery (A-D) A Type 1 route is advertised by a PE router on a per-Ethernet Segment Identifier (ESI) basis. It is triggered by the presence of a multihomed connection.  Purpose of Type 1 routes Aliasing:  In an all-active multihoming setup, a Type 1 route informs remote PE routers that an Ethernet segment is reachable via multiple PEs. This allows for load-balancing traffic to the same customer device over multiple paths. Fast convergence (Mass MAC Withdrawal):  If a local link to a multihomed customer device fails, the PE sends a withdrawal message for the Type 1 route. Remote PEs can then withdraw all MAC addresses associated with that Ethernet segment, instead of waiting for individual MAC withdrawals, which speeds up convergence. Split-horizon filtering:   The route carries an ESI label to prevent traffic loops in all-active mode. A PE router won't forward broadcast, unknown unicast, and multicast (BUM) traffic back to its sour...
Read more

Network Automation with ROBOT Framework

-
Image
  Folder-structure Scripts testcase_with_keywordsLibrary.robot *** Settings *** Documentation    Test Case With Keyword Resource         Resources/Keywords/common.robot Resource          Resources/Keywords/vxlanInstance.robot Test Setup        Open Connection Test Teardown    Close Connection *** Test Cases *** [Documentation] Step 1: Verify VXLAN Interface Status     VXLAN Interface Status [Documentation] Step 2: Verify VXLAN VNI to VLAN Mapping     VXLAN VNI to VLAN Mapping Resources/Keywords/common.robot *** Settings *** Documentation    Common Keyword Library Library          ../../Libraries/commonLib.py Variables        ../Variables/veosLeaf01.yaml *** Variables *** ${devType}         ${virtualBox}[vmType] ${ipAddr}          ${virtualBox}[vmManagement][hostIp] ${po...
Read more