This Document Describes The Use And Design Of A Method Known As "BGP Route Reflection (RFC 1966)".
QUICK RECAP OF BGP
BGP-1 Was First Defined In RFC 1105 In 1989, Then Was Updated With BGP-2 In 1990 With RFC 1163 Only To Updated Again To BGP-3 In 1991 With RFC 1267.
The Current Version Of BGP Is Known As Bgp-4 And Was Defined In RFC 1654, RFC 1655, RFC 1771 And RFC 1772. BGP-4 Was Different From Earlier Versions In One Main Respect And That Was It Became A Classless Routing Protocol And Thereby Supported CIDR. For Information On CIDR Have A Look At CIDR.
In BGP Terminology, An Independent Routing Domain (Which Almost Always Means An ISP) Is Called An Autonomous System.
BGP Is Always Used As The Routing Protocol Of Choice Between ISPs (External BGP) But Also As The Core Routing Protocol Within Large ISP Networks (Internal BGP).
BGP Is Considered To Be A 'Path Vector' Routing Protocol Rather Than A Distance Vector Routing Protocol Since It Utilises A List Of AS Numbers To Describe The Path That A Packet Should Take. This List Is Called The AS_PATH. Loops Are Prevented Because If A BGP Speaking Router Sees It's Own AS In The AS_PATH Of A Route It Rejects The Route.
A Router In A Transit AS May Have Extremely Large Routing Tables (Up To 90,000 Networks Amounting To Over 30Mb) And BGP-4 Uses Classless Interdomain Routing (CIDR) To Slow The Growth Of These Tables.
BGP's Basic Unit Of Routing Information Is The BGP Path, A Route To A Certain Set Of CIDR Prefixes. Paths Are Tagged With Various Path Attributes, Of Which The Most Important Are AS_PATH And NEXT_HOP.
External BGP (EBGP): Sessions Occur Between Routers In Different Ass Which Are Usually Next To Each Other Sharing The Same Media And Subnet.
Internal BGP (IBGP): Sessions Occur Between Routers Within The Same AS And These Sessions Are Used To Synchronise The Routing Policy Within An AS. These Routers Do Not Have To Be Next To Each Other However They Do Need To Be Able To See Each Other So That A TCP Connection Can Be Made Between Them! You Would Configure These If You Were Needing To Pass BGP Information To Other Ass.
IBGP AND EBGP ARE THE BASICALLY THE SAME ROUTING PROTOCOL JUST WITH DIFFERENT RULES AND APPLICATIONS:
EBGP Advertises Everything To Everyone By Default.
IBGP Does Not Advertise “3rd-Party Routes” To Other IBGP Peers.
This Is Because There Is No Way To Do Loop Detection With IBGP, So This Solves It. IBGP, By Default, Does Not Change The Next-Hop Address Attribute As Routes Traverse An IBGP Mesh. An IBGP Peer Will Not Advertise A Route Learned By One IBGP Peer To Another IBGP Peer. This Is A Readvertisement Restriction To Prevent Looping. Therefore, IBGP Should Be Used When AS_PATH Information Must Remain Intact Between Multiple EBGP Peers.
BGP-4: Uses TCP (Port 179) For Sending And Receiving Messages Reliably Between Peer Routers. (BGP Calls Routers Speakers, And Routers That Run Between Each Other Are Called Peers). The Reliable Connection Means That Only Changes Need To Be Sent Between Peers Rather Than Complete Tables. These Updates Can Be Triggered Updates Rather Than Periodic Updates. Only Keep Alive Messages Are Sent Regularly.
One Of BGP-4's Most Important Functions Is Loop Detection At The Autonomous System Level, Using The AS_PATH Attribute, A List Of Autonomous Systems Being Used For Data Transport.
The Syntax Of This Attribute Is Made More Complex By Its Need To Support Path Aggregation, When Multiple Paths Are Collapsed Into One To Simplify Further Route Advertisements. A Simplified View Of AS_PATH Is That It Is The List Of Autonomous Systems That A Route Goes Through To Reach Its Destination. Loops Are Detected And Avoided By Checking For Your Own AS Number In AS_PATH's Received From Neighboring Autonomous Systems.
Every Time A BGP Path Advertisement Crosses An Autonomous System Boundary, The NEXT_HOP Attribute Is Changed To The IP Address Of The Boundary Router. Conversely, As A BGP Path Advertisement Is Passed Among BGP Speakers In The Same AS, The NEXT_HOP Attribute Is Left Untouched. Consequently, BGP's NEXT_HOP Is Always The IP Address Of The First Router In The Next Autonomous System, Even Though This May Actually Be Several Hops Away. The AS's Interior Routing Protocol Is Responsible For Computing An Interior Route To Reach The BGP NEXT_HOP. This Leads To The Distinction Between Internal BGP (IBGP) Sessions (Between Routers In The Same AS) And External BGP (EBGP) Sessions (Between Routers In Different AS's). NEXT_Hops Are Only Changed Across EBGP Sessions, But Left Intact Across IBGP Sessions.
The Two Most Important Consequences Of This Design Are The Need For Interior Routing Protocols To Reach One Hop Beyond The AS Boundary, And For BGP Sessions To Be Fully Meshed Within An AS.
Since The NEXT_HOP Contains The IP Address Of A Router Interface In The Next Autonomous System, And This IP Address Is Used To Perform Routing, The Interior Routing Protocol Must Be Able To Route To This Address. This Means That Interior Routing Tables Must Include Entries One Hop Beyond The AS Boundary. Furthermore, Since BGP Does Not Relay Routing Traffic From One Interior BGP Session To Another (Only From An Exterior BGP Session To An IBGP Session Or Another EBGP Session), BGP Speakers Must Be Fully Meshed.
When A BGP Routing Update Is Received From A Neighboring AS, It Must Be Relayed Directly To All Other BGP Speakers In The AS. Do Not Expect To Relay BGP Paths From One Router, Through Another, To A Third, All Within The Same AS.
BGP Requires A Full Mesh Of Internal BGP Sessions (Sessions Between Routers In The Same Autonomous System). You Could Use BGP Route Reflectors Or BGP Confederations To Make Your Network Scalable.
BGP ROUTE REFLECTORS
Route Reflectors are defined in RFC 1966.
A Route Reflector (RR) Is A Network Routing Component. Its Offers An Alternative To The Logical Full-Mesh Requirement Of Internal Border Gateway Protocol (IBGP). Route Reflectors Is A Technique To Better Control The Deployment Of BGP Inside Of A Large AS. Route Reflectors Provide A Method To Reduce IBGP Mesh By Creating A Concentration Router To Act As A Focal Point For IBGP Sessions.
The Route Reflection Mechanism Relaxes The Rule That IBGP Updates May Not Be Sent To Other IBGP Speakers. Route Reflectors Send (Reflect) All Routes Learned Over IBGP To Their Clients. Thus, A Route Reflector Client Needs To Have An IBGP Connection Only To A Single Route Reflector, But It Still Receives The Best Route (As Determined By The Reflector) For Each Destination. A Cluster Of Route Reflector Clients May Be Served By More Than One Route Reflector, To Avoid Having A Single Point Of Failure. Route Reflection Has A Big Advantage Over Confederations: Only The Reflectors Have To Be Aware Of It. Clients And Nonclient (Regular) IBGP Neighbors Don't Have To Be Configured In A Special Way Or Do Anything Other Than Regular BGP Processing. Route Reflectors Are Often Used On A Per-Pop Basis, To Hide The Additional BGP Routers In The Pop From The Rest Of The Network.There Must Still Be A Full IBGP Mesh Between All Route Reflectors And Nonclient Peers.Also, Route Reflector Clients Must Know All Possible Next Hop Addresses, So They Have To Participate Fully In The IGP.
The Routers Acting As Route Reflector (RRs) Will Announce To Other IBGP Peers Whatever They Have Learned From Their IBGP Clients. So It’s Not Needed Any More To Build A Full-Mesh Topology. It’s Enough With Each Router Having An IBGP Session With The RR, Becoming Then Clients Of The RR.
An RR Acts As A Focal Point For IBGP Sessions. The Purpose Of The RR Is Concentration. Multiple BGP Routers Can Peer With A Central Point, The RR - Acting As A Route Reflector Server - Rather Than Peer With Every Other Router In A Full Mesh. All The Other IBGP Routers Become Route Reflector Clients.
The Concentration Router Is Called A Route Reflector Server. Routers Called Route Reflector Clients Only Have To Peer With The RR Server To Exchange Routing Information Between Themselves. The Route Reflector Server “Reflects” The Routes To Its Clients. This Means That The IBGP Re-Advertisement Restrictions Are Relaxed. It Is Possible To Arrange A Hierarchical Structure Of These Servers And Clients And Group Them Into What Is Known As Clusters.
BGP Requires That All BGP Peers In The Same Autonomous System Form An IBGP Session With All Peers In The Autonomous System. This Is Too Difficult In Many Environments. Route Reflectors Are Fully Functional IBGP Speakers That Form IBGP Sessions With Other IBGP Speakers, And They Also Perform A Second Function - They Forward Routes From Other IBGP Speakers To Route Reflector Clients. The Route Reflector Clients And Clients Form A Cluster.
NOTE :The Non-Client Peer Must Be Fully Meshed But The Client Peers Need Not Be Fully Meshed.
When An RR Receives A Route From An IBGP Peer, It Selects The Best Path Based On Its Path Selection Rule. After The Best Path Is Selected, It Must Do The Following Depending On The Type Of Peer It Is Receiving The Best Path From:
1) A Route From A Non-Client IBGP Peer :
Reflect To All The Clients.
2) A Route From A Client Peer :
Reflect To All The Non-Client Peers And Also To The Client Peers. (Hence The Client Peers Are Not Required To Be Fully Meshed.)
An Autonomous System Could Have Many RRs. An RR Treats Other RRs Just Like Any Other Internal BGP Speakers. An RR Could Be Configured To Have Other RRs In A Client Group Or Non-Client Group.
In A Simple Configuration, The Backbone Could Be Divided Into Many Clusters. Each RR Would Be Configured With Other RRs As Non-Client Peers (Thus All The RRs Will Be Fully Meshed). The Clients Will Be Configured To Maintain IBGP Session Only With The RR In Their Cluster. Due To Route Reflection, All The IBGP Speakers Will Receive Reflected Routing Information.
It Is Possible In An Autonomous System To Have BGP Speakers That Do Not Understand The Concept Of Route Reflectors (Let Us Call Them Conventional BGP Speakers). The Route Reflector Scheme Allows Such Conventional BGP Speakers To Coexist. Conventional BGP Speakers Could Be Members Of Either A Non-Client Group Or A Client Group.
This Allows For An Easy And Gradual Migration From The Current IBGP Model To The Route Reflection Model. One Could Start Creating Clusters By Configuring A Single Router As The Designated RR And Configuring Other Rrs And Their Clients As Normal IBGP Peers. Additional Clusters Can Be Created Gradually.
Usually, A Cluster Of Clients Will Have A Single RR. In That Case, The Cluster Will Be Identified By The BGP Identifier Of The RR. However, This Represents A Single Point Of Failure So To Make It Possible To Have Multiple RRs In The Same Cluster, All RRs In The Same Cluster Can Be Configured With A 4-Byte CLUSTER_ID So That An RR Can Discard Routes From Other RRs In The Same Cluster.
The BGP Protocol Provides No Way For A Client To Identify It Self Dynamically As A Client To An RR Configured BGP Speaker And The Simplest Way To Achieve This Is By Manual Configuration.
There Can Be Multiple Router Reflectors In The Same Cluster And At Different Levels. A Route Reflector Forms A Peering With The Other Non-Route Reflectors Called Clients And Forms A Cluster With Them. The Clients Are Not Peers With Each Other. Other IBGP Routers Not In The Cluster Are Called Non-Clients. The ORIGINATOR_ID Attribute Is Used To Identify The Router-Id Of The Route Reflector This Enables The Router To Determine Whether The Route Has Come From Itself In The First Place Thereby Preventing Loops. Another Way Of Preventing Loops Is By Use Of Cluster Lists. If You Want Multiple Route Reflectors For Resilience Then A CLUSTER_LIST Attribute Can Be Configured So That The Route Reflectors Recognise Each Other As Being Part Of The Same Cluster.
You Can Have Multiple Clusters As Well And A Route Reflector Can Determine Whether A Loop Exists By Looking For Its Own Cluster ID In The Cluster List Of The Advertisement. It Is Important That The Route Reflectors Themselves Are Fully Meshed.
You Can Have Multiple Route Reflectors Inside One AS And This Might Break The Normal AS Path Loop Prevention Mechanism. So Normally AS Path Takes Care Of Loop, But Inside The AS It’s Done With Cluster-Id And Originator-Id.
In BGP You Would Need A Full Mesh For All IBGP Client Peerings, To Have Routes Propagated From Client To Client. Route Reflection Overcomes The Need For A Full Mesh. The Route Reflector Reflects Routes Coming From A Client To His Route Reflector Clients.
Whatever Is Received From A Route-Reflector Client Or An External BGP Peer Will Be Sent To Every Other BGP Peer.
Whatever Is Received From A Router That Is Not A Route-Reflector Client Will Be Sent Only To Clients And External BGP Peers.
With These Rules In Hand, You Have To Step Through The Graph Of BGP Sessions In Your Network, Checking Every BGP Router On The Way And Ensuring That The Route Reflector Rules Are Not Violated (And That, Using The Rules, The BGP Prefixes Get From Every Edge Router To All Other Routers).
There Is Another Common Reason An IP Prefix Is Not Propagated Across Your Network: The External Subnets On The Edge Of Your Network Are Not Advertised To Your Core Routers.
The IP Address Of The Next-Hop Router Is Not Changed When An IP Prefix Is Sent To An Internal BGP Neighbor. The IP Next-Hop Of An External Route Is Thus Always The IP Address Of A Router One Hop Beyond The Edge Of Your Autonomous System. The IP Subnets Connecting Your Edge Routers To Their External Neighbors Thus Have To Be Inserted Into Your Internal Routing Protocol (For Example, OSPF Or IS-IS), Otherwise Some Internal BGP Router Will Decide That The BGP Next-Hop Is Not Reachable And Ignore The IP Prefix. (It Will Appear In The BGP Table But Will Not Be Used Or Propagated To Other BGP Peers.)
ALSO UNDERSTAND BGP CONFEDERATIONS
BGP Autonomous Systems With Fully-Meshed IBGP Peers You Can Divide Up The Routers Into Smaller Private (Member) Ass And Form A Confederation Of Private Ass That Come Together To Produce A Public AS As Far As The External Networks Are Concerned. Confederations Are Described In RFC 1965.
Reserved AS Numbers Used For Private Ass Are 64512 Through To 65535. These Numbers Should Therefore Be Used For The Internal AS Numbers. EBGP Peers In Each Private AS Peer With Each Other And The Whole Confederation Has A Confederation ID Which Is A Legitimate AS Number That External Ass See. The Confederation Structure Itself Is Invisible To The External Ass. Other Ass Connect Using The Confederation AS Number. Normally Next-Hop, Metric And Local Preference Information Is Not Passed Between EBGP Peers, However Within A Confederation This Information Is Shared.
In Order To Prevent Loops From Occurring The AS_PATH Has Two Versions, One Called The AS_CONFED_SEQUENCE That Is An Ordered List Of Ass That Are Internal To The Confederation, And The Other Called The AS_CONFED_SET That Is An Unordered List Of Ass.
NOTE :In Large Ass Confederations Can Be Used In Conjunction With Route Reflectors.
A Member Of A BGP Confederation Will Use Its AS Confederation ID In All Transactions With Peers That Are Not Members Of Its Confederation. This Confederation Identifier Is Considered To Be The "Externally Visible" AS Number And This Number Is Used In OPEN Messages And Advertised In The AS_PATH Attribute.
A Member Of A BGP Confederation Will Use Its Member AS Number In All Transactions With Peers That Are Members Of The Same Confederation As The Given Router.
A BGP Speaker Receiving An AS_PATH Attribute Containing An Autonomous System Matching Its Own Confederation Shall Treat The Path In The Same Fashion As If It Had Received A Path Containing Its Own AS Number.
A BGP Speaker Receiving An AS_PATH Attribute Containing An AS_CONFED_SEQUENCE Or AS_CONFED_SET Which Contains Its Own Member AS Number Shall Treat The Path In The Same Fashion As If It Had Received A Path Containing Its Own AS Number.
AS CONFEDERATION :
A Collection Of Autonomous Systems Advertised As A Single AS Number To BGP Speakers That Are Not Members Of The Confederation.
AS CONFEDERATION IDENTIFIER :
An Externally Visible Autonomous System Number That Identifies The Confederation As A Whole.
MEMBER-AS :
An Autonomous System That Is Contained In A Given AS Confederation. MEMBER-AS NUMBER :
An Autonomous System Number Visible Only Internal To A BGP Confederation.
DIFFERENCES BETWEEN BGP ROUTE REFLECTORS AND A BGP ROUTE CONFEDERATIONS
There Are Two Alternatives To The Full-Mesh BGP Topology, That Are :
BGP Route-Reflectors
And BGP Confederations
BGP CONFEDERATIONS :
With Confederations We Partition The Whole AS Network In Sub-AS, Without Needing To Build A Full-Mesh Topology Between All The BGP Routers Involved In The Network. Each Confederation, Or Sub-Autonomous System, Will Have A Full-Mesh BGP Topology Between The Routers Forming The Confederation. But Between Confederations, The Behaviour Will Be More Like EBGP Sessions With Some Differences (In Fact, It’s Called Confederation BGP, CBGP). Each Confederation Has A Different Sub-AS Number, Usually A Private One (From 64512 To 65534).
Confederations Are Another Method Of Solving The IBGP Full-Mesh Requirement. Confederations Are Smaller Sub-Autonomous Systems Created Within The Primary Autonomous System To Decrease The Number Of BGP Peer Connections.
BGP Confederation Is Breaking Up Your IBGP Domain Into Sub-Autonomous Systems To Change The Behavior Of How IBGP Works.
Confederations Are Another Method Of Reducing The IBGP Mesh Requirements. It Is A Technique To Subdivide A Single AS Into Multiple, Internal Sub-AS’s, Yet Still Advertise A Single AS To External Peers. Within Each Sub-AS (Confederated AS) The Normal Rules Of IBGP Meshing Still Apply, But EBGP Is Run Between The Confederated AS.
In A Confederation, The AS Is Split Into A Number Of Sub-ASes, So The IBGP Full Mesh Is Done Within Each Sub-AS And A Modified Version Of EBGP Is Used Between Sub-ASes. To The Outside, The Confederation Behaves Like A Single AS.
FIVE STEPS ARE USED IN THE CONFIGURATION OF CONFEDERATIONS :
1) Enable BGP Using The Member Autonomous System Number.
2) Configure The Confederation Identifier Using The BGP Confederation Identifier Command.
3) Configure Fully Meshed IBGP Sub-Autonomous System Neighbor Relationships Using The Sub-Autonomous System Number As The Remote Autonomous System Number (ASN) For All Internal IBGP Peers.
4) Configure Other Neighbors Within The Same Parent Autonomous System By Specifying Their Sub-Autonomous System Number As The Remote Autonomous System Number; Other Confederation Peers From Different Subautonomous Systems Must Also Be Identified As External Confederation Peers Using The BGP Confederation Peers Command.
5) Configure Any EBGP Neighbor As You Normally Would.
BGP CONFEDERATIONS CAN HAVE THREE TYPES OF BGP SESSIONS :
1) Regular IBGP Sessions : With Routers Inside The Same Sub-As. All These Routers Having IBGP Sessions Must Have The Same Asn To Identify The BGP Process (64990 And 64991 In Our Topology). Furthermore, It’s Necessary To Build A Full-Mesh IBGP Topology Inside Each Sub-As. All The Rules For IBGP Sessions Apply Here.
2) CBGP Sessions : The BGP Session Built Between Sub-As Is Called CBGP (Confederation BGP), And Its Characteristics Are A Mix Between IBGP And EBGP Sessions. The Topology Between Sub-As Doesn’t Need To Be Full-Mesh.
3) Regular EBGP Sessions: The Whole Confederations System Behaves As A Unique ASn Towards EBGP Sessions. All The Rules For EBGP Sessions Apply Here.
BENEFITS AND CONCERNS OF USING CONFEDERATIONS ARE :
Confederations Reduce CPU Utilization Due To Internal Route Churn, But Can Increases CPU Due To External Churn In Some Cases.
Confederations Can Help Identify Sources Of Routes Handily. One Just Has To Remember The “Fake” Confederated As Numbers In Each Pop Rather Than One Loopback For Each Router In A Pop.
With Confederations You Can Use EBGP Between Sites For More Control Over Routing.
EBGP Will Update The Next-Hop Router Attribute Between Confederated Ass.
USEFUL POINTS TO ALWAYS REMEMBER :
Confederations Are Another Alternative To The IBGP Full-Mesh Topology.
Inside A Confederation, All The Routers Must Be In Full-Mesh (Or In A Route-Reflector Topology), And The IBGP Rules Apply.
Between Confederations, The Multihop Limit Is 1, So Either It’s Changed To 2, Or The IP Of The Interface Directly Connected Is Used To Build The Session.
The Next-Hop Attribute Is Not Changed, And Is Passed To The Next Confederation Peer.
The AS Path Attribute Is Modified Inside The Confederation With The Sub-Autonomous ASns. When Announcing To An External AS, The Sub-Autonomous ASns Are Supressed And Only The ASN Of The Whole Confederations System Is Added.
ROUTE REFLECTORS :
BGP Requires That All BGP Peers In The Same Autonomous System Form An IBGP Session With All Peers In The Autonomous System. This Is Too Difficult In Many Environments. Route Reflectors Are Fully Functional IBGP Speakers That Form IBGP Sessions With Other IBGP Speakers, And They Also Perform A Second Function - They Forward Routes From Other IBGP Speakers To Route Reflector Clients. The Route Reflector Clients And Clients Form A Cluster.
Route Reflectors Distribute IBGP Information From One Router To Another, Which Is Normally Not Allowed In IBGP. Since The Clients Of The Route Reflector Get All IBGP From The Route Reflector They Don't Need To Have IBGP Sessions With All Other BGP Routers. Reflectors Add Additional Path Attributes That Allow Them To Detect And Eliminate Loops.
Route Reflectors Also Change The Behavior Of IBGP, Just Differently With Clients And Non-Clients.
BGP Route Reflectors (RR) Provides A Mechanism For Both Minimizing The Number Of Update Messages Transmitted Within The AS, And Reducing The Amount Of Data That Is Propagated In Each Message. The Deployment Of BGP Route Reflectors Leads To Much Higher Levels Of Network Scalability.
INITIAL IMPORTANT TASKS FOR ROUTE REFLECTORS
1) Route Reflector Clients Must Not Peer With RR’s Outside Of Their Cluster.
2) RR Clients Must Be One Hop From The RR Server.
3) Route Reflector Servers Still Need To Be Meshed With Non-RR-Clients.
4) Route Reflection Is Only Configured On The RR Server – The RR Clients Are Told Nothing.
5) A Lack Of Redundancy Exists With A RR Server Acting As A Single-Point-Of-Failure.
6) Route Reflection Consumes Resources On The Concentration (Route Reflector Server) Router.
7) Some Vendors Do Not Support The Optional/Nontransitive BGP Attributes Originator ID (Type 9) And Cluster List (Type 10).
8) Still Have N*(N-1)/2 Problem Between RRs (Must Run IBGP) Between RRs In Each Site.
1) Configure The Proper Cluster ID Value On The Route Reflector.
2) Configure The Route Reflector With Information About Which IBGP Neighbor Sessions Are Reaching Their Clients.
3) In The Clients, Remove All IBGP Sessions To Neighbors That Are Not A Route Reflector In The Client Cluster.
4) Make Sure That The IBGP Neighbor Is Removed On Both Ends Of The IBGP Session.
1) Each RR (Route Reflector) Sends Updates To All Reflector Clients.
2) RRs In Redundant Configuration (As Here) Must All Have The Same Cluster-Id.
3) If RR-Client Has More Than 1 Connection To An RR (As Here), RRs Must Use Same Cluster-Id.
4) RR-Client Would Not Have Other Non-RR-Client IBGP Sessions To Other RR-Clients.
5) EBGP Sessions To Other Ass Should Be Normally Done At Designated RR-Clients (Except In Case Of A Routeserver RR In A Public Exchange).
6) Each RR Must Be Fully Meshed With All Other RRs In Same Cluster (In This Example Case K2 Mesh).
1) ROUTES FROM A NONCLIENT PEER — Reflects To All The Clients Within The Cluster.
2) ROUTES FROM A CLIENT PEER — Reflects To All The Nonclient Peers And Also To The Client Peers.
3) ROUTES FROM AN EBGP PEER — Sends The Update To All Client And Nonclient Peers.
The Command Used To Configure The Cluster ID If The BGP Cluster Has Redundant Route Reflectors Is As Follows:
Syntax :
BGP Cluster-ID Cluster-ID
The Command Used To Configure The Router As A BGP Route Reflector And Configure The Specified Neighbor As Its Client Is As Follows:
Neighbor IP-Address Route-Reflector-Client
To Configure One Router As A Route Reflector, You Simply Configure A Neighbor Command With The Route-Reflector-Client Keyword For Those Neighbor Devices That Will Be Client Peers:
Router2(Config)#Router BGP 65500
Router2(Config-Router)#No Synchronization
Router2(Config-Router)#Neighbor 172.18.6.1 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.1 Route-Reflector-Client
Router2(Config-Router)#Neighbor 172.18.6.1 Update-Source Loopback0
Router2(Config-Router)#Neighbor 172.18.6.3 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.3 Route-Reflector-Client
Router2(Config-Router)#Neighbor 172.18.6.3 Update-Source Loopback0
Router2(Config-Router)#Neighbor 172.18.6.4 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.4 Update-Source Loopback0
Router2(Config-Router)#No Auto-Summary
Router2(Config-Router)#Exit
This Specifies That The Two Peers, 172.18.6.1 And 172.18.6.3, Are Client Peers. We Have Not Included A Neighbor Route-Reflector-Client Command For The Other Neighbor, 172.18.6.4, Making It A Nonclient Peer Of This Route Reflector.
There Is No Special Configuration Required On Either Client Or Nonclient Peer Routers And, Indeed, These Devices Don't Even Know Or Care About The Difference. The Only Router That Needs To Do Anything Special Is The Route Reflector Itself.
CLUSTER-ID :
NOTE : When Configuring Two Or More Redundant BGP Route Reflectors, Though, Another Little Trick Is Required.
As The Two Route Reflectors Hear About Every Reflected Routing Prefix Both From The Original Source And From The Other Route Reflector. This Could Cause Strange Behavior If The Real Source Of The Route Becomes Unavailable. The Two Route Reflectors Will Both Believe That The Route Is Reachable Through One Another.
To Prevent This Problem, We Need To Specify A Cluster ID On Each Route Reflector To Identify A Particular Group Of Client Peers:
Routera#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router 4(Config)#Router BGP 65500
Router 4(Config-Router)#BGP Cluster-Id 1234
And You Need To Configure The Same Cluster ID On The Other Route Reflector :
Router 4#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router 4(Config)#Router BGP 65500
Router 4(Config-Router)#BGP Cluster-Id 1234
NOTE :There Is One Important Caveat About Implementing Cluster Ids, However. In A Case Like This One, Where We Had One Router Acting As A Route Reflector, And We Wanted To Either Implement A New Cluster ID, Or To Change An Existing One, We Had To Manually Remove The Client Peer Configuration From The Route Reflector First.
Then We Configured The Cluster-Id Command And Replaced The Client Peer Neighbor Configuration Statements.
When Working With Route Reflectors, We Strongly Recommend Implementing Two Or More Redundant Reflectors. If You Have A Single Reflector For A Large Network, Then This Becomes A Dangerous Single Point Of Failure For Your Entire BGP Routing Infrastructure.
CISCO – BGP LAB FOR ROUTE REFLECTED CLIENT
Route Reflection Is Concerned With Distributing Routes Within An AS, Not The Actual Routing.
The Private Sub-ASns That Will Be Used In The Confederations Peers. (AS 65512 < - > AS 65517 In Our Topology).
BGP Only Send BGP Topology Table Details To The Neighbor Router Only. So That Purposes We Have To Create Route Reflected Client Route For Another New BGP Route If We Have Added Newly.
The Route Reflectors (RRs) Have To Be Configured To Reflect Routes To Router Reflector Clients.
The Clients Do Not Know They Are Clients And Are Configured As Normal IBGP Peers.
A Set Of RRs And Clients Is Referred To As A Cluster.
Only The Best Route To A Destination Is Sent From A RR To A Client.
To Avoid Loops, A RR Setup Should Always Follow The Physical Topology
Router> - User Exec Mode
Router# - Privileged Exec Mode
Router(Config)# - Configuration Mode (Notice The # Sign Indicates This Is Only Accessible At Privileged Exec Mode.)
Router(Config-If)# - Interface Level Within Configuration Mode.
Router(Config-Router)# - Routing Engine Level Within Configuration Mode.
Router# Copy Running-Config Startup-Config - Saves Configuration Into NVRAM
A Cisco IOS Router Stores Configurations In Two Locations - RAM And NVRAM. The Running Configuration Is Stored In RAM And Is Used By The Router During Operation. Any Configuration Changes To The Router Are Made To The Running-Configuration And Take Effect Immediately After The Command Is Entered.
The Startup-Configuration Is Saved In NVRAM And Is Loaded Into The Router's Running-Configuration When The Router Boots Up. If A Router Loses Power Or Is Reloaded, Changes To The Running Configuration Will Be Lost Unless They Are Saved To The Startup-Configuration.
To Save The Running-Configuration To The Startup Configuration, Type The Following From Privileged EXEC Mode (I.E. At The "Router#" Prompt.)
Router# Copy Running-Config Startup-Config
Router #Show IP BGP Neighbor IP-Address - > Displays Detailed Neighbor Information
Router #Show IP BGP - > Displays All The Routes In The BGP Table
Router #Show IP BGP IP-Prefix [Mask Subnet-Mask] - > Displays Detailed Information About All Paths For A Single Prefix
Router #Debug IP TCP Transactions - > Displays All TCP Transactions
Router #Debug IP BGP Events - > Displays Significant BGP Events
Router #Debug IP BGP Keepalives - > Debugs BGP Keepalive Packets
Router #Debug IP BGP Updates - > Displays All Incoming Or Outgoing BGP Updates.
Router #Debug IP BGP Updates Acl - > Displays All Incoming And Sent Updates Matching An ACL
Router #Debug UP BGP Ip-Address Update [Acl] - > Displays All BGP Updates Received From Or Sent To A Specific Neighbor
Router#CLEAR IP BGP* SOFT
Router#SHOW IP BGP
Router##SHOW IP BGP NEIGHBOR
Router#SHOW IP BGP SUMMARY
Router#SHOW IP INT BRIEF
Router#CLEAR IP ROUTE*
Router#SHOW IP ROUTE
Router#SHOW RUN
Router>enable (Switches To Privileged EXEC Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router A (Assign Host Name To Router A)
Router A(Config)#
Router A(Config)#int e0 (Switches To Configure The E0 Interface)
Router A(Config-if)#IP address 10.0.0.1 255.0.0.0 (Configures An IP Address On Ethernet0 (Interface))
Router A(Config-if)#No shutdown (Activates Serial0 (Interface))
Router A(Config-if)#No Keepalive (Keepalive Packets Are Disabled On The Interface To Pass Through Other Interface)
Router A(Config-if)#Exit (Exits Back To Global Configuration Level)
KEEPALIVE :
A Keepalive Is A Message Sent By One Device To Another To Check That The Link Between The Two Is Operating, Or To Prevent This Link From Being Broken. No Keepalive Will Be Bringing Down The Interface Or Before Bringing The Tunnel Protocol Down For A Specific Interface.
NOTE :If You Enter The No Keepalive Command, Keepalive Packets Are Disabled On The Interface.
Router A(Config)#Exit
Router A# Copy Running-Config Startup-Config (Saves Configuration Into NVRAM)
Router A#Conf T
Router A(Config)#Int s1 (Switches To Configure The Serial1 Interface)
Router A(Config-if)#Ip address 20.0.0.1 255.0.0.0
Router A(Config-if)#No shut (Enable An Interface)
Router A(Config-if)# Clock Rate 56000 (Set The Clock Rate 56000 For DCE Interface)
Router A(Config-if)# Bandwidth 64 (Set A Logical Bandwidth Assignment Of 64k To The Serial Interface)
To Enable The Back-To-Back Serial Connection Between Two Routers, You Need To Configure One Router As DCE Using The Following Command In Interface Configuration Mode For The Serial Connection On Two different Routers.
Router A(Config-if)#Exit
In A Real-Life Network, Your Serial Interfaces Will Almost Certainly Be Configured As DTE Interfaces. Recall That A CSU/DSU Usually Handles The Clocking For A Synchronous Serial Interface.
A DTE (Date Terminating Equipment) Cable Is The Normal Cable You Should Use. Being DTE You Should Expect The Other End To Provide Clocking.
A DCE (Data Communication Equipment) Means That This Device Must Provide The Clocking On The Wire. DTE/DCE Cable To Directly Connect Two Cisco Router Serial Interfaces.
Connecting The Serial Ports Of Two Routers Directly Using What Is Known As A DCE-To-DTE Crossover Cable. These Cables Allow You To Simulate A Serial WAN Connection Without Requiring A CSU/DSU Or Similar Device.
The Main Issue With Connecting Your Serial Interfaces In This Manner Is The Fact That One Of The Devices Will Need To Be Configured As DCE In Order To Provide The Timing Mechanism Required.
The DCE-To-DTE Crossover Cable Will Have Two Different DB-60 Interfaces – One Marked DTE, And The Other Marked DCE. The Router Connected To The DCE End Of The Cable Will Need Its Serial Interface Configured As A DCE Device.
NOTE : If Your Device Is The DCE, You Must Provide Clocking Using The Clock Rate Command.
Example - > Router A(Config-if)# Clock Rate 56000
Router A(Config-if)#^Z
Router A#
Router A# Copy Running-Config Startup-Config
Router A#SHOW RUN
Router A#SHOW IP ROUTE
Router A(Config)#Router BGP 10 (This Command To Configure A Fixed Router ID As An Identifier Of The Router Running BGP.)
BGP ROUTER-ID :
To Configure A Fixed Router ID For A BGP-Speaking Router, Use The BGP Router-Id Command In Router Configuration Mode. To Remove The BGP Router-ID Command From The Configuration File And Restore The Default Value Of The Router ID, Use The No BGP Router IDForm Of This Command.
Default The Router ID Is Set To The IP Address Of A Loopback Interface If One Is Configured. If No Virtual Interfaces Are Configured, The Highest IP Address Is Configured For A Physical Interface On That Router. Peering Sessions Will Be Reset If The Router ID Is Changed.
Router A(Config-Router)#Neighbor 20.0.0.2 remote-as 20
To Configure The Border Gateway Protocol (BGP) Routing Process, Use The Router BGP Command In Global Configuration Mode. The Above Example Configures A BGP Process For Autonomous System20).
Router A(Config-Router)#Network 10.0.0.0 (Advertised Route To The Network Specified Must Be Present In The Routing Table.)
Router A(Config-Router)#Network 20.0.0.0 (Advertised Route To The Network Specified Must Be Present In The Routing Table.)
Router A(Config-Router)#Exit (Or ^Z It will Go To Router A#)
Router A(Config)#Exit
Router A#
Router A# Copy Running-Config Startup-Config
Router A#CLEAR IP BGP* SOFT
The CLEAR IP BGP Command Can Be Used To Initiate A Hard Reset Or Soft Reconfiguration. A Hard Reset Tears Down And Rebuilds The Specified Peering Sessions And Rebuilds The BGP Routing Tables. A Soft Reconfiguration Uses Stored Prefix Information To Reconfigure And Activate BGP Routing Tables Without Tearing Down Existing Peering Sessions. Soft Reconfiguration Uses Stored Update Information, At The Cost Of Additional Memory For Storing The Updates, To Allow You To Apply New BGP Policy Without Disrupting The Network. Soft Reconfiguration Can Be Configured For Inbound Or Outbound Sessions.
Router A#CLEAR IP ROUTE*
Removes From The IP Routing Table From The IP Routing Table.
Router A#SHOW IP BGP NEIGHBOR
To Display Information About The TCP And BGP Connections To Neighbors, Use The Show IP BGP Neighbors Command In EXEC Mode.
Router A#SHOW IP BGP
To Display Entries In The BGP Routing Table, Use The Show IP BGP Command In EXEC Mode.
Router A#SHow IP ROUTE
To Display The Current State Of The Routing Table, Use The Show Ip Route Command In EXEC Mode.
Router A#SHOW IP INT BRIEF
Interface Commands (Show Ip Interface), To Display The Usability Status Of Interfaces Configured For IP, Use The Show Ip Interface Command In Privileged EXEC Mode.
Show Ip Interface [Type Number] [Brief]
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router B (Assign Host Name To Router B)
Router B(Config)#
Router B(Config)#Int S0
Router B(Config-if)#IP Address 20.0.0.2 255.0.0.0
Router B(Config-if)#No shutdown
Router B(Config-if)# Bandwidth 64
Router B(Config-if)#Exit
Router B(Config)#Exit
Router B# Copy Running-Config Startup-Config
Router B(Config)#Int S1
Router B(Config-if)#IP Address 30.0.0.1 255.0.0.0
Router B(Config-if)#No shutdown
Router B(Config-if)#Clock Rate 56000
Router B(Config-if)# Bandwidth 64
Router B(Config-if)#Exit OR (^Z)
Router B(Config)#Exit
Router B# Copy Running-Config Startup-Config
Router B#Conf T
Router B(Config)#Router BGP 65512
Router B(Config-Router)#Neighbor 20.0.0.1 remote-as 10
Router B(Config-Router)#Neighbor 30.0.0.1 remote-as 65512
Router B(Config-Router)#BGP confederation identifier 20 (The BGP Confederation Identifier Command Is Used To Configure A Single Autonomous System Number To Identify A Group Of Smaller Autonomous Systems As A Single Confederation).
BGP CONFEDERATION IDENTIFIER :
To Specify A BGP Confederation Identifier, Use The BGP Confederation Identifier Command In Router Configuration Mode.
To Enables To You To Retain A Single Interior Gateway Protocol (IGP) For All The Autonomous Systems. To The Outside World, The Confederation Looks Like A Single Autonomous System.
A Confederation Can Be Used To Reduce The Internal BGP (IBGP) Mesh By Dividing A Large Single Autonomous System Into Multiple Sub-Autonomous Systems And Then Grouping Them Into A Single Confederation. The Sub-Autonomous Systems Within The Confederation Exchange Routing Information Like IBGP Peers. External Peers Interact With The Confederation As If It Is A Single Autonomous System.
Each Sub-Autonomous System Is Fully Meshed Within Itself And Has A Few Connections To Other Autonomous Systems Within The Confederation. Next Hop, Multi Exit Discriminator (MED), And Local Preference Information Is Preserved Throughout The Confederation, Allowing You Enables To You To Retain A Single Interior Gateway Protocol (IGP) For All The Autonomous Systems.
Router B(Config-Router)#^z
Router B#
Router B# Copy Running-Config Startup-Config
Router B#SHOW RUN
Router B#SHOW IP ROUTE
Router B#SHOW IP INT BRIEF
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
Router B##SHOW IP BGP NEIGHBOR
Router B#CLEAR IP ROUTE*
Router B#SHOW IP ROUTE
Router B#SHOW RUN
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router C (Assign Host Name To Router C)
Router C(Config)#
Router C(Config)#Int S0
Router C(Config-if)#IP Address 30.0.0.2 255.0.0.0
Router C(Config-if)#No shutdown
Router C(Config-if)# Bandwidth 64
Router C(Config-if)#Exit
Router C(Config)#Exit
Router C#Copy Running-Config Startup-Config
Router C(Config)#Int S1
Router C(Config-if)#IP Address 40.0.0.1 255.0.0.0
Router C(Config-if)#No shutdown
Router C(Config-if)#Clock Rate 56000
Router C(Config-if)# Bandwidth 64
Router C(Config-if)#Exit OR (^Z)
Router C(Config)#Exit
Router C# Copy Running-Config Startup-Config
Router C#SHOW RUN
Router C#SHOW IP ROUTE
Router C#Conf T
Router C(Config)#Router BGP 65512
Router C(Config-Router)#Neighbor 30.0.0.1 remote-as 65512
Router C(Config-Router)#Neighbor 40.0.0.2 remote-as 65517
Router C(Config-Router)#BGP confederation identifier 20
Router C(Config-Router)#^z
Router C#
Router C# Copy Running-Config Startup-Config
Router C#SHOW IP INT BRIEF
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
Router C##SHOW IP BGP NEIGHBOR
Router C#CLEAR IP ROUTE*
Router C#SHOW IP ROUTE
Router C#SHOW RUN
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router D (Assign Host Name To Router D)
Router D(Config)#
Router D(Config)#Int S0
Router D(Config-if)#IP Address 40.0.0.2 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
Router D(Config)#Int S1
Router D(Config-if)#IP Address 50.0.0.1 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)#Clock Rate 56000
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit OR (^Z)
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
Router D#SHOW RUN
Router D#SHOW IP ROUTE
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#Neighbor 40.0.0.1 remote-as 65512
Router D(Config-Router)#Neighbor 50.0.0.2 remote-as 65517
Router D(Config-Router)#BGP confederation identifier 20
Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
Router D#SHOW IP INT BRIEF
Router D#CLEAR IP BGP* SOFT
Router D#SHOW IP BGP
Router D##SHOW IP BGP NEIGHBOR
Router D#CLEAR IP ROUTE*
Router D#SHOW IP ROUTE
Router D#SHOW RUN
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router E (Assign Host Name To Router E)
Router E(Config)#
Router E(Config)#Int S0
Router E(Config-if)#IP Address 50.0.0.2 255.0.0.0
Router E(Config-if)#No shutdown
Router E(Config-if)# Bandwidth 64
Router E(Config-if)#Exit
Router E(Config)#Exit
Router E# Copy Running-Config Startup-Config
Router E(Config)#Int S1
Router E(Config-if)#IP Address 60.0.0.1 255.0.0.0
Router E(Config-if)#No shutdown
Router E(Config-if)#Clock Rate 56000
Router E(Config-if)# Bandwidth 64
Router E(Config-if)#Exit OR (^Z)
Router E(Config)#Exit
Router E# Copy Running-Config Startup-Config
Router E#SHOW RUN
Router E#SHOW IP ROUTE
Router E#Conf T
Router E(Config)#Router BGP 65517
Router E(Config-Router)#Neighbor 50.0.0.1 remote-as 65517
Router E(Config-Router)#Neighbor 60.0.0.2 remote-as 30
Router E(Config-Router)#BGP confederation identifier 20
Router E(Config-Router)#^z
Router E#
Router E# Copy Running-Config Startup-Config
Router E#SHOW IP INT BRIEF
Router E#CLEAR IP BGP* SOFT
Router E#SHOW IP BGP
Router E##SHOW IP BGP NEIGHBOR
Router E#CLEAR IP ROUTE*
Router E#SHOW IP ROUTE
Router E#SHOW RUN
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router F (Assign Host Name To Router F)
Router F(Config)#
Router F(Config)#Int e0
Router F(Config-if)#IP Address 70.0.0.1 255.0.0.0
Router F(Config-if)#No shutdown
Router F(Config-if)#No Keepalive
Router F(Config-if)#Exit
Router F(Config)#Exit
Router F# Copy Running-Config Startup-Config
Router F(Config)#Int S0
Router F(Config-if)#IP Address 60.0.0.2 255.0.0.0
Router F(Config-if)#No shutdown
Router F(Config-if)# Bandwidth 64
Router F(Config-if)#Exit OR (^Z)
Router F(Config)#Exit
Router F# Copy Running-Config Startup-Config
Router F#SHOW RUN
Router F#SHOW IP ROUTE
Router F#Conf T
Router F(Config)#Router BGP 30
Router F(Config-Router)#Neighbor 60.0.0.1 remote-as 20
Router F(Config-Router)#Network 60.0.0.0
Router F(Config-Router)#Network 70.0.0.0
Router F(Config-Router)#^z
Router F#
Router F# Copy Running-Config Startup-Config
Router F#SHOW IP INT BRIEF
Router F#CLEAR IP BGP* SOFT
Router F#SHOW IP BGP
Router F##SHOW IP BGP NEIGHBOR
Router F#CLEAR IP ROUTE*
Router F#SHOW IP ROUTE
Router F#SHOW RUN
CONFEDERATION PEER CONNECTION
STEP 1:
Making Connection In Between Two Each Private AS Such As AS 65512 And 65517).
Router C#Conf T
Router C(Config)#Router BGP 65512
Router C(Config-Router)#BGP Confederation Peers 65517 (To Configure Sub- Autonomous Systems To Belong To A Single Confederation, Use The BGP Confederation Peers Command In Router Configuration Mode.)
BGP CONFEDERATION PEERS:
To Configure Sub-Autonomous Systems To Belong To A Single Confederation, Use The BGP Confederation Peers Command In Router Configuration Mode. To Remove An Autonomous System From The Confederation, Use The No Form Of This Command.
The BGP Confederation Peers Command Is Used To Configure Multiple Autonomous Systems As A Single Confederation. The Ellipsis (...) In The Command Syntax Indicates That Your Command Input Can Include Multiple Values For The As-Number Argument.
The Autonomous Systems Specified In This Command Are Visible Internally To The Confederation. Each Autonomous System Is Fully Meshed Within Itself. The BGP Confederation Identifier Command Specifies The Confederation To Which The Autonomous Systems Belong.
Router C(Config-Router)#^z
Router C#
Router C# Copy Running-Config Startup-Config
THEN GO TO ROUTER D:
STEP 2:
Making Connection In Between Two Each Private AS Such As AS 65512 And 65517).
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#BGP Confederation Peers 65512 Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
Router F#SHOW IP INT BRIEF
#CLEAR IP BGP* SOFT
#SHOW IP BGP
#SHOW IP BGP NEIGHBOR
#SHOW IP BGP SUMMARY
#CLEAR IP ROUTE*
F#SHOW IP ROUTE
#SHOW RUN
#TRACEROUTE 10.0.0.1
PING AND TRACEROUTE :
The Ping And Traceroute Commands Are Convenient, Frequently Used Tools For Checking Network Connectivity And Troubleshooting Network Problems. The Ping Command Determines Whether A Specific IP Address Is Online By Sending Out A Packet And Waiting For A Response. The Traceroute Command Provides The Path From The Source To The Remote Destination Being Contacted.
PING :
The Ping Command Is A Common Method For Troubleshooting The Accessibility Of Devices. It Uses Two Internet Control Message Protocol (ICMP) Query Messages, ICMP Echo Requests, And ICMP Echo Replies To Determine Whether A Remote Host Is Active. The Ping Command Also Measures The Amount Of Time It Takes To Receive The Echo Reply.
The Ping Command First Sends An Echo Request Packet To An Address, And Then It Waits For A Reply. The Ping Is Successful Only If The Echo Request Gets To The Destination, And The Destination Is Able To Get An Echo Reply (Hostname Is Alive) Back To The Source Of The Ping Within A Predefined Time Interval.
TRACEROUTE :
Where The Ping Command Can Be Used To Verify Connectivity Between Devices, The Traceroute Command Can Be Used To Discover The Paths Packets Take To A Remote Destination And Where Routing Breaks Down.
The Traceroute Command Records The Source Of Each ICMP "Time-Exceeded" Message To Provide A Trace Of The Path That The Packet Took To Reach The Destination. You Can Use The IP Traceroute Command To Identify The Path That Packets Take Through The Network On A Hop-By-Hop Basis. The Command Output Displays All Network Layer (Layer 3) Devices, Such As Routers, That The Traffic Passes Through On The Way To The Destination.
The Traceroute Command Uses The Time To Live (TTL) Field In The IP Header To Cause Routers And Servers To Generate Specific Return Messages. The Traceroute Command Sends A User Datagram Protocol (UDP) Datagram To The Destination Host With The TTL Field Set To 1. If A Router Finds A TTL Value Of 1 Or 0, It Drops The Datagram And Sends Back An ICMP Time-Exceeded Message To The Sender. The Traceroute Facility Determines The Address Of The First Hop By Examining The Source Address Field Of The ICMP Time-Exceeded Message.
To Identify The Next Hop, The Traceroute Command Sends A UDP Packet With A TTL Value Of 2. The First Router Decrements The TTL Field By 1 And Sends The Datagram To The Next Router. The Second Router Sees A TTL Value Of 1, Discards The Datagram, And Returns The Time-Exceeded Message To The Source. This Process Continues Until The TTL Increments To A Value Large Enough For The Datagram To Reach The Destination Host (Or Until The Maximum TTL Is Reached).
To Determine When A Datagram Reaches Its Destination, The Traceroute Command Sets The UDP Destination Port In The Datagram To A Very Large Value That The Destination Host Is Unlikely To Be Using. When A Host Receives A Datagram With An Unrecognized Port Number, It Sends An ICMP Port Unreachable Error To The Source. This Message Indicates To The Traceroute Facility That It Has Reached The Destination.
TO SOLVE REACHABILITY PROBLEMS
Reachability Issues When Interfaces Other Than Directly Connected Interfaces Are Used While Peering.
Border Gateway Protocol (BGP), The De-Facto Inter-Domain Routing Protocol, Can Adapt To Failures By Converging To A New Set Of Valid Paths. However, The Routing Adjustment May Take A Long Time Due To Various Delays In The Propagation Of Update Messages And The Exploration Of Alternative Paths.
As A Result, The Period Of Destination Unreachability Can Be Substantially Longer Than The Time Period Of Actual Physical Connectivity Losses. BGP Convergence Time Without Considering The Impact On Packet Delivery. Packet Delivery Performance Is Related, But Not Equivalent, To The Routing Convergence Time.
Path Vector Messages In BGP: The Autonomous System Boundary Routers (ASBR), Which Participate In Path Vector Routing, Advertise The Reachability Of Networks. Each Router That Receives A Path Vector Message Must Verify That The Advertised Path Is According To Its Policy. If The Messages Comply With The Policy, The ASBR Modifies Its Routing Table And The Message Before Sending It To The Next Neighbor. In The Modified Message It Sends Its Own AS Number And Replaces The Next Router Entry With Its Own Identification.
BGP ROUTES INJECTION PROCESS: The BGP Process Injects Local Routes In Two Different Ways:
Using The Network Configuration Commands. This Command Lists Networks That Are Candidates If They Appear In The Routing Table.
Using Redistribution From Another Routing Protocol.
If Certain BGP Routes Are Missing From The Routing Table, Determine If They Are Learned Through BGP And Exist In The BGP Table. Routes Existing In The BGP Table Might Be Missing From The Routing Table Due To The BGP Synchronization Rule Or Due To The Non-Availability Of A Valid Route To The Next Hop. If The Routes Are Missing From The BGP Table Altogether, Determine If The Peering Has Been Successful, And Check For The Existence Of Route Filters. If BGP Routes Are Not Being Advertised, Check If The Conditions For Advertising BGP Routes Are Being Satisfied.
An Internal Border Gateway Protocol (IBGP) Learned Route Is Not Advertised To Other IBGP Peers, And Configuring A Route Reflector Might Be Necessary.
Aggregate Routes Are Not Advertised Unless At Least One Component Route Exists In The BGP Table.
Similarly, Routes Advertised By Issuing The BGP Network Command Are Also Subject To The Existence Of Corresponding Routes In The Routing Table.
Ensure That BGP Routers Are Able To Cope With The High Amount Of Routing Information That Is Typically Exchanged Between Routers Configured For BGP.
If Cannot Be Measured By Examining The Routing Tables At All The Routers At Time, Because It Takes Time For A Packet To Propagate Through The Network And The Routing Tables May Change During This Time Period. 1Minimum Route Announcement Interval, Which Is Used To Space Out Consecutive Route Announcement Messages (“Reachability msg”).
NOTE: In Such Cases, Additional Configuration Might Be Required.
ACCORDING TO OUR TOPOLOGY
NOTE: (According To Our Topology) REHABILITEE & BEST PATH PROBLEMS SHOULD BE SOLVE IN: (NeighborNext-Hop-Self) :
Router B Rehabilitee Problems Should Be Solve On Router C.
Router C Rehabilitee Problems Should Be Solve On Router B And Router D.
Router D Rehabilitee Problems Should Be Solve On Router C And Router E.
Router E Rehabilitee Problems Should Be Solve On Router D.
RB < - (For Router C) - > RD
STEP 1:
For Router B Receiving Point From Router C. So giving This Command On Router B. (Neighbor Next-Hop-Self Address Is 30.0.0.2).
Router B(config)#Router BGP 65512
Router B(config-Router)#Neighbor 30.0.0.2 next-hop-self.
Router B(config-Router)#^z
NEXT-HOP-SELF:
Router(config-router)#Neighbor {ip-address | peer-group-name} next-hop-self - > Disables next hop processing on BGP updates to a neighbor.
Configuring This Command Causes The Current Router To Advertise Its Peering Address As The Next Hop For The Specified Neighbor. Therefore, Other BGP Neighbors Will Forward To It Packets For That Address.
This Configuration Is Useful In A Nonmeshed Environment Because You Know That A Path Exists From The Present Router To That Address. In A Fully Meshed Environment, This Configuration Is Not Useful Because It Will Result In Unnecessary Extra Hops And Because There Might Be A Direct Access Through The Fully Meshed Cloud With Fewer Hops.
STEP 1 - 002 :
Router D(Config)#Router BGP 65512
Router D(Config-Router)#neighbor 40.0.0.1 next-hop-self
Router D(Config-Router)^z
STEP 1 - 003 :
Router C#CLEAR IP BGP* SOFT (Refresh New Entries)
Router C#CLEAR IP BGP*
Then - > Give This Command
Router C#SHOW IP BGP
THERE IS NO BEST PATH ON ROUTER C
STEP 1 - 004 :
So Now Reachability Problem Is Solve In Router C From Router B. But The Best Path Is Still Not So - > Going To Solve This (Give This Command).
Router C(config)#Router BGP 65512
Router C(config-router)#No Synchronization (Disables Synchronization Between BGP And An IGP - > Best Path From Router C To Router B)
Router C(config-router)Z
If Will Not Be Passing Traffic From A Different Autonomous System Through Your Autonomous System, Or If All Routers In Your Autonomous System Will Be Running BGP, You Can Disable Synchronization. Disabling This Feature Can Allow You To Carry Fewer Routes In Your IGP And Allow BGP To Converge More Quickly.
So Now Router C Reachability Problem and Best Path are Is Solved.
STEP 1 - 005 :
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem And The Best Path Are Solved.
RC < - (For Router D) - > RE
STEP 2 - 001 :
For Router C Receiving Point From Router C (40.0.0.2) and Router E (50.0.0.1) .
Router C(config)#Router BGP 65512
Router C(config-Router)#neighbor 40.0.0.2 next-hop-self.
Router C(config-Router)#^z
One Side (On Router C) Receiving Point Is Ok But Other Side (Router E) Still Having Reachability Problem. Should Be Solving On Router E.
STEP 2 - 002 :
Router E(config)#Router BGP 65517
Router E(config-Router)#neighbor 50.0.0.1 next-hop-self.
Router E(config-Router)#^z
STEP 2 - 003 :
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem Is Solved But The Best Path Is Not Yet Solve. So Give This Command On Router D “Router D(Config-Router)# No Synchronization”
STEP 2 - 004 :
THERE IS NO BEST PATH
Router D(config)#Router BGP 65517
Router D(config-router)#No Synchronization
Router D(config-router)Z
STEP 1 - 005 :
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem And The Best Path Are Solved Now.
RD < - (For Router E)
STEP 3 - 001 :
Router D(Config)#Router BGP 65517
Router D(Config-Router)# Neighbor 50.0.0.2 next-hop-self.
Router D(config-Router)#^z
Router E#CLEAR IP BGP* SOFT
Router E#SHOW IP BGP
STEP 3 - 003 :
THERE IS NO BEST PATH ON ROUTER E
Router E(config)#Router BGP 65517
Router E(config-router)#No Synchronization
Router E(config-router)Z
(For Router B) - > RC
STEP 4 - 001 :
To Solve Router B Reachability Problem On Router B Go To Router C.
Router C(Config)#Router BGP 65512
Router D(Config-Router)# Neighbor 30.0.0.1 next-hop-self.
Router D(config-Router)#^z
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
THERE IS NO BEST PATH
STEP 4 - 002 :
Router B(config)#Router BGP 65517
Router B(config-router)#No Synchronization
Router B(config-router)Z
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
NOTE: Now Each And Every Reachability And Best Path Problems Has Been Solved From Router A - > Router F And Router F - > Router A Route. So Next We Go For BGP Route Reflected Client Configuration on Router G.
BGP ROUTE REFLECTED CLIENT
NOTE :According To Our Topology Router G Is ROUTE REFLECTED CLIENT For Router D.
STEP 1:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router G (Assign Host Name To Router G)
Router G(Config)#
Router G(Config)#Int e0
Router G(Config-if)#IP Address 90.0.0.1 255.0.0.0
Router G(Config-if)#No shutdown
Router G(Config-if)#No Keepalive
Router G(Config-if)#Exit
Router G(Config)#Exit
Router G# Copy Running-Config Startup-Config
Router G(Config)#Int S0
Router G(Config-if)#IP Address 80.0.0.2 255.0.0.0
Router G(Config-if)#No shutdown
Router G(Config-if)#Clock Rate 56000
Router G(Config-if)# Bandwidth 64
Router G(Config-if)#Exit OR (^Z)
Router G(Config)#Exit
Router G# Copy Running-Config Startup-Config
Router G#SHOW RUN
Router G#SHOW IP ROUTE
Router G#Conf T
Router G(Config)#Router BGP 65517
Router G(Config-Router)#Neighbor 800.0.0.1 remote-as 65517
Router G(Config-Router)# BGP Confederation Identifier20 (One Way To Reduce The IBGP Mesh Is To Divide An Autonomous System Into Multiple Autonomous Systems And Group Them Into A Single Confederation.)
Router G(Config-Router)#Network 90.0.0.0
Router G(Config-Router)#Network 80.0.0.0
Router G(Config-Router)#^z
Router G#
Router G# Copy Running-Config Startup-Config
STEP 2:
THEN GO TO ROUTER D:
Router D(Config)#Int S2
Router D(Config-if)#IP Address 80.0.0.1 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit OR (^Z)
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
Router D#SHOW RUN
Router D#SHOW IP ROUTE
NEIGHBOR ROUTE-REFLECTOR-CLIENT
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#Neighbor 800.0.0.2 remote-as 65517
Router D(Config-Router)# BGP Confederation Identifier20 (One Way To Reduce The IBGP Mesh Is To Divide An Autonomous System Into Multiple Autonomous Systems And Group Them Into A Single Confederation).
Router D(Config-Router)# Neighbor 80.0.0.2 Route-Reflector-Client (Restores Route Reflection From A BGP Route Reflector To Clients).
NEIGHBOR ROUTE-REFLECTOR-CLIENT :
To Configure The Router As A BGP Route Reflector And Configure The Specified Neighbor As Its Client, Use The Neighbor Route-Reflector-Client Command In Router Configuration Mode. To Indicate That The Neighbor Is Not A Client, Use The No Form Of This Command. When All The Clients Are Disabled, The Local Router Is No Longer A Route Reflector.
By Default, All IBGP Speakers In An Autonomous System Must Be Fully Meshed, And Neighbors Do Not Readvertise IBGP Learned Routes To Neighbors, Thus Preventing A Routing Information Loop.
If You Use Route Reflectors, All IBGP Speakers Need Not Be Fully Meshed. In The Route Reflector Model, An Internal BGP Peer Is Configured To Be A Route Reflector Responsible For Passing IBGP Learned Routes To IBGP Neighbors. This Scheme Eliminates The Need For Each Router To Talk To Every Other Router.
Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
#CLEAR IP BGP* SOFT
#SHOW IP BGP
#SHOW IP BGP NEIGHBOR
RC < - (Router G) - > RD
STEP 1:
For Router G Receiving Point From Router D (80.0.0.1).
Router D(config)#Router BGP 65517
Router D(config-Router)#neighbor 80.0.0.2 next-hop-self.
Router D(config-Router)#^z
Router G#CLEAR IP BGP* SOFT
Router G#SHOW IP BGP
Router G#SHOW IP BGP NEIGHBOR
NOTE :Now Router G Reachability Problem Is Solved But The Best Path Is Not Yet Solve. So Give This Command On Router G “Router G (Config-Router)# No Synchronization ”
STEP 2:
THERE IS NO BEST PATH
Router G(config)#Router BGP 65517
Router G(config-router)#No Synchronization
Router G(config-router)Z
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
Router G#SHOW IP BGP NEIGHBOR
NOTE :
When Checked On Router G Reachability Problem And The Best Path Are Solved Now.
BGP Only Send BGP Topology Table Details to the Neighbor Router Only.
EXTERNAL PING FROM ROUTER A TO - > RG & RF
Router A#PING
-
-
Target IP Address 70.0.0.1
-
-
Source IP Address 10.0.0.1
THEN ROUTER A PING TO - > ROUTER G:
ROUTER A#PING
-
-
Target IP Address 90.0.0.1
-
-
Source IP Address 10.0.0.1
EXTERNAL PING FROM ROUTER F TO - > RG & RA
Router F#PING
-
-
Target IP Address 10.0.0.1
-
-
Source IP Address 70.0.0.1
THEN ROUTER F PING TO - > ROUTER G:
ROUTER F#PING
-
-
Target IP Address 90.0.0.1
-
-
Source IP Address 70.0.0.1
ALSO KNOW THIS COMMANDS (In Our Lab We Are Not Using)
NEIGHBOR SEND-COMMUNITY:
To Specify That A Communities Attribute Should Be Sent To A BGP Neighbor, Use The Neighbor Send-Community Command In Router Configuration Mode. To Remove The Entry, Use The No Form Of This Command.
Neighbor {Ip-Address | Peer-Group-Name} Send-Community [Both | Standard | Extended]
No Neighbor {Ip-Address | Peer-Group-Name} Send-Community
If You Specify A BGP Peer Group By Using The Peer-Group-Name Argument, All The Members Of The Peer Group Will Inherit The Characteristic Configured With This Command.
EXAMPLES :
In The Following Example, The Router Belongs To Autonomous System 65517 And Is Configured To Send The Communities Attribute To Its Neighbor At Ip Address 80.0.0.2
Router D(Config)#Router BGP 65517
Router D(Config-Router)# BGP Confederation Identifier20
Router D(Config-Router)# Neighbor 80.0.0.2 Route-Reflector-Client
Router D(Config-Router)#Neighbor 80.0.0.2 Send-Community
NEIGHBOR SHUTDOWN :
To Disable A Neighbor Or Peer Group, Use The Neighbor Shutdown Command In Router Configuration Mode.To Re-Enable The Neighbor Or Peer Group, Use The No Form Of This Command.
Neighbor {Ip-Address | Peer-Group-Name} Shutdown
No Neighbor {Ip-Address | Peer-Group-Name} Shutdown
The Neighbor Shutdown Command Terminates Any Active Session For The Specified Neighbor Or Peer Group, And Removes All Associated Routing Information. In The Case Of A Peer Group, This Could Mean A Large Number Of Peering Sessions Are Suddenly Terminated.
To Display A Summary Of BGP Neighbors And Peer-Group Connections, Use The Show IP BGP Summary Command. Those Neighbors With An Idle Status And The Admin Entry Have Been Disabled By The Neighbor Shutdown Command.
The Goal Of This Article Is To Give An Easy Way To Understand The “CISCO – BGP LAB “ROUTE REFLECTED CLIENT” STEP BY STEP LAB CONFIGURATION GUIDANCE”. Hope This Article Will Help Every Beginners Who Are Going To Start Cisco Lab Practice Without Any Doubts.
Some Topics That You Might Want To Pursue On Your Own That We Did Not Cover In This Article Are Listed Here, Thank You And Best Of Luck.
This Article Written Author By: Premakumar Thevathasan. CCNA, CCNP, CCIP, MCSE, MCSA, MCSA - MSG, CIW Security Analyst, CompTIA Certified A+.
RECAP OF BORDER GATEWAY PROTOCOL (BGP - 4) :
BGP-1 Was First Defined In RFC 1105 In 1989, Then Was Updated With BGP-2 In 1990 With RFC 1163 Only To Updated Again To BGP-3 In 1991 With RFC 1267.
The Current Version Of BGP Is Known As Bgp-4 And Was Defined In RFC 1654, RFC 1655, RFC 1771 And RFC 1772. BGP-4 Was Different From Earlier Versions In One Main Respect And That Was It Became A Classless Routing Protocol And Thereby Supported CIDR. For Information On CIDR Have A Look At CIDR.
In BGP Terminology, An Independent Routing Domain (Which Almost Always Means An ISP) Is Called An Autonomous System.
BGP Is Always Used As The Routing Protocol Of Choice Between ISPs (External BGP) But Also As The Core Routing Protocol Within Large ISP Networks (Internal BGP).
BGP Is Considered To Be A 'Path Vector' Routing Protocol Rather Than A Distance Vector Routing Protocol Since It Utilises A List Of AS Numbers To Describe The Path That A Packet Should Take. This List Is Called The AS_PATH. Loops Are Prevented Because If A BGP Speaking Router Sees It's Own AS In The AS_PATH Of A Route It Rejects The Route.
A Router In A Transit AS May Have Extremely Large Routing Tables (Up To 90,000 Networks Amounting To Over 30Mb) And BGP-4 Uses Classless Interdomain Routing (CIDR) To Slow The Growth Of These Tables.
BGP's Basic Unit Of Routing Information Is The BGP Path, A Route To A Certain Set Of CIDR Prefixes. Paths Are Tagged With Various Path Attributes, Of Which The Most Important Are AS_PATH And NEXT_HOP.
THERE ARE TWO TYPES OF SESSIONS BETWEEN A ROUTER AND ITS NEIGHBOURS:
External BGP (EBGP): Sessions Occur Between Routers In Different Ass Which Are Usually Next To Each Other Sharing The Same Media And Subnet.
Internal BGP (IBGP): Sessions Occur Between Routers Within The Same AS And These Sessions Are Used To Synchronise The Routing Policy Within An AS. These Routers Do Not Have To Be Next To Each Other However They Do Need To Be Able To See Each Other So That A TCP Connection Can Be Made Between Them! You Would Configure These If You Were Needing To Pass BGP Information To Other Ass.
IBGP AND EBGP ARE THE BASICALLY THE SAME ROUTING PROTOCOL JUST WITH DIFFERENT RULES AND APPLICATIONS:
EBGP Advertises Everything To Everyone By Default.
IBGP Does Not Advertise “3rd-Party Routes” To Other IBGP Peers.
This Is Because There Is No Way To Do Loop Detection With IBGP, So This Solves It. IBGP, By Default, Does Not Change The Next-Hop Address Attribute As Routes Traverse An IBGP Mesh. An IBGP Peer Will Not Advertise A Route Learned By One IBGP Peer To Another IBGP Peer. This Is A Readvertisement Restriction To Prevent Looping. Therefore, IBGP Should Be Used When AS_PATH Information Must Remain Intact Between Multiple EBGP Peers.
BGP-4: Uses TCP (Port 179) For Sending And Receiving Messages Reliably Between Peer Routers. (BGP Calls Routers Speakers, And Routers That Run Between Each Other Are Called Peers). The Reliable Connection Means That Only Changes Need To Be Sent Between Peers Rather Than Complete Tables. These Updates Can Be Triggered Updates Rather Than Periodic Updates. Only Keep Alive Messages Are Sent Regularly.
One Of BGP-4's Most Important Functions Is Loop Detection At The Autonomous System Level, Using The AS_PATH Attribute, A List Of Autonomous Systems Being Used For Data Transport.
The Syntax Of This Attribute Is Made More Complex By Its Need To Support Path Aggregation, When Multiple Paths Are Collapsed Into One To Simplify Further Route Advertisements. A Simplified View Of AS_PATH Is That It Is The List Of Autonomous Systems That A Route Goes Through To Reach Its Destination. Loops Are Detected And Avoided By Checking For Your Own AS Number In AS_PATH's Received From Neighboring Autonomous Systems.
Every Time A BGP Path Advertisement Crosses An Autonomous System Boundary, The NEXT_HOP Attribute Is Changed To The IP Address Of The Boundary Router. Conversely, As A BGP Path Advertisement Is Passed Among BGP Speakers In The Same AS, The NEXT_HOP Attribute Is Left Untouched. Consequently, BGP's NEXT_HOP Is Always The IP Address Of The First Router In The Next Autonomous System, Even Though This May Actually Be Several Hops Away. The AS's Interior Routing Protocol Is Responsible For Computing An Interior Route To Reach The BGP NEXT_HOP. This Leads To The Distinction Between Internal BGP (IBGP) Sessions (Between Routers In The Same AS) And External BGP (EBGP) Sessions (Between Routers In Different AS's). NEXT_Hops Are Only Changed Across EBGP Sessions, But Left Intact Across IBGP Sessions.
The Two Most Important Consequences Of This Design Are The Need For Interior Routing Protocols To Reach One Hop Beyond The AS Boundary, And For BGP Sessions To Be Fully Meshed Within An AS.
Since The NEXT_HOP Contains The IP Address Of A Router Interface In The Next Autonomous System, And This IP Address Is Used To Perform Routing, The Interior Routing Protocol Must Be Able To Route To This Address. This Means That Interior Routing Tables Must Include Entries One Hop Beyond The AS Boundary. Furthermore, Since BGP Does Not Relay Routing Traffic From One Interior BGP Session To Another (Only From An Exterior BGP Session To An IBGP Session Or Another EBGP Session), BGP Speakers Must Be Fully Meshed.
When A BGP Routing Update Is Received From A Neighboring AS, It Must Be Relayed Directly To All Other BGP Speakers In The AS. Do Not Expect To Relay BGP Paths From One Router, Through Another, To A Third, All Within The Same AS.
BGP Requires A Full Mesh Of Internal BGP Sessions (Sessions Between Routers In The Same Autonomous System). You Could Use BGP Route Reflectors Or BGP Confederations To Make Your Network Scalable.
INTRODUCTION OF BGP ROUTE REFLECTORS :
Route Reflectors are defined in RFC 1966.
A Route Reflector (RR) Is A Network Routing Component. Its Offers An Alternative To The Logical Full-Mesh Requirement Of Internal Border Gateway Protocol (IBGP). Route Reflectors Is A Technique To Better Control The Deployment Of BGP Inside Of A Large AS. Route Reflectors Provide A Method To Reduce IBGP Mesh By Creating A Concentration Router To Act As A Focal Point For IBGP Sessions.
The Route Reflection Mechanism Relaxes The Rule That IBGP Updates May Not Be Sent To Other IBGP Speakers. Route Reflectors Send (Reflect) All Routes Learned Over IBGP To Their Clients. Thus, A Route Reflector Client Needs To Have An IBGP Connection Only To A Single Route Reflector, But It Still Receives The Best Route (As Determined By The Reflector) For Each Destination. A Cluster Of Route Reflector Clients May Be Served By More Than One Route Reflector, To Avoid Having A Single Point Of Failure. Route Reflection Has A Big Advantage Over Confederations: Only The Reflectors Have To Be Aware Of It. Clients And Nonclient (Regular) IBGP Neighbors Don't Have To Be Configured In A Special Way Or Do Anything Other Than Regular BGP Processing. Route Reflectors Are Often Used On A Per-Pop Basis, To Hide The Additional BGP Routers In The Pop From The Rest Of The Network.There Must Still Be A Full IBGP Mesh Between All Route Reflectors And Nonclient Peers.Also, Route Reflector Clients Must Know All Possible Next Hop Addresses, So They Have To Participate Fully In The IGP.
The Routers Acting As Route Reflector (RRs) Will Announce To Other IBGP Peers Whatever They Have Learned From Their IBGP Clients. So It’s Not Needed Any More To Build A Full-Mesh Topology. It’s Enough With Each Router Having An IBGP Session With The RR, Becoming Then Clients Of The RR.
An RR Acts As A Focal Point For IBGP Sessions. The Purpose Of The RR Is Concentration. Multiple BGP Routers Can Peer With A Central Point, The RR - Acting As A Route Reflector Server - Rather Than Peer With Every Other Router In A Full Mesh. All The Other IBGP Routers Become Route Reflector Clients.
The Concentration Router Is Called A Route Reflector Server. Routers Called Route Reflector Clients Only Have To Peer With The RR Server To Exchange Routing Information Between Themselves. The Route Reflector Server “Reflects” The Routes To Its Clients. This Means That The IBGP Re-Advertisement Restrictions Are Relaxed. It Is Possible To Arrange A Hierarchical Structure Of These Servers And Clients And Group Them Into What Is Known As Clusters.
BGP Requires That All BGP Peers In The Same Autonomous System Form An IBGP Session With All Peers In The Autonomous System. This Is Too Difficult In Many Environments. Route Reflectors Are Fully Functional IBGP Speakers That Form IBGP Sessions With Other IBGP Speakers, And They Also Perform A Second Function - They Forward Routes From Other IBGP Speakers To Route Reflector Clients. The Route Reflector Clients And Clients Form A Cluster.
NOTE :The Non-Client Peer Must Be Fully Meshed But The Client Peers Need Not Be Fully Meshed.
BGP ROUTE REFLECTION OPERATION :
When An RR Receives A Route From An IBGP Peer, It Selects The Best Path Based On Its Path Selection Rule. After The Best Path Is Selected, It Must Do The Following Depending On The Type Of Peer It Is Receiving The Best Path From:
1) A Route From A Non-Client IBGP Peer :
Reflect To All The Clients.
2) A Route From A Client Peer :
Reflect To All The Non-Client Peers And Also To The Client Peers. (Hence The Client Peers Are Not Required To Be Fully Meshed.)
An Autonomous System Could Have Many RRs. An RR Treats Other RRs Just Like Any Other Internal BGP Speakers. An RR Could Be Configured To Have Other RRs In A Client Group Or Non-Client Group.
In A Simple Configuration, The Backbone Could Be Divided Into Many Clusters. Each RR Would Be Configured With Other RRs As Non-Client Peers (Thus All The RRs Will Be Fully Meshed). The Clients Will Be Configured To Maintain IBGP Session Only With The RR In Their Cluster. Due To Route Reflection, All The IBGP Speakers Will Receive Reflected Routing Information.
It Is Possible In An Autonomous System To Have BGP Speakers That Do Not Understand The Concept Of Route Reflectors (Let Us Call Them Conventional BGP Speakers). The Route Reflector Scheme Allows Such Conventional BGP Speakers To Coexist. Conventional BGP Speakers Could Be Members Of Either A Non-Client Group Or A Client Group.
This Allows For An Easy And Gradual Migration From The Current IBGP Model To The Route Reflection Model. One Could Start Creating Clusters By Configuring A Single Router As The Designated RR And Configuring Other Rrs And Their Clients As Normal IBGP Peers. Additional Clusters Can Be Created Gradually.
REDUNDANT RRS :
Usually, A Cluster Of Clients Will Have A Single RR. In That Case, The Cluster Will Be Identified By The BGP Identifier Of The RR. However, This Represents A Single Point Of Failure So To Make It Possible To Have Multiple RRs In The Same Cluster, All RRs In The Same Cluster Can Be Configured With A 4-Byte CLUSTER_ID So That An RR Can Discard Routes From Other RRs In The Same Cluster.
The BGP Protocol Provides No Way For A Client To Identify It Self Dynamically As A Client To An RR Configured BGP Speaker And The Simplest Way To Achieve This Is By Manual Configuration.
There Can Be Multiple Router Reflectors In The Same Cluster And At Different Levels. A Route Reflector Forms A Peering With The Other Non-Route Reflectors Called Clients And Forms A Cluster With Them. The Clients Are Not Peers With Each Other. Other IBGP Routers Not In The Cluster Are Called Non-Clients. The ORIGINATOR_ID Attribute Is Used To Identify The Router-Id Of The Route Reflector This Enables The Router To Determine Whether The Route Has Come From Itself In The First Place Thereby Preventing Loops. Another Way Of Preventing Loops Is By Use Of Cluster Lists. If You Want Multiple Route Reflectors For Resilience Then A CLUSTER_LIST Attribute Can Be Configured So That The Route Reflectors Recognise Each Other As Being Part Of The Same Cluster.
You Can Have Multiple Clusters As Well And A Route Reflector Can Determine Whether A Loop Exists By Looking For Its Own Cluster ID In The Cluster List Of The Advertisement. It Is Important That The Route Reflectors Themselves Are Fully Meshed.
You Can Have Multiple Route Reflectors Inside One AS And This Might Break The Normal AS Path Loop Prevention Mechanism. So Normally AS Path Takes Care Of Loop, But Inside The AS It’s Done With Cluster-Id And Originator-Id.
In BGP You Would Need A Full Mesh For All IBGP Client Peerings, To Have Routes Propagated From Client To Client. Route Reflection Overcomes The Need For A Full Mesh. The Route Reflector Reflects Routes Coming From A Client To His Route Reflector Clients.
THE RULES FOR WHEN A REFLECTOR UPDATES ARE AS FOLLOWS:
With These Rules In Hand, You Have To Step Through The Graph Of BGP Sessions In Your Network, Checking Every BGP Router On The Way And Ensuring That The Route Reflector Rules Are Not Violated (And That, Using The Rules, The BGP Prefixes Get From Every Edge Router To All Other Routers).
There Is Another Common Reason An IP Prefix Is Not Propagated Across Your Network: The External Subnets On The Edge Of Your Network Are Not Advertised To Your Core Routers.
The IP Address Of The Next-Hop Router Is Not Changed When An IP Prefix Is Sent To An Internal BGP Neighbor. The IP Next-Hop Of An External Route Is Thus Always The IP Address Of A Router One Hop Beyond The Edge Of Your Autonomous System. The IP Subnets Connecting Your Edge Routers To Their External Neighbors Thus Have To Be Inserted Into Your Internal Routing Protocol (For Example, OSPF Or IS-IS), Otherwise Some Internal BGP Router Will Decide That The BGP Next-Hop Is Not Reachable And Ignore The IP Prefix. (It Will Appear In The BGP Table But Will Not Be Used Or Propagated To Other BGP Peers.)
WHAT IS BGP CONFEDERATIONS?
BGP Autonomous Systems With Fully-Meshed IBGP Peers You Can Divide Up The Routers Into Smaller Private (Member) Ass And Form A Confederation Of Private Ass That Come Together To Produce A Public AS As Far As The External Networks Are Concerned. Confederations Are Described In RFC 1965.
Reserved AS Numbers Used For Private Ass Are 64512 Through To 65535. These Numbers Should Therefore Be Used For The Internal AS Numbers. EBGP Peers In Each Private AS Peer With Each Other And The Whole Confederation Has A Confederation ID Which Is A Legitimate AS Number That External Ass See. The Confederation Structure Itself Is Invisible To The External Ass. Other Ass Connect Using The Confederation AS Number. Normally Next-Hop, Metric And Local Preference Information Is Not Passed Between EBGP Peers, However Within A Confederation This Information Is Shared.
In Order To Prevent Loops From Occurring The AS_PATH Has Two Versions, One Called The AS_CONFED_SEQUENCE That Is An Ordered List Of Ass That Are Internal To The Confederation, And The Other Called The AS_CONFED_SET That Is An Unordered List Of Ass.
NOTE :In Large Ass Confederations Can Be Used In Conjunction With Route Reflectors.
BGP CONFEDERATION OPERATION:
A Member Of A BGP Confederation Will Use Its AS Confederation ID In All Transactions With Peers That Are Not Members Of Its Confederation. This Confederation Identifier Is Considered To Be The "Externally Visible" AS Number And This Number Is Used In OPEN Messages And Advertised In The AS_PATH Attribute.
A Member Of A BGP Confederation Will Use Its Member AS Number In All Transactions With Peers That Are Members Of The Same Confederation As The Given Router.
A BGP Speaker Receiving An AS_PATH Attribute Containing An Autonomous System Matching Its Own Confederation Shall Treat The Path In The Same Fashion As If It Had Received A Path Containing Its Own AS Number.
A BGP Speaker Receiving An AS_PATH Attribute Containing An AS_CONFED_SEQUENCE Or AS_CONFED_SET Which Contains Its Own Member AS Number Shall Treat The Path In The Same Fashion As If It Had Received A Path Containing Its Own AS Number.
TERMS :
AS CONFEDERATION :
A Collection Of Autonomous Systems Advertised As A Single AS Number To BGP Speakers That Are Not Members Of The Confederation.
AS CONFEDERATION IDENTIFIER :
An Externally Visible Autonomous System Number That Identifies The Confederation As A Whole.
MEMBER-AS :
An Autonomous System That Is Contained In A Given AS Confederation. MEMBER-AS NUMBER :
An Autonomous System Number Visible Only Internal To A BGP Confederation.
DIFFERENCES BETWEEN BGP ROUTE REFLECTORS AND BGP ROUTE CONFEDERATIONS :
There Are Two Alternatives To The Full-Mesh BGP Topology, That Are :
BGP CONFEDERATIONS :
With Confederations We Partition The Whole AS Network In Sub-AS, Without Needing To Build A Full-Mesh Topology Between All The BGP Routers Involved In The Network. Each Confederation, Or Sub-Autonomous System, Will Have A Full-Mesh BGP Topology Between The Routers Forming The Confederation. But Between Confederations, The Behaviour Will Be More Like EBGP Sessions With Some Differences (In Fact, It’s Called Confederation BGP, CBGP). Each Confederation Has A Different Sub-AS Number, Usually A Private One (From 64512 To 65534).
Confederations Are Another Method Of Solving The IBGP Full-Mesh Requirement. Confederations Are Smaller Sub-Autonomous Systems Created Within The Primary Autonomous System To Decrease The Number Of BGP Peer Connections.
BGP Confederation Is Breaking Up Your IBGP Domain Into Sub-Autonomous Systems To Change The Behavior Of How IBGP Works.
Confederations Are Another Method Of Reducing The IBGP Mesh Requirements. It Is A Technique To Subdivide A Single AS Into Multiple, Internal Sub-AS’s, Yet Still Advertise A Single AS To External Peers. Within Each Sub-AS (Confederated AS) The Normal Rules Of IBGP Meshing Still Apply, But EBGP Is Run Between The Confederated AS.
In A Confederation, The AS Is Split Into A Number Of Sub-ASes, So The IBGP Full Mesh Is Done Within Each Sub-AS And A Modified Version Of EBGP Is Used Between Sub-ASes. To The Outside, The Confederation Behaves Like A Single AS.
FIVE STEPS ARE USED IN THE CONFIGURATION OF CONFEDERATIONS :
1) Enable BGP Using The Member Autonomous System Number.
2) Configure The Confederation Identifier Using The BGP Confederation Identifier Command.
3) Configure Fully Meshed IBGP Sub-Autonomous System Neighbor Relationships Using The Sub-Autonomous System Number As The Remote Autonomous System Number (ASN) For All Internal IBGP Peers.
4) Configure Other Neighbors Within The Same Parent Autonomous System By Specifying Their Sub-Autonomous System Number As The Remote Autonomous System Number; Other Confederation Peers From Different Subautonomous Systems Must Also Be Identified As External Confederation Peers Using The BGP Confederation Peers Command.
5) Configure Any EBGP Neighbor As You Normally Would.
BGP CONFEDERATIONS CAN HAVE THREE TYPES OF BGP SESSIONS :
1) Regular IBGP Sessions : With Routers Inside The Same Sub-As. All These Routers Having IBGP Sessions Must Have The Same Asn To Identify The BGP Process (64990 And 64991 In Our Topology). Furthermore, It’s Necessary To Build A Full-Mesh IBGP Topology Inside Each Sub-As. All The Rules For IBGP Sessions Apply Here.
2) CBGP Sessions : The BGP Session Built Between Sub-As Is Called CBGP (Confederation BGP), And Its Characteristics Are A Mix Between IBGP And EBGP Sessions. The Topology Between Sub-As Doesn’t Need To Be Full-Mesh.
3) Regular EBGP Sessions: The Whole Confederations System Behaves As A Unique ASn Towards EBGP Sessions. All The Rules For EBGP Sessions Apply Here.
BENEFITS AND CONCERNS OF USING CONFEDERATIONS ARE :
USEFUL POINTS TO ALWAYS REMEMBER :
ROUTE REFLECTORS :
BGP Requires That All BGP Peers In The Same Autonomous System Form An IBGP Session With All Peers In The Autonomous System. This Is Too Difficult In Many Environments. Route Reflectors Are Fully Functional IBGP Speakers That Form IBGP Sessions With Other IBGP Speakers, And They Also Perform A Second Function - They Forward Routes From Other IBGP Speakers To Route Reflector Clients. The Route Reflector Clients And Clients Form A Cluster.
Route Reflectors Distribute IBGP Information From One Router To Another, Which Is Normally Not Allowed In IBGP. Since The Clients Of The Route Reflector Get All IBGP From The Route Reflector They Don't Need To Have IBGP Sessions With All Other BGP Routers. Reflectors Add Additional Path Attributes That Allow Them To Detect And Eliminate Loops.
Route Reflectors Also Change The Behavior Of IBGP, Just Differently With Clients And Non-Clients.
BGP Route Reflectors (RR) Provides A Mechanism For Both Minimizing The Number Of Update Messages Transmitted Within The AS, And Reducing The Amount Of Data That Is Propagated In Each Message. The Deployment Of BGP Route Reflectors Leads To Much Higher Levels Of Network Scalability.
IMPORTANT TO NOTE FOR ROUTE REFLECTORS :
1) Route Reflector Clients Must Not Peer With RR’s Outside Of Their Cluster.
2) RR Clients Must Be One Hop From The RR Server.
3) Route Reflector Servers Still Need To Be Meshed With Non-RR-Clients.
4) Route Reflection Is Only Configured On The RR Server – The RR Clients Are Told Nothing.
5) A Lack Of Redundancy Exists With A RR Server Acting As A Single-Point-Of-Failure.
6) Route Reflection Consumes Resources On The Concentration (Route Reflector Server) Router.
7) Some Vendors Do Not Support The Optional/Nontransitive BGP Attributes Originator ID (Type 9) And Cluster List (Type 10).
8) Still Have N*(N-1)/2 Problem Between RRs (Must Run IBGP) Between RRs In Each Site.
CONSIDER THESE INITIAL TASKS FOR CONFIGURATION TO ROUTE REFLECTORS :
1) Configure The Proper Cluster ID Value On The Route Reflector.
2) Configure The Route Reflector With Information About Which IBGP Neighbor Sessions Are Reaching Their Clients.
3) In The Clients, Remove All IBGP Sessions To Neighbors That Are Not A Route Reflector In The Client Cluster.
4) Make Sure That The IBGP Neighbor Is Removed On Both Ends Of The IBGP Session.
RULES FOR ROUTE REFLECTION AND CLUSTER CONFIGURATION :
1) Each RR (Route Reflector) Sends Updates To All Reflector Clients.
2) RRs In Redundant Configuration (As Here) Must All Have The Same Cluster-Id.
3) If RR-Client Has More Than 1 Connection To An RR (As Here), RRs Must Use Same Cluster-Id.
4) RR-Client Would Not Have Other Non-RR-Client IBGP Sessions To Other RR-Clients.
5) EBGP Sessions To Other Ass Should Be Normally Done At Designated RR-Clients (Except In Case Of A Routeserver RR In A Public Exchange).
6) Each RR Must Be Fully Meshed With All Other RRs In Same Cluster (In This Example Case K2 Mesh).
RULES ON THE PEER TYPE :
1) ROUTES FROM A NONCLIENT PEER — Reflects To All The Clients Within The Cluster.
2) ROUTES FROM A CLIENT PEER — Reflects To All The Nonclient Peers And Also To The Client Peers.
3) ROUTES FROM AN EBGP PEER — Sends The Update To All Client And Nonclient Peers.
EXAMPLE :
The Command Used To Configure The Cluster ID If The BGP Cluster Has Redundant Route Reflectors Is As Follows:
Syntax :
The Command Used To Configure The Router As A BGP Route Reflector And Configure The Specified Neighbor As Its Client Is As Follows:
To Configure One Router As A Route Reflector, You Simply Configure A Neighbor Command With The Route-Reflector-Client Keyword For Those Neighbor Devices That Will Be Client Peers:
Router2(Config)#Router BGP 65500
Router2(Config-Router)#No Synchronization
Router2(Config-Router)#Neighbor 172.18.6.1 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.1 Route-Reflector-Client
Router2(Config-Router)#Neighbor 172.18.6.1 Update-Source Loopback0
Router2(Config-Router)#Neighbor 172.18.6.3 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.3 Route-Reflector-Client
Router2(Config-Router)#Neighbor 172.18.6.3 Update-Source Loopback0
Router2(Config-Router)#Neighbor 172.18.6.4 Remote-As 65500
Router2(Config-Router)#Neighbor 172.18.6.4 Update-Source Loopback0
Router2(Config-Router)#No Auto-Summary
Router2(Config-Router)#Exit
This Specifies That The Two Peers, 172.18.6.1 And 172.18.6.3, Are Client Peers. We Have Not Included A Neighbor Route-Reflector-Client Command For The Other Neighbor, 172.18.6.4, Making It A Nonclient Peer Of This Route Reflector.
There Is No Special Configuration Required On Either Client Or Nonclient Peer Routers And, Indeed, These Devices Don't Even Know Or Care About The Difference. The Only Router That Needs To Do Anything Special Is The Route Reflector Itself.
CLUSTER-ID :
NOTE : When Configuring Two Or More Redundant BGP Route Reflectors, Though, Another Little Trick Is Required.
As The Two Route Reflectors Hear About Every Reflected Routing Prefix Both From The Original Source And From The Other Route Reflector. This Could Cause Strange Behavior If The Real Source Of The Route Becomes Unavailable. The Two Route Reflectors Will Both Believe That The Route Is Reachable Through One Another.
To Prevent This Problem, We Need To Specify A Cluster ID On Each Route Reflector To Identify A Particular Group Of Client Peers:
Routera#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router 4(Config)#Router BGP 65500
Router 4(Config-Router)#BGP Cluster-Id 1234
And You Need To Configure The Same Cluster ID On The Other Route Reflector :
Router 4#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router 4(Config)#Router BGP 65500
Router 4(Config-Router)#BGP Cluster-Id 1234
NOTE :There Is One Important Caveat About Implementing Cluster Ids, However. In A Case Like This One, Where We Had One Router Acting As A Route Reflector, And We Wanted To Either Implement A New Cluster ID, Or To Change An Existing One, We Had To Manually Remove The Client Peer Configuration From The Route Reflector First.
Then We Configured The Cluster-Id Command And Replaced The Client Peer Neighbor Configuration Statements.
When Working With Route Reflectors, We Strongly Recommend Implementing Two Or More Redundant Reflectors. If You Have A Single Reflector For A Large Network, Then This Becomes A Dangerous Single Point Of Failure For Your Entire BGP Routing Infrastructure.
CISCO – BGP LAB FOR ROUTE REFLECTORS CLIENT:
BEFORE START THE LAB PLZ NOTE IT IMPORTANT POINTS :
STEP BY STEP LAB GUIDANCE FOR ROUTE REFLECTED CLIENT
Router> - User Exec Mode
Router# - Privileged Exec Mode
Router(Config)# - Configuration Mode (Notice The # Sign Indicates This Is Only Accessible At Privileged Exec Mode.)
Router(Config-If)# - Interface Level Within Configuration Mode.
Router(Config-Router)# - Routing Engine Level Within Configuration Mode.
SAVING CONFIGURATIONS - ALWAYS ISSUE THIS COMMAND AFTER EACH CONFIGURATION :
Router# Copy Running-Config Startup-Config - Saves Configuration Into NVRAM
A Cisco IOS Router Stores Configurations In Two Locations - RAM And NVRAM. The Running Configuration Is Stored In RAM And Is Used By The Router During Operation. Any Configuration Changes To The Router Are Made To The Running-Configuration And Take Effect Immediately After The Command Is Entered.
The Startup-Configuration Is Saved In NVRAM And Is Loaded Into The Router's Running-Configuration When The Router Boots Up. If A Router Loses Power Or Is Reloaded, Changes To The Running Configuration Will Be Lost Unless They Are Saved To The Startup-Configuration.
To Save The Running-Configuration To The Startup Configuration, Type The Following From Privileged EXEC Mode (I.E. At The "Router#" Prompt.)
Router# Copy Running-Config Startup-Config
TO TROUBLESHOOT AND DISPLAY BGP COMMANDS :
Router #Show IP BGP Neighbor IP-Address - > Displays Detailed Neighbor Information
Router #Show IP BGP - > Displays All The Routes In The BGP Table
Router #Show IP BGP IP-Prefix [Mask Subnet-Mask] - > Displays Detailed Information About All Paths For A Single Prefix
Router #Debug IP TCP Transactions - > Displays All TCP Transactions
Router #Debug IP BGP Events - > Displays Significant BGP Events
Router #Debug IP BGP Keepalives - > Debugs BGP Keepalive Packets
Router #Debug IP BGP Updates - > Displays All Incoming Or Outgoing BGP Updates.
Router #Debug IP BGP Updates Acl - > Displays All Incoming And Sent Updates Matching An ACL
Router #Debug UP BGP Ip-Address Update [Acl] - > Displays All BGP Updates Received From Or Sent To A Specific Neighbor
TO CHECK YOUR BGP TABLE :
Router#CLEAR IP BGP* SOFT
Router#SHOW IP BGP
Router##SHOW IP BGP NEIGHBOR
Router#SHOW IP BGP SUMMARY
TO CHECK YOUR ROUTING TABLE :
Router#SHOW IP INT BRIEF
Router#CLEAR IP ROUTE*
Router#SHOW IP ROUTE
Router#SHOW RUN
CONFIGURATION ON ROUTER A:
Router>enable (Switches To Privileged EXEC Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router A (Assign Host Name To Router A)
Router A(Config)#
INTERFACE E0 CONFIGURATION ON ROUTER A:
Router A(Config)#int e0 (Switches To Configure The E0 Interface)
Router A(Config-if)#IP address 10.0.0.1 255.0.0.0 (Configures An IP Address On Ethernet0 (Interface))
Router A(Config-if)#No shutdown (Activates Serial0 (Interface))
Router A(Config-if)#No Keepalive (Keepalive Packets Are Disabled On The Interface To Pass Through Other Interface)
Router A(Config-if)#Exit (Exits Back To Global Configuration Level)
KEEPALIVE :
A Keepalive Is A Message Sent By One Device To Another To Check That The Link Between The Two Is Operating, Or To Prevent This Link From Being Broken. No Keepalive Will Be Bringing Down The Interface Or Before Bringing The Tunnel Protocol Down For A Specific Interface.
NOTE :If You Enter The No Keepalive Command, Keepalive Packets Are Disabled On The Interface.
Router A(Config)#Exit
Router A# Copy Running-Config Startup-Config (Saves Configuration Into NVRAM)
INTERFACE SERIAL S1 CONFIGURATION ON ROUTER A:
Router A#Conf T
Router A(Config)#Int s1 (Switches To Configure The Serial1 Interface)
Router A(Config-if)#Ip address 20.0.0.1 255.0.0.0
Router A(Config-if)#No shut (Enable An Interface)
Router A(Config-if)# Clock Rate 56000 (Set The Clock Rate 56000 For DCE Interface)
Router A(Config-if)# Bandwidth 64 (Set A Logical Bandwidth Assignment Of 64k To The Serial Interface)
To Enable The Back-To-Back Serial Connection Between Two Routers, You Need To Configure One Router As DCE Using The Following Command In Interface Configuration Mode For The Serial Connection On Two different Routers.
Router A(Config-if)#Exit
ROUTER - DTE / DCE :
In A Real-Life Network, Your Serial Interfaces Will Almost Certainly Be Configured As DTE Interfaces. Recall That A CSU/DSU Usually Handles The Clocking For A Synchronous Serial Interface.
The DCE-To-DTE Crossover Cable Will Have Two Different DB-60 Interfaces – One Marked DTE, And The Other Marked DCE. The Router Connected To The DCE End Of The Cable Will Need Its Serial Interface Configured As A DCE Device.
NOTE : If Your Device Is The DCE, You Must Provide Clocking Using The Clock Rate Command.
Example - > Router A(Config-if)# Clock Rate 56000
Router A(Config-if)#^Z
Router A#
Router A# Copy Running-Config Startup-Config
Router A#SHOW RUN
Router A#SHOW IP ROUTE
BGP PEERS CONFIGURATION ON ROUTER A:
Router A(Config)#Router BGP 10 (This Command To Configure A Fixed Router ID As An Identifier Of The Router Running BGP.)
BGP ROUTER-ID :
To Configure A Fixed Router ID For A BGP-Speaking Router, Use The BGP Router-Id Command In Router Configuration Mode. To Remove The BGP Router-ID Command From The Configuration File And Restore The Default Value Of The Router ID, Use The No BGP Router IDForm Of This Command.
Default The Router ID Is Set To The IP Address Of A Loopback Interface If One Is Configured. If No Virtual Interfaces Are Configured, The Highest IP Address Is Configured For A Physical Interface On That Router. Peering Sessions Will Be Reset If The Router ID Is Changed.
Router A(Config-Router)#Neighbor 20.0.0.2 remote-as 20
To Configure The Border Gateway Protocol (BGP) Routing Process, Use The Router BGP Command In Global Configuration Mode. The Above Example Configures A BGP Process For Autonomous System20).
Router A(Config-Router)#Network 10.0.0.0 (Advertised Route To The Network Specified Must Be Present In The Routing Table.)
Router A(Config-Router)#Network 20.0.0.0 (Advertised Route To The Network Specified Must Be Present In The Routing Table.)
Router A(Config-Router)#Exit (Or ^Z It will Go To Router A#)
Router A(Config)#Exit
Router A#
Router A# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER A (USE ALL THESE COMMANDS BY THIS ORDERS) :
Router A#CLEAR IP BGP* SOFT
The CLEAR IP BGP Command Can Be Used To Initiate A Hard Reset Or Soft Reconfiguration. A Hard Reset Tears Down And Rebuilds The Specified Peering Sessions And Rebuilds The BGP Routing Tables. A Soft Reconfiguration Uses Stored Prefix Information To Reconfigure And Activate BGP Routing Tables Without Tearing Down Existing Peering Sessions. Soft Reconfiguration Uses Stored Update Information, At The Cost Of Additional Memory For Storing The Updates, To Allow You To Apply New BGP Policy Without Disrupting The Network. Soft Reconfiguration Can Be Configured For Inbound Or Outbound Sessions.
Router A#CLEAR IP ROUTE*
Removes From The IP Routing Table From The IP Routing Table.
Router A#SHOW IP BGP NEIGHBOR
To Display Information About The TCP And BGP Connections To Neighbors, Use The Show IP BGP Neighbors Command In EXEC Mode.
Router A#SHOW IP BGP
To Display Entries In The BGP Routing Table, Use The Show IP BGP Command In EXEC Mode.
Router A#SHow IP ROUTE
To Display The Current State Of The Routing Table, Use The Show Ip Route Command In EXEC Mode.
Router A#SHOW IP INT BRIEF
Interface Commands (Show Ip Interface), To Display The Usability Status Of Interfaces Configured For IP, Use The Show Ip Interface Command In Privileged EXEC Mode.
Show Ip Interface [Type Number] [Brief]
CONFIGURATION ON ROUTER B:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router B (Assign Host Name To Router B)
Router B(Config)#
INTERFACE S0 CONFIGURATION ON ROUTER B:
Router B(Config)#Int S0
Router B(Config-if)#IP Address 20.0.0.2 255.0.0.0
Router B(Config-if)#No shutdown
Router B(Config-if)# Bandwidth 64
Router B(Config-if)#Exit
Router B(Config)#Exit
Router B# Copy Running-Config Startup-Config
INTERFACE S1 CONFIGURATION ON ROUTER B:
Router B(Config)#Int S1
Router B(Config-if)#IP Address 30.0.0.1 255.0.0.0
Router B(Config-if)#No shutdown
Router B(Config-if)#Clock Rate 56000
Router B(Config-if)# Bandwidth 64
Router B(Config-if)#Exit OR (^Z)
Router B(Config)#Exit
Router B# Copy Running-Config Startup-Config
BGP PEERS CONFIGURATION ON ROUTER B:
Router B#Conf T
Router B(Config)#Router BGP 65512
Router B(Config-Router)#Neighbor 20.0.0.1 remote-as 10
Router B(Config-Router)#Neighbor 30.0.0.1 remote-as 65512
Router B(Config-Router)#BGP confederation identifier 20 (The BGP Confederation Identifier Command Is Used To Configure A Single Autonomous System Number To Identify A Group Of Smaller Autonomous Systems As A Single Confederation).
BGP CONFEDERATION IDENTIFIER :
To Specify A BGP Confederation Identifier, Use The BGP Confederation Identifier Command In Router Configuration Mode.
To Enables To You To Retain A Single Interior Gateway Protocol (IGP) For All The Autonomous Systems. To The Outside World, The Confederation Looks Like A Single Autonomous System.
A Confederation Can Be Used To Reduce The Internal BGP (IBGP) Mesh By Dividing A Large Single Autonomous System Into Multiple Sub-Autonomous Systems And Then Grouping Them Into A Single Confederation. The Sub-Autonomous Systems Within The Confederation Exchange Routing Information Like IBGP Peers. External Peers Interact With The Confederation As If It Is A Single Autonomous System.
Each Sub-Autonomous System Is Fully Meshed Within Itself And Has A Few Connections To Other Autonomous Systems Within The Confederation. Next Hop, Multi Exit Discriminator (MED), And Local Preference Information Is Preserved Throughout The Confederation, Allowing You Enables To You To Retain A Single Interior Gateway Protocol (IGP) For All The Autonomous Systems.
Router B(Config-Router)#^z
Router B#
Router B# Copy Running-Config Startup-Config
Router B#SHOW RUN
Router B#SHOW IP ROUTE
THEN CHECK IT ON THE ROUTER B (USE ALL THESE COMMANDS BY THIS ORDER) :
Router B#SHOW IP INT BRIEF
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
Router B##SHOW IP BGP NEIGHBOR
Router B#CLEAR IP ROUTE*
Router B#SHOW IP ROUTE
Router B#SHOW RUN
CONFIGURATION ON ROUTER C:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router C (Assign Host Name To Router C)
Router C(Config)#
INTERFACE S0 CONFIGURATION ON ROUTER C:
Router C(Config)#Int S0
Router C(Config-if)#IP Address 30.0.0.2 255.0.0.0
Router C(Config-if)#No shutdown
Router C(Config-if)# Bandwidth 64
Router C(Config-if)#Exit
Router C(Config)#Exit
Router C#Copy Running-Config Startup-Config
INTERFACE S1 CONFIGURATION ON ROUTER C:
Router C(Config)#Int S1
Router C(Config-if)#IP Address 40.0.0.1 255.0.0.0
Router C(Config-if)#No shutdown
Router C(Config-if)#Clock Rate 56000
Router C(Config-if)# Bandwidth 64
Router C(Config-if)#Exit OR (^Z)
Router C(Config)#Exit
Router C# Copy Running-Config Startup-Config
Router C#SHOW RUN
Router C#SHOW IP ROUTE
BGP PEERS CONFIGURATION WITH PRIVATE AS ON ROUTER C :
Router C#Conf T
Router C(Config)#Router BGP 65512
Router C(Config-Router)#Neighbor 30.0.0.1 remote-as 65512
Router C(Config-Router)#Neighbor 40.0.0.2 remote-as 65517
Router C(Config-Router)#BGP confederation identifier 20
Router C(Config-Router)#^z
Router C#
Router C# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER C (USE ALL THESE COMMANDS BY THIS ORDER) :
Router C#SHOW IP INT BRIEF
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
Router C##SHOW IP BGP NEIGHBOR
Router C#CLEAR IP ROUTE*
Router C#SHOW IP ROUTE
Router C#SHOW RUN
CONFIGURATION ON ROUTER D:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router D (Assign Host Name To Router D)
Router D(Config)#
INTERFACE S0 CONFIGURATION ON ROUTER D:
Router D(Config)#Int S0
Router D(Config-if)#IP Address 40.0.0.2 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
INTERFACE S1 CONFIGURATION ON ROUTER D:
Router D(Config)#Int S1
Router D(Config-if)#IP Address 50.0.0.1 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)#Clock Rate 56000
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit OR (^Z)
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
Router D#SHOW RUN
Router D#SHOW IP ROUTE
BGP PEERS CONFIGURATION WITH PRIVATE AS (65517 - > 65512) ON ROUTER D :
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#Neighbor 40.0.0.1 remote-as 65512
Router D(Config-Router)#Neighbor 50.0.0.2 remote-as 65517
Router D(Config-Router)#BGP confederation identifier 20
Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER D (USE ALL THESE COMMANDS BY THIS ORDER) :
Router D#SHOW IP INT BRIEF
Router D#CLEAR IP BGP* SOFT
Router D#SHOW IP BGP
Router D##SHOW IP BGP NEIGHBOR
Router D#CLEAR IP ROUTE*
Router D#SHOW IP ROUTE
Router D#SHOW RUN
CONFIGURATION ON ROUTER E:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router E (Assign Host Name To Router E)
Router E(Config)#
INTERFACE S0 CONFIGURATION ON ROUTER E:
Router E(Config)#Int S0
Router E(Config-if)#IP Address 50.0.0.2 255.0.0.0
Router E(Config-if)#No shutdown
Router E(Config-if)# Bandwidth 64
Router E(Config-if)#Exit
Router E(Config)#Exit
Router E# Copy Running-Config Startup-Config
INTERFACE S1 CONFIGURATION ON ROUTER E:
Router E(Config)#Int S1
Router E(Config-if)#IP Address 60.0.0.1 255.0.0.0
Router E(Config-if)#No shutdown
Router E(Config-if)#Clock Rate 56000
Router E(Config-if)# Bandwidth 64
Router E(Config-if)#Exit OR (^Z)
Router E(Config)#Exit
Router E# Copy Running-Config Startup-Config
Router E#SHOW RUN
Router E#SHOW IP ROUTE
BGP PEERS CONFIGURATION WITH PRIVATE AS ON ROUTER E :
Router E#Conf T
Router E(Config)#Router BGP 65517
Router E(Config-Router)#Neighbor 50.0.0.1 remote-as 65517
Router E(Config-Router)#Neighbor 60.0.0.2 remote-as 30
Router E(Config-Router)#BGP confederation identifier 20
Router E(Config-Router)#^z
Router E#
Router E# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER E (USE ALL THESE COMMANDS BY THIS ORDER) :
Router E#SHOW IP INT BRIEF
Router E#CLEAR IP BGP* SOFT
Router E#SHOW IP BGP
Router E##SHOW IP BGP NEIGHBOR
Router E#CLEAR IP ROUTE*
Router E#SHOW IP ROUTE
Router E#SHOW RUN
CONFIGURATION ON ROUTER F:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router F (Assign Host Name To Router F)
Router F(Config)#
INTERFACE E0 CONFIGURATION ON ROUTER F:
Router F(Config)#Int e0
Router F(Config-if)#IP Address 70.0.0.1 255.0.0.0
Router F(Config-if)#No shutdown
Router F(Config-if)#No Keepalive
Router F(Config-if)#Exit
Router F(Config)#Exit
Router F# Copy Running-Config Startup-Config
INTERFACE S1 CONFIGURATION ON ROUTER F:
Router F(Config)#Int S0
Router F(Config-if)#IP Address 60.0.0.2 255.0.0.0
Router F(Config-if)#No shutdown
Router F(Config-if)# Bandwidth 64
Router F(Config-if)#Exit OR (^Z)
Router F(Config)#Exit
Router F# Copy Running-Config Startup-Config
Router F#SHOW RUN
Router F#SHOW IP ROUTE
BGP PEERS CONFIGURATION ON ROUTER F :
Router F#Conf T
Router F(Config)#Router BGP 30
Router F(Config-Router)#Neighbor 60.0.0.1 remote-as 20
Router F(Config-Router)#Network 60.0.0.0
Router F(Config-Router)#Network 70.0.0.0
Router F(Config-Router)#^z
Router F#
Router F# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER F (USE ALL THESE COMMANDS BY THIS ORDER) :
Router F#SHOW IP INT BRIEF
Router F#CLEAR IP BGP* SOFT
Router F#SHOW IP BGP
Router F##SHOW IP BGP NEIGHBOR
Router F#CLEAR IP ROUTE*
Router F#SHOW IP ROUTE
Router F#SHOW RUN
DIFFERENT CONFEDERATION PEER, TO MAKE A SINGLE CONFEDERATION PEER CONNECTION SUCH AS 65512 VS 65517 :
STEP 1:
Making Connection In Between Two Each Private AS Such As AS 65512 And 65517).
ROUTER C (AS 65512) < ----- > ROUTER D (AS 65517)
Router C#Conf T
Router C(Config)#Router BGP 65512
Router C(Config-Router)#BGP Confederation Peers 65517 (To Configure Sub- Autonomous Systems To Belong To A Single Confederation, Use The BGP Confederation Peers Command In Router Configuration Mode.)
BGP CONFEDERATION PEERS:
To Configure Sub-Autonomous Systems To Belong To A Single Confederation, Use The BGP Confederation Peers Command In Router Configuration Mode. To Remove An Autonomous System From The Confederation, Use The No Form Of This Command.
The BGP Confederation Peers Command Is Used To Configure Multiple Autonomous Systems As A Single Confederation. The Ellipsis (...) In The Command Syntax Indicates That Your Command Input Can Include Multiple Values For The As-Number Argument.
The Autonomous Systems Specified In This Command Are Visible Internally To The Confederation. Each Autonomous System Is Fully Meshed Within Itself. The BGP Confederation Identifier Command Specifies The Confederation To Which The Autonomous Systems Belong.
Router C(Config-Router)#^z
Router C#
Router C# Copy Running-Config Startup-Config
THEN GO TO ROUTER D:
STEP 2:
Making Connection In Between Two Each Private AS Such As AS 65512 And 65517).
ROUTER C (AS 65512) < ----- > ROUTER D (AS 65517)
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#BGP Confederation Peers 65512 Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
THEN CHECK IT ON THE ROUTER C & ROUTER D (USE ALL THESE COMMANDS BY THIS ORDER) :
Router F#SHOW IP INT BRIEF
#CLEAR IP BGP* SOFT
#SHOW IP BGP
#SHOW IP BGP NEIGHBOR
#SHOW IP BGP SUMMARY
#CLEAR IP ROUTE*
F#SHOW IP ROUTE
#SHOW RUN
#TRACEROUTE 10.0.0.1
PING AND TRACEROUTE :
The Ping And Traceroute Commands Are Convenient, Frequently Used Tools For Checking Network Connectivity And Troubleshooting Network Problems. The Ping Command Determines Whether A Specific IP Address Is Online By Sending Out A Packet And Waiting For A Response. The Traceroute Command Provides The Path From The Source To The Remote Destination Being Contacted.
PING :
The Ping Command Is A Common Method For Troubleshooting The Accessibility Of Devices. It Uses Two Internet Control Message Protocol (ICMP) Query Messages, ICMP Echo Requests, And ICMP Echo Replies To Determine Whether A Remote Host Is Active. The Ping Command Also Measures The Amount Of Time It Takes To Receive The Echo Reply.
The Ping Command First Sends An Echo Request Packet To An Address, And Then It Waits For A Reply. The Ping Is Successful Only If The Echo Request Gets To The Destination, And The Destination Is Able To Get An Echo Reply (Hostname Is Alive) Back To The Source Of The Ping Within A Predefined Time Interval.
TRACEROUTE :
Where The Ping Command Can Be Used To Verify Connectivity Between Devices, The Traceroute Command Can Be Used To Discover The Paths Packets Take To A Remote Destination And Where Routing Breaks Down.
The Traceroute Command Records The Source Of Each ICMP "Time-Exceeded" Message To Provide A Trace Of The Path That The Packet Took To Reach The Destination. You Can Use The IP Traceroute Command To Identify The Path That Packets Take Through The Network On A Hop-By-Hop Basis. The Command Output Displays All Network Layer (Layer 3) Devices, Such As Routers, That The Traffic Passes Through On The Way To The Destination.
The Traceroute Command Uses The Time To Live (TTL) Field In The IP Header To Cause Routers And Servers To Generate Specific Return Messages. The Traceroute Command Sends A User Datagram Protocol (UDP) Datagram To The Destination Host With The TTL Field Set To 1. If A Router Finds A TTL Value Of 1 Or 0, It Drops The Datagram And Sends Back An ICMP Time-Exceeded Message To The Sender. The Traceroute Facility Determines The Address Of The First Hop By Examining The Source Address Field Of The ICMP Time-Exceeded Message.
To Identify The Next Hop, The Traceroute Command Sends A UDP Packet With A TTL Value Of 2. The First Router Decrements The TTL Field By 1 And Sends The Datagram To The Next Router. The Second Router Sees A TTL Value Of 1, Discards The Datagram, And Returns The Time-Exceeded Message To The Source. This Process Continues Until The TTL Increments To A Value Large Enough For The Datagram To Reach The Destination Host (Or Until The Maximum TTL Is Reached).
To Determine When A Datagram Reaches Its Destination, The Traceroute Command Sets The UDP Destination Port In The Datagram To A Very Large Value That The Destination Host Is Unlikely To Be Using. When A Host Receives A Datagram With An Unrecognized Port Number, It Sends An ICMP Port Unreachable Error To The Source. This Message Indicates To The Traceroute Facility That It Has Reached The Destination.
TO SOLVE THE RECHABLITE PROBLEMS FROM ROUTER A - > TOWARDS TO ROUTER F:
FIRST KNOW WHAT IS REACHABILITY ISSUES?
Reachability Issues When Interfaces Other Than Directly Connected Interfaces Are Used While Peering.
Border Gateway Protocol (BGP), The De-Facto Inter-Domain Routing Protocol, Can Adapt To Failures By Converging To A New Set Of Valid Paths. However, The Routing Adjustment May Take A Long Time Due To Various Delays In The Propagation Of Update Messages And The Exploration Of Alternative Paths.
As A Result, The Period Of Destination Unreachability Can Be Substantially Longer Than The Time Period Of Actual Physical Connectivity Losses. BGP Convergence Time Without Considering The Impact On Packet Delivery. Packet Delivery Performance Is Related, But Not Equivalent, To The Routing Convergence Time.
Path Vector Messages In BGP: The Autonomous System Boundary Routers (ASBR), Which Participate In Path Vector Routing, Advertise The Reachability Of Networks. Each Router That Receives A Path Vector Message Must Verify That The Advertised Path Is According To Its Policy. If The Messages Comply With The Policy, The ASBR Modifies Its Routing Table And The Message Before Sending It To The Next Neighbor. In The Modified Message It Sends Its Own AS Number And Replaces The Next Router Entry With Its Own Identification.
BGP ROUTES INJECTION PROCESS: The BGP Process Injects Local Routes In Two Different Ways:
If Certain BGP Routes Are Missing From The Routing Table, Determine If They Are Learned Through BGP And Exist In The BGP Table. Routes Existing In The BGP Table Might Be Missing From The Routing Table Due To The BGP Synchronization Rule Or Due To The Non-Availability Of A Valid Route To The Next Hop. If The Routes Are Missing From The BGP Table Altogether, Determine If The Peering Has Been Successful, And Check For The Existence Of Route Filters. If BGP Routes Are Not Being Advertised, Check If The Conditions For Advertising BGP Routes Are Being Satisfied.
An Internal Border Gateway Protocol (IBGP) Learned Route Is Not Advertised To Other IBGP Peers, And Configuring A Route Reflector Might Be Necessary.
Aggregate Routes Are Not Advertised Unless At Least One Component Route Exists In The BGP Table.
Similarly, Routes Advertised By Issuing The BGP Network Command Are Also Subject To The Existence Of Corresponding Routes In The Routing Table.
Ensure That BGP Routers Are Able To Cope With The High Amount Of Routing Information That Is Typically Exchanged Between Routers Configured For BGP.
If Cannot Be Measured By Examining The Routing Tables At All The Routers At Time, Because It Takes Time For A Packet To Propagate Through The Network And The Routing Tables May Change During This Time Period. 1Minimum Route Announcement Interval, Which Is Used To Space Out Consecutive Route Announcement Messages (“Reachability msg”).
NOTE: In Such Cases, Additional Configuration Might Be Required.
NOTE: (According To Our Topology) REHABILITEE & BEST PATH PROBLEMS SHOULD BE SOLVE IN: (Neighbor
TO SOLVE THE RECHABLITE PROBLEMS ON ROUTER C TOWARDS TO ROUTER B & ROUTER D:
STEP 1:
ROUTER C RECHABILITY PROBLEM TO BE SOLVING ON ROUTER B & ROUTER D:
ROUTER B (30.0.0.1) <---------> (30.0.0.2) ROUTER C (40.0.0.1) <---------> (40.0.0.2) ROUTER D
For Router B Receiving Point From Router C. So giving This Command On Router B. (Neighbor Next-Hop-Self Address Is 30.0.0.2).
Router B(config)#Router BGP 65512
Router B(config-Router)#Neighbor 30.0.0.2 next-hop-self.
Router B(config-Router)#^z
NEXT-HOP-SELF:
Router(config-router)#Neighbor {ip-address | peer-group-name} next-hop-self - > Disables next hop processing on BGP updates to a neighbor.
Configuring This Command Causes The Current Router To Advertise Its Peering Address As The Next Hop For The Specified Neighbor. Therefore, Other BGP Neighbors Will Forward To It Packets For That Address.
This Configuration Is Useful In A Nonmeshed Environment Because You Know That A Path Exists From The Present Router To That Address. In A Fully Meshed Environment, This Configuration Is Not Useful Because It Will Result In Unnecessary Extra Hops And Because There Might Be A Direct Access Through The Fully Meshed Cloud With Fewer Hops.
STEP 1 - 002 :
ROUTER C RECHABILITY PROBLEM (ROUTER C - > ROUTER D) TO BE SOLVING ON ROUTER D:
ROUTER B (30.0.0.1) <---------> (30.0.0.2) ROUTER C (40.0.0.1) <---------> (40.0.0.2) ROUTER D
Router D(Config)#Router BGP 65512
Router D(Config-Router)#neighbor 40.0.0.1 next-hop-self
Router D(Config-Router)^z
STEP 1 - 003 :
THEN GO TO ROUTER C AND CHECK IT:
Router C#CLEAR IP BGP* SOFT (Refresh New Entries)
Router C#CLEAR IP BGP*
Then - > Give This Command
Router C#SHOW IP BGP
THERE IS NO BEST PATH ON ROUTER C
STEP 1 - 004 :
ROUTER C BEST PATH:
So Now Reachability Problem Is Solve In Router C From Router B. But The Best Path Is Still Not So - > Going To Solve This (Give This Command).
Router C(config)#Router BGP 65512
Router C(config-router)#No Synchronization (Disables Synchronization Between BGP And An IGP - > Best Path From Router C To Router B)
Router C(config-router)Z
If Will Not Be Passing Traffic From A Different Autonomous System Through Your Autonomous System, Or If All Routers In Your Autonomous System Will Be Running BGP, You Can Disable Synchronization. Disabling This Feature Can Allow You To Carry Fewer Routes In Your IGP And Allow BGP To Converge More Quickly.
So Now Router C Reachability Problem and Best Path are Is Solved.
STEP 1 - 005 :
THEN GO TO ROUTER C AND CHECK IT:
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem And The Best Path Are Solved.
STEP 2 - 001 :
ON ROUTER D RECHABILITY PROBLEM TO BE SOLVING ON ROUTER C & ROUTER E :
ROUTER B (30.0.0.1) <---------> (30.0.0.2) ROUTER C (40.0.0.1) <---------> (40.0.0.2) ROUTER D (50.0.01) <---------> (50.0.0.2) ROUTER E (60.0.0.1)
For Router C Receiving Point From Router C (40.0.0.2) and Router E (50.0.0.1) .
Router C(config)#Router BGP 65512
Router C(config-Router)#neighbor 40.0.0.2 next-hop-self.
Router C(config-Router)#^z
One Side (On Router C) Receiving Point Is Ok But Other Side (Router E) Still Having Reachability Problem. Should Be Solving On Router E.
STEP 2 - 002 :
Router E(config)#Router BGP 65517
Router E(config-Router)#neighbor 50.0.0.1 next-hop-self.
Router E(config-Router)#^z
STEP 2 - 003 :
THEN GO TO ROUTER C AND CHECK IT :
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem Is Solved But The Best Path Is Not Yet Solve. So Give This Command On Router D “Router D(Config-Router)# No Synchronization”
STEP 2 - 004 :
THERE IS NO BEST PATH
FOR ROUTER C BEST PATH SHOULD BE ON ROUTER B & ROUTER D,ON ROUTER B WE ALLLMOST DONE:
Router D(config)#Router BGP 65517
Router D(config-router)#No Synchronization
Router D(config-router)Z
STEP 1 - 005 :
THEN GO TO ROUTER C AND CHECK IT:
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
NOTE :When Checked On Router C Reachability Problem And The Best Path Are Solved Now.
STEP 3 - 001 :
Router D(Config)#Router BGP 65517
Router D(Config-Router)# Neighbor 50.0.0.2 next-hop-self.
Router D(config-Router)#^z
THEN GO TO ROUTER E AND CHECK IT :
Router E#CLEAR IP BGP* SOFT
Router E#SHOW IP BGP
STEP 3 - 003 :
THERE IS NO BEST PATH ON ROUTER E
FOR BEST PATH ROUTER E :
Router E(config)#Router BGP 65517
Router E(config-router)#No Synchronization
Router E(config-router)Z
STEP 4 - 001 :
To Solve Router B Reachability Problem On Router B Go To Router C.
Router C(Config)#Router BGP 65512
Router D(Config-Router)# Neighbor 30.0.0.1 next-hop-self.
Router D(config-Router)#^z
THEN GO TO ROUTER B AND CHECK IT :
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
THERE IS NO BEST PATH
STEP 4 - 002 :
FOR BEST PATH ON ROUTER B :
Router B(config)#Router BGP 65517
Router B(config-router)#No Synchronization
Router B(config-router)Z
THEN CHECK IT ON ROUTER B :
Router B#CLEAR IP BGP* SOFT
Router B#SHOW IP BGP
NOTE: Now Each And Every Reachability And Best Path Problems Has Been Solved From Router A - > Router F And Router F - > Router A Route. So Next We Go For BGP Route Reflected Client Configuration on Router G.
NOTE :According To Our Topology Router G Is ROUTE REFLECTED CLIENT For Router D.
CONFIGURATION ON ROUTER G:
STEP 1:
Router>Enable (Switches To Privileged Exec Level)
Router#Configure Terminal (Switches To Global Configuration Level)
Router(Config)#Hostname Router G (Assign Host Name To Router G)
Router G(Config)#
INTERFACE E0 CONFIGURATION ON ROUTER G:
Router G(Config)#Int e0
Router G(Config-if)#IP Address 90.0.0.1 255.0.0.0
Router G(Config-if)#No shutdown
Router G(Config-if)#No Keepalive
Router G(Config-if)#Exit
Router G(Config)#Exit
Router G# Copy Running-Config Startup-Config
INTERFACE S0 CONFIGURATION ON ROUTER G:
Router G(Config)#Int S0
Router G(Config-if)#IP Address 80.0.0.2 255.0.0.0
Router G(Config-if)#No shutdown
Router G(Config-if)#Clock Rate 56000
Router G(Config-if)# Bandwidth 64
Router G(Config-if)#Exit OR (^Z)
Router G(Config)#Exit
Router G# Copy Running-Config Startup-Config
Router G#SHOW RUN
Router G#SHOW IP ROUTE
BGP PEERS CONFIGURATION ON ROUTER G (ROUTER D – > ROUTER G):
Router G#Conf T
Router G(Config)#Router BGP 65517
Router G(Config-Router)#Neighbor 800.0.0.1 remote-as 65517
Router G(Config-Router)# BGP Confederation Identifier20 (One Way To Reduce The IBGP Mesh Is To Divide An Autonomous System Into Multiple Autonomous Systems And Group Them Into A Single Confederation.)
Router G(Config-Router)#Network 90.0.0.0
Router G(Config-Router)#Network 80.0.0.0
Router G(Config-Router)#^z
Router G#
Router G# Copy Running-Config Startup-Config
STEP 2:
THEN GO TO ROUTER D:
CONFIGURATION ON ROUTER D - INTERFACE S2 :
INTERFACE S2 CONFIGURATION ON ROUTER D :
Router D(Config)#Int S2
Router D(Config-if)#IP Address 80.0.0.1 255.0.0.0
Router D(Config-if)#No shutdown
Router D(Config-if)# Bandwidth 64
Router D(Config-if)#Exit OR (^Z)
Router D(Config)#Exit
Router D# Copy Running-Config Startup-Config
Router D#SHOW RUN
Router D#SHOW IP ROUTE
BGP NEIGHBOR ROUTE-REFLECTOR-CLIENT PEERS CONFIGURATION ON ROUTER D (ROUTER D – > ROUTER G):
Router D#Conf T
Router D(Config)#Router BGP 65517
Router D(Config-Router)#Neighbor 800.0.0.2 remote-as 65517
Router D(Config-Router)# BGP Confederation Identifier20 (One Way To Reduce The IBGP Mesh Is To Divide An Autonomous System Into Multiple Autonomous Systems And Group Them Into A Single Confederation).
Router D(Config-Router)# Neighbor 80.0.0.2 Route-Reflector-Client (Restores Route Reflection From A BGP Route Reflector To Clients).
NEIGHBOR ROUTE-REFLECTOR-CLIENT :
To Configure The Router As A BGP Route Reflector And Configure The Specified Neighbor As Its Client, Use The Neighbor Route-Reflector-Client Command In Router Configuration Mode. To Indicate That The Neighbor Is Not A Client, Use The No Form Of This Command. When All The Clients Are Disabled, The Local Router Is No Longer A Route Reflector.
By Default, All IBGP Speakers In An Autonomous System Must Be Fully Meshed, And Neighbors Do Not Readvertise IBGP Learned Routes To Neighbors, Thus Preventing A Routing Information Loop.
If You Use Route Reflectors, All IBGP Speakers Need Not Be Fully Meshed. In The Route Reflector Model, An Internal BGP Peer Is Configured To Be A Route Reflector Responsible For Passing IBGP Learned Routes To IBGP Neighbors. This Scheme Eliminates The Need For Each Router To Talk To Every Other Router.
Router D(Config-Router)#^z
Router D#
Router D# Copy Running-Config Startup-Config
THEN CHECK IT ON ROUTER G AND ROUTER D :
#CLEAR IP BGP* SOFT
#SHOW IP BGP
#SHOW IP BGP NEIGHBOR
STEP 1:
ON ROUTER G RECHABILITY PROBLEM TO BE SOLVING ON ROUTER D :
ROUTER D (80.0.0.1) <---------> (80.0.0.2) ROUTER G
For Router G Receiving Point From Router D (80.0.0.1).
Router D(config)#Router BGP 65517
Router D(config-Router)#neighbor 80.0.0.2 next-hop-self.
Router D(config-Router)#^z
THEN GO TO ROUTER G AND CHECK IT :
Router G#CLEAR IP BGP* SOFT
Router G#SHOW IP BGP
Router G#SHOW IP BGP NEIGHBOR
NOTE :Now Router G Reachability Problem Is Solved But The Best Path Is Not Yet Solve. So Give This Command On Router G “Router G (Config-Router)# No Synchronization ”
STEP 2:
THERE IS NO BEST PATH
FOR ROUTER G BEST PATH SHOULD BE:
Router G(config)#Router BGP 65517
Router G(config-router)#No Synchronization
Router G(config-router)Z
THEN GO TO ROUTER G CHECK IT:
Router C#CLEAR IP BGP* SOFT
Router C#SHOW IP BGP
Router G#SHOW IP BGP NEIGHBOR
NOTE :
When Checked On Router G Reachability Problem And The Best Path Are Solved Now.
FINALLY WE ARE GOING (EXTERNAL) PING :
Router A#PING
-
-
Target IP Address 70.0.0.1
-
-
Source IP Address 10.0.0.1
THEN ROUTER A PING TO - > ROUTER G:
ROUTER A#PING
-
-
Target IP Address 90.0.0.1
-
-
Source IP Address 10.0.0.1
Router F#PING
-
-
Target IP Address 10.0.0.1
-
-
Source IP Address 70.0.0.1
THEN ROUTER F PING TO - > ROUTER G:
ROUTER F#PING
-
-
Target IP Address 90.0.0.1
-
-
Source IP Address 70.0.0.1
NEIGHBOR SEND-COMMUNITY:
To Specify That A Communities Attribute Should Be Sent To A BGP Neighbor, Use The Neighbor Send-Community Command In Router Configuration Mode. To Remove The Entry, Use The No Form Of This Command.
Neighbor {Ip-Address | Peer-Group-Name} Send-Community [Both | Standard | Extended]
No Neighbor {Ip-Address | Peer-Group-Name} Send-Community
If You Specify A BGP Peer Group By Using The Peer-Group-Name Argument, All The Members Of The Peer Group Will Inherit The Characteristic Configured With This Command.
EXAMPLES :
In The Following Example, The Router Belongs To Autonomous System 65517 And Is Configured To Send The Communities Attribute To Its Neighbor At Ip Address 80.0.0.2
Router D(Config)#Router BGP 65517
Router D(Config-Router)# BGP Confederation Identifier20
Router D(Config-Router)# Neighbor 80.0.0.2 Route-Reflector-Client
Router D(Config-Router)#Neighbor 80.0.0.2 Send-Community
NEIGHBOR SHUTDOWN :
To Disable A Neighbor Or Peer Group, Use The Neighbor Shutdown Command In Router Configuration Mode.To Re-Enable The Neighbor Or Peer Group, Use The No Form Of This Command.
Neighbor {Ip-Address | Peer-Group-Name} Shutdown
No Neighbor {Ip-Address | Peer-Group-Name} Shutdown
The Neighbor Shutdown Command Terminates Any Active Session For The Specified Neighbor Or Peer Group, And Removes All Associated Routing Information. In The Case Of A Peer Group, This Could Mean A Large Number Of Peering Sessions Are Suddenly Terminated.
To Display A Summary Of BGP Neighbors And Peer-Group Connections, Use The Show IP BGP Summary Command. Those Neighbors With An Idle Status And The Admin Entry Have Been Disabled By The Neighbor Shutdown Command.
CONCLUSION:
The Goal Of This Article Is To Give An Easy Way To Understand The “CISCO – BGP LAB “ROUTE REFLECTED CLIENT” STEP BY STEP LAB CONFIGURATION GUIDANCE”. Hope This Article Will Help Every Beginners Who Are Going To Start Cisco Lab Practice Without Any Doubts.
Some Topics That You Might Want To Pursue On Your Own That We Did Not Cover In This Article Are Listed Here, Thank You And Best Of Luck.
This Article Written Author By: Premakumar Thevathasan. CCNA, CCNP, CCIP, MCSE, MCSA, MCSA - MSG, CIW Security Analyst, CompTIA Certified A+.
No comments:
Post a Comment