DYNAMIC ROUTING PROTOCOLS CAN BE DIVIDED INTO TWO GROUPS:
Interior Gateway Protocols (IGP) And Exterior Gateway Protocols (EGP).IGP: An Interior Gateway Protocol - Is Used For Exchanging Routing Information Between Gateways Within An Autonomous System. Currently Popular IGPs Include OSPF, RIP, EIGRP, And IS-IS
EGP: Exterior Gateway Protocol – Routing Protocol Designed Or Managing Route Updates Between Different Autonomous Systems. The Main EGP In Use Today Is BGP Version 4, And Exterior Gateway Protocols On Backbone Routers.
An Autonomous System Is A Group Of Networking Components Under One Administrative Domain. The Gateways Within The Autonomous System Use The Route Information Conveyed By The IGP Messages To Direct IP Traffic.
BGP OVERVIEW
INTRODUCTION:
Border Gateway Protocol (BGP) Is The Only Protocol That Is Designed To Deal With A Network Of The Internet's Size, And The Only Protocol That Can Deal Well With Having Multiple Connections To Unrelated Routing Domains. BGP First Became An Internet Standard In 1989 And Was Originally Defined In RFC 1105. The Current Version, BGP4 Was Adopted In 1995 And Is Defined In RFC 4271.BGP Is An IETF Draft Standard Protocol Described In RFC 4271. The Version Described In This RFC Is BGP Version 4. Following Standard Convention, This Document Uses The Term BGP When Referencing BGP Version 4. The Initial Version Of The BGP Protocol Was Published In [RFC1105]. BGP Version 2 Is Defined In [RFC1163]. BGP Version 3 Is Defined In RFC1267]. BGP Version 4 Is Defined In [RFC1771] And [RFC4271]. Current BGP-4 RFC Is RFC 4271 (Obsoletes: RFC 1771)
BGP Has Proven To Be Scalable, Stable And Provides The Mechanisms Needed To Support Complex Routing Policies. When People Talk About "BGP" Today, They Implicitly Mean BGP4. There Is No Need To Specify The Version Number Because No One Uses Earlier Versions (Current Version Of BGP Is Version 4), And Very Few Vendors Even Still Support Them.
BGP Neighbors, Called Peers, Are Established By Manual Configuration Between Routers To Create A TCP Session On Port 179. A BGP Speaker Periodically (Every 30 Seconds) Sends 19-Byte Keep-Alive Messages To Maintain The Connection. Among Routing Protocols, BGP Is Unique In Using TCP As Its Transport Protocol.
When BGP Runs Between Two Peers In The Same Autonomous System (AS), It Is Referred To As Internal BGP (IBGP Or Interior Border Gateway Protocol). When It Runs Between Different Autonomous Systems, It Is Called External BGP (EBGP Or Exterior Border Gateway Protocol). Routers On The Boundary Of One AS Exchanging Information With Another AS Are Called Border Or Edge Routers.
BGP PROTOCOL SPECIFICATIONS:
◙ Protocol Type - > Path Vector◙ Peering Mechanism - > Manual Peering Between Neighbors
◙ Rights - > Open Standard
◙ Supported Protocols - > IPv4, IPv6
◙ Private AS Numbers: 64512-65535
◙ Reliable Updates.
◙ Rich Metric (Path Attributes).
◙ Scalable To Massive Networks
◙ EBGP AD - > 20
◙ IBGP AD - > 200
◙ Transport - > TCP/179
◙ Update Mode - > Only Triggered
◙ Timers - > Hello (60 Sec)
◙ Authentication - > None, MD5
◙ Specifications - > Current BGP-4 RFC Is RFC 4271
◙ The NOPEER Community, As Defined In RFC 3765
◙ BGP Route Reflection, As Defined In RFC 4456
◙ BGP Confederations, As Defined In RFC 3065
◙ BGP Communities, As Defined In RFC 1997
BGP CHARACTERISTICS:
◙ BGP Stands For Border Gateway Protocol. Routers Running BGP Are Termed BGP Speakers.◙ BGP Uses The Concept Of Autonomous Systems (AS). An Autonomous System Is A Group Of Networks Under A Common Administration. The Internet Assigned Numbers Authority (IANA) Assigns AS Numbers: 1 To 64511 Are Public AS Numbers And 64512 To 65535 Are Private AS Numbers.
◙ Autonomous Systems Run Interior Gateway Protocols (IGP) Within The System. They Run An Exterior Gateway Protocol (EGP) Between Them. BGP Version 4 Is The Only EGP Currently In Use.
◙ Routing Between Autonomous Systems Is Called Interdomain Routing.
◙ The Administrative Distance For EBGP Routes Is 20. The Administrative Distance For IBGP Routes Is 200.
◙ BGP Neighbors Are Called Peers And Must Be Statically Configured.
◙ BGP Uses TCP Port 179. BGP Peers Exchange Incremental, Triggered Route Updates And Periodic Keepalives.
◙ Routers Can Run Only One Instance Of BGP At A Time.
◙ BGP Is A Path-Vector Protocol. Its Route To A Network Consists Of A List Of Autonomous Systems On The Path To That Network.
◙ BGP's Loop Prevention Mechanism Is An Autonomous System Number. When An Update About A Network Leaves An Autonomous System, That Autonomous System's Number Is Prepended To The List Of Autonomous Systems That Have Handled That Update. When An Autonomous System Receives An Update, It Examines The Autonomous System List. If It Finds Its Own Autonomous System Number In That List, The Update Is Discarded.
◙ BGP Supports Classless Addressing (CIDR). That It Supports A Way To Send The Network Mask Along With The Addresses.
◙ BGP Allows A Receiver To Authenticate Messages, So That The Identity Of The Sender Can Be Verified.
HOW DOES BGP WORK:
BGP Uses TCP As Its Transport Protocol (Port 179). Two BGP Speaking Routers Form A TCP Connection Between One Another (Peer Routers) And Exchange Messages To Open And Confirm The Connection Parameters.BGP Routers Will Exchange Network Reachability Information, This Information Is Mainly An Indication Of The Full Paths (BGP AS Numbers) That A Route Should Take In Order To Reach The Destination Network. This Information Will Help In Constructing A Graph Of Ass That Are Loop Free And Where Routing Policies Can Be Applied In Order To Enforce Some Restrictions On The Routing Behavior.
WHEN USE BGP:
BGP Use In An AS Is Most Appropriate When The Effects Of BGP Are Well Understood And At Least One Of The Following Conditions Exists:◙ The AS Allows Packets To Transit Through It To Reach Other Autonomous Systems.
◙ He AS Has Multiple Connections To Other Autonomous Systems.
◙ The Flow Of Traffic Entering And Leaving The AS Must Be Manipulated.
WHEN NOT TO USE BGP:
Do Not Use BGP Is One Of The Following Conditions Exists:◙ A Single Connection To The Internet Or Another AS.
◙ Lack Of Memory Or Processor Power On Routers To Handle Constant BGP Updates.
◙ You Have Limited Understanding Of Route Filtering And The BGP Path-Selection Process.
◙ Low Bandwidth Between Autonomous Systems.
BGP DATABASES:
BGP Uses Three Databases. The First Two Listed Are BGP-Specific; The Third Is Shared By All Routing Processes On The Router:◙ NEIGHBOR DATABASE: A List Of All Configured Bgp Neighbors. To View It, Use The “SHOW IP BGP SUMMARY” Command.
◙ BGP DATABASE, OR RIB (ROUTING INFORMATION BASE): A List Of Networks Known By BGP, Along With Their Paths And Attributes. To View It, Use The “SHOW IP BGP” Command.
The BGP Topology Table, Also Called The BGP Routing Information Base (RIB), Holds The Network Layer Reachability Information (NLRI) Learned By BGP, As Well As The Associated Pas. An NLRI Is Simply An IP Prefix And Prefix Length. This Section Focuses On The Process Of How BGP Injects NLRI Into A Router’s BGP Table, Followed By How Routers Advertise Their Associated Pas And NLRI To Neighbors.
◙ ROUTING TABLE: A List Of The Paths To Each Network Used By The Router, And The Next Hop For Each Network. To View It, Use The SHOW IP ROUTE Command.
BGP NEIGHBOR RELATIONSHIPS:
A BGP Router Considers Each Neighbor To Be Either An INTERNAL BGP (IBGP) Peer Or An EXTERNAL BGP (EBGP) PEER. Any Two Routers That Have Formed A TCP Connection (BGP Port 179) In Order To Exchange BGP Routing Information Are Called Peers, They Are Also Called Neighbors. The Neighbor With Which The BGP Speaker Peers With Is In A Different AS Then Its Called As External BGP Or EBGP, And If The Neighbor Is The Same AS Then Its Called As Internal BGP Or IBGP.When A BGP Router Receives An Update From An EBGP Neighbor, It Must Pass That Update To Its IBGP Neighbors Without Changing The Next-Hop Attribute. The Next-Hop IP Address Is The IP Address Of An Edge Router Belonging To The Next-Hop Autonomous System. Therefore, IBGP Routers Must Have A Route To The Network Connecting Their Autonomous System To That Edge Router.
INTERNAL BGP NEIGHBORS:
Internal BGP (IBGP) / Internal Peer Is BGP Peering Relationship Between Routers In The Same Autonomous System. IBGP Exchanges BGP Information Within An Autonomous System. The Point Of Internal BGP Is To Distribute Your BGP Information Between Your External BGP Routers. Your External Routers Are Usually Not Close Together; IBGP Allows Them To Communicate Across Your Internal Network.◙ Because Multiple Paths Generally Exist Within An AS To Reach Other Routers, A Loopback Address Is Usually Used In The BGP Neighbor Command To Establish The IBGP Sessions.
◙ Routers Running IBGP Do Not Have To Be Directly Connected To Each Other, As Long As They Can Reach Each Other So That TCP Handshaking Can Be Performed To Set Up The BGP Speakers’ Relationship.
EXTERNAL BGP NEIGHBORS:
External BGP (EBGP) / External Peer Is BGP Peering Relationship Between Routers In Different Autonomous Systems.The Physical Topology Between EBGP Peers Is Often A Single Link, Mainly Because The Connection Is Between Different Companies In Different Autonomous Systems. As A Result, EBGP Peering Can Simply Use The Interface IP Addresses For Redundancy, Because If The Link Fails, The TCP Connection Will Fail Because There Is No Longer An IP Route Between The Peers.
When IP Redundancy Exists Between Two EBGP Peers, The EBGP Neighbor Commands Should Use Loopback IP Addresses To Take Advantage Of That Redundancy.
For Example, External BGP Is Used For Routing Between Your Local Network And Two Different ISPS.
◙ When BGP Is Running Between Routers In Different Autonomous Systems, It Is Called External BGP (EBGP).
◙ An EBGP Neighbor Is Outside This AS; An IGP Is Not Run Between The EBGP Neighbors.
BECOMING BGP NEIGHBORS:
BGP Peers Will Initially Exchange Their Full BGP Routing Tables. From Then On Incremental Updates Are Sent As The Routing Table Changes. BGP Keeps A Version Number Of The BGP Table And It Should Be The Same For All Of Its BGP Peers. The Version Number Will Change Whenever BGP Updates The Table Due To Some Routing Information Changes. Keepalive Packets Are Sent To Ensure That The Connection Is Alive Between The BGP Peers And Notification Packets Are Sent In Response To Errors Or Special Conditions. If Any State Other Than Established Is An Indication That The Two Routers Did Not Become Neighbors And Hence The BGP Updates Will Not Be Exchanged.
The Neighbor Command Used To Establish A TCP Connection Is:
Neighbor IP-Address Remote-As Number
◙ The Remote-As Number Is The AS Number Of The Router We Are Trying To Connect To Via BGP.
◙ The IP-Address Is The Next Hop Directly Connected Address For EBGP And Any IP Address On The Other Router For IBGP.
It Is Essential That The Two IP Addresses Used In The Neighbor Command Of The Peer Routers Be Able To Reach One Another. One Sure Way To Verify Reachability Is An Extended Ping Between The Two IP Addresses, The Extended Ping Forces The Pinging Router To Use As Source The IP Address Specified In The Neighbor Command Rather Than The IP Address Of The Interface The Packet Is Going Out From.
It Is Important To Reset The Neighbor Connection In Case Any BGP Configuration Changes Are Made In Order For The New Parameters To Take Effect.
Clear IP BGP Address (Where Address Is The Neighbor Address)
Clear IP BGP * (Clear All Neighbor Connections)
By Default, BGP Sessions Begin Using BGP Version 4 And Negotiating Downward To Earlier Versions If Necessary. To Prevent Negotiations And Force The BGP Version Used To Communicate With A Neighbor, Perform The Following Task In Router Configuration Mode:
Neighbor {Ip Address|Peer-Group-Name} Version Value
An Example Of The Neighbor Command Configuration Follows:
Router BGP 100
Neighbor 129.213.1.1 Remote-As 200
RTB#
Router BGP 200
Neighbor 129.213.1.2 Remote-As 100
Neighbor 175.220.1.2 Remote-As 200
RTC#
Router BGP 200
Neighbor 175.220.212.1 Remote-As 200
In The Above Example RTA And RTB Are Running EBGP. RTB And RTC Are Running IBGP. The Difference Between EBGP And IBGP Is Manifested By Having The Remote-As Number Pointing To Either An External Or An Internal AS.
Also, The EBGP Peers Are Directly Connected And The IBGP Peers Are Not. IBGP Routers Do Not Have To Be Directly Connected, As Long As There Is Some IGP Running That Allows The Two Neighbors To Reach One Another.
The Following Is An Example Of The Information That The Command "Show IP BGP Neighbors" Will Show You, Pay Special Attention To The BGP State. Anything Other Than State Established Indicates That The Peers Are Not Up.
You Should Also Note The BGP Is Version 4, The Remote Router ID (Highest IP Address On That Box Or The Highest Loopback Interface In Case It Exists) And The Table Version (This Is The State Of The Table, Any Time New Information Comes In, The Table Will Increase The Version And A Version That Keeps Incrementing Indicates That Some Route Is Flapping Causing Routes To Keep Getting Updated).
# SHOW IP BGP NEIGHBORS
BGP Neighbor Is 129.213.1.1, Remote AS 200, External Link
BGP Version 4, Remote Router ID 175.220.12.1
BGP State = Established, Table Version = 3, Up For 0:10:59
Last Read 0:00:29, Hold Time Is 180, Keepalive Interval Is 60 Seconds
Minimum Time Between Advertisement Runs Is 30 Seconds
Received 2828 Messages, 0 Notifications, 0 In Queue
Sent 2826 Messages, 0 Notifications, 0 In Queue
Connections Established 11; Dropped 10
BGP MESSAGES
After The TCP Connection Is Established, BGP Begins With BGP Open Messages. Once A Pair Of BGP Open Messages Has Been Exchanged, The Neighbors Have Reached The Established State, Which Is The Stable State Of Two Working BGP Peers. At This Point, BGP Update Messages Can Be Exchanged.
BGP MESSAGE TYPES (BGP PEERS MESSAGES):
There Are Four Types Of Messages That Can Be Exchanged Between Two BGP Peers:1. Open Message -➤ Establish Neighbor Relationship. BGP Forms Its Peer Relationships Through A Series Of Messages. First, An OPEN Message Is Sent Between Peers To Initiate The Session.
2. Keepalive Message -➤ Maintain Neighbor Relationship. Keepalive Messages Are Sent Periodically (Every 60 Seconds By Default) To Ensure That The Remote Peer Is Still Available. If A Router Does Not Receive A Keepalive From A Peer For A Hold-Time Period (By Default, 180 Seconds), The Router Declares That Peer Dead.
3. Update Message -➤ Exchange Routing Information. Update Messages Are Used To Exchange Routes Between Peers. Finally, Notification Messages Are Sent When There Is A Fatal Error Condition.
4. Notification Message -➤ When Error Occurs; Neighbor Relationship Reset. If A Notification Message Is Sent, The BGP Peer Session Is Torn Down And Reset.
OPEN MESSAGE:
Before A BGP Session Can Be Used To Exchange Routing Information, BGP Sends An Open Message To Try To Establish Peering With That Neighbor. Each BGP Speaker Uses Open Message To Identify Itself To Its Peer And To Also Specify Its BGP Operational Parameters. The BGP Operational Parameters Must Match Between Both The BGP Speakers And Both Of Them Have To Agree On Them In Order To Make Successful Peering.BGP Open Message Is Sent After A TCP Session Is Established Between The BGP Speakers Who Are Trying To Establish The Peering. This Process Begins With The Creation Of A TCP Connection Between The Peers. Once This Is Done, The BGP Peers Will Attempt To Create A BGP Session By Exchanging BGP Open Messages.
THE OPEN MESSAGE HAS TWO MAIN PURPOSES : The First Is Identification And Initiation Of A Link Between The Two Devices; It Allows One Peer To Tell The Other ``I Am A BGP Speaker Named X On Autonomous System Y, And I Want To Start Exchanging BGP Information With You''.
The Second Is Negotiation Of Session Parameters. These Are The Terms By Which The BGP Session Will Be Conducted. One Important Parameter Negotiated Using Open Message Is The Method That Each Device Wants To Use For Authentication. The Importance Of BGP Means That Authentication Is Essential, To Avoid Bad Information Or A Malicious Person From Disrupting Routes.
Each BGP Receiving An Open Message Should Process It. If Its Contents Are Acceptable, Including The Parameters The Other Device Wants To Use, It Responds With A Keepalive Message As An Acknowledgment. Each Peer Must Send An Open And Receive A Keepalive Acknowledgment For The BGP Session To Be Initialized. If Either Is Not Willing To Accept The Terms Of The Open, The Session Is Not Established. In That Case, A Notification Message May Be Sent To Convey The Nature Of The Problem.
EACH OPEN MESSAGE SPECIFIES THE FOLLOWING PARAMETERS: BGP Version Number: It Identifies The BGP Protocol Version Used. Almost All Implementations Now Use Version 4 (Since It Is The Only Version To Support CIDR).
Autonomous System Number (AS Number): Gives The Autonomous System Of The Sender’s System, Determines If The BGP Session Will Be IBGP Or If It Will Be An EBGP Session. Each Router Announces Its Own AS Number In The Open Message.
The Range For AS Numbers Is 0 – 65535, Where 0, 56320–64511 And 65535 Are Reserved By IANA And Cannot Be Used In Any Routing Environment. ASN 0 May Be Used To Label Non-Routed Networks. AS Numbers Can Be Public Or Private, Public AS Numbers Are Assigned By IANA, Private AS Numbers Can Range Between 64512 Through 65534.
If The AS Number Sent Does Not Match The AS Number Configured In The Neighbor Statement Of The Peer Receiving The Open Message, The Recipient Sends A Notification Message Indicating An Error Condition.
Hold Time :Is The Maximum Number Of Seconds That Can Elapse Before Receiving A Keepalive Or An Update Message. Hold Time Values Must Match Between Both The BGP Speakers, If The Hold Time Values Differ Then The Lower Value Is Selected As Hold Time For The Connection. If The Hold Time Is Set To Zero Then No Keepalives Are Sent. If Keeplaives Are Needed Then The Lowest Hold Time Value Which Can Be Set Is 3 Seconds For Cisco Implementation Of BGP.
The Duration Of Inactivity That Will Cause The Sender Of The Open Message To Tear Down The Session. The Hold Timer Is Reset Every Time A Keepalive Or Update Message Is Received.
BGP Identifier It Is A 32-Bit Value That Uniquely Identifies The Sender. It Is The IP Address And The Router Must Choose One Of Its IP Addresses To Use With All The BGP Peers. Is The IP Address That Identifies A BGP Speaker. If BGP Identifier Is Not Manually Set Then Cisco Defaults To Use The BGP Identifier As Numerically Highest Loopback Address And If No Loopback Address Is Configured On The Router Then Numerically Highest IP Address On A Physical Interface Is Used.
This Is The Highest Loopback Address Configured On The Router And Serves To UNIQUELY IDENTIFY THE SENDER OF THE OPEN MESSAGE.
Parameter Length: If Optional Parameters Are Specified Then This Fields Contains The Length Of Optional Parameters, In Octets.
Optional Parameters: It Contains A List Of Parameters. Authentication Is Also A Kind Of Parameter In BGP. It’s Done In This Way So That The BGP Peers Can Choose The Authentication Method Without Making It A Part Of BGP Fixed Header.
BGP Peers May Authenticate Each Other Using The MD-5 Algorithm, Whose “Message Digest” May Be Placed In The Open Message As An Optional Parameter. A New Optional Parameter Called Capability Permits BGP Peers To Evaluate Each Other’s Capabilities For The Support Of New Network-Layer Protocols Such As IP Multicast And IP Version 6. This New Parameter—Capability—Is Backward Compatible, Allowing A Peer That Does Not Support The Parameter To Maintain A Session With A Peer That Does Support The Parameter.
An OPEN Message Is Acknowledged By A KEEPALIVE Message, When It Accepts An Incoming OPEN Message, A Machine Speaking BGP Responds By Sending A Keepalive Message. Each Side Must Send An OPEN Message And Receive A Keepalive Message Before They Can Actually Exchange Routing Information. Thus, Keepalive Messages Are A Kind Of Acknowledgement For OPEN Message.
KEEPALIVE MESSAGE:
If The Parameters In The Open Message Are Accepted Then The Router Responds With A Keepalive Message, Keepalive Messages Ensure That The Connections To BGP Peers Are Alive.The Default Interval Between Keepalive Messages Is 60 Seconds (On Cisco Routers), And The Hold Time Interval Is 180 Seconds (3 X Keepalive). Keepalives Are Sent Every 60 Seconds And After Not Receiving Any Keepalive Message From BGP Peer For 180 Seconds, The Connection To That Peer Is Declared As Dead And The BGP Neighbor Is Reported As Down.
UPDATE MESSAGE:
Reachability Information Is Exchanged Between Peers In UPDATE Messages. Once BGP Speakers Have Made Contact And A Session Has Been Established Using Open Messages, The Peers Begin The Actual Process Of Exchanging Routing Information. Each BGP Router Uses Its BGP Decision Process To Select Certain Routes To Be Advertised To Its Peer. This Information Is Then Placed Into BGP Update Messages, Which Are Sent To Every BGP Peer For Which A Session Has Been Established. These Messages Are The Way That Network Reachability Knowledge Is Propagated Around The Internetwork, Includes New Routes, Withdrawn Routes, And Path Attributes.Update Messages Are Used To Update The BGP Neighbor About The Network Layer Reachability Information (NLRI) And The Path Attributes Associated With That NLRI. NLRI Is Simply The Combination Of IP Address Prefix And Length (Subnet Mask) In The Format X.X.X.X /Mask For IPv4 Addresses.
Path Attributes Are Used In The Selection Of Shortest Path Or To Detect Any Routing Loops. Update Messages Advertise Both Feasible Routes And Also The Withdrawn Routes. Withdrawn Routes Let The BGP Neighbor Know Of Any Destinations Which Have Become Unreachable.
THE UPDATE MESSAGE SPECIFIES THE FOLLOWING PARAMETERS : Withdrawn Routes Length - The Length Of The Withdrawn Routes Field.
Withdrawn Routes - A List Of IP Prefixes That The Sender Had Announced But Now Wishes To Withdraw. This Could Be A Result Of A Change In The Network Topology Or Configuration.
Total Path Attributes Length - The Length Of The Attributes Length Field. Path Attributes-A List Of BGP Attributes That Apply To The Prefixes Described In The Network Layer Reachability Information Field.
Network Layer Reachability Information (NLRI) - A List Of Prefixes That The Sender Is Advertising To Its Peer. Note That The Path Attributes Listed Earlier Apply To All Prefixes In The NLRI Field.
NOTIFICATION MESSAGE:
Notification Messages Are Used To Indicate An Error Condition Such As The Expiry Of The Hold Timer, The Receipt Of An Unrecognized Attribute Type, An Invalid AS Number, Etc. The Underlying TCP Session Is Closed After A Notification Message Is Sent.Once Established, A BGP Session Will Remain Open For A Considerable Period Of Time, Allowing Routing Information To Be Exchanged Between Peers On A Regular Basis. During The Course Of Operation, Certain Error Conditions, When A Problem Occurs That Causes A Router To End The BGP Peering Session, Some Of These Are Serious Enough That The BGP Session Must Be Terminated. When This Occurs, The Peer Detecting The Error Will Inform Its Peer Of The Nature Of The Problem By Sending It A BGP NOTIFICATION Message, And Then Close The Connection.
NOTIFICATION OF ERROR CONDITIONS : A BGP Device Can Observe Error Conditions Impacting The Connection To A Peer. Notification Messages Are Sent To The Neighbor When These Conditions Are Detected. After The Message Is Sent, The BGP Transport Connection Is Closed.
This Means That All Resources For The BGP Connection Are Deallocated. The Routing Table Entries Associated With The Remote Peer Are Marked As Invalid. Finally, Other Peers Are Notified That These Routes Are Invalid.
Notification Messages Include An Error Code And An Error Sub Code. THE ERROR CODES PROVIDED BY BGP INCLUDE: ✓ Message Header Error
✓ OPEN Message Error
✓ UPDATE Message Error
✓ Hold Timer Expired
✓ Finite State Machine Error
✓ Cease
The Error Subcode Further Qualifies The Specific Error. Each Error Code Can Have Multiple Subcodes Associated With It. Below Are The Error-Codes And Their Corresponding Sub-Codes Which Can Help Determine What Type Of Event Triggered The BGP To Close The Session.
| Error Code | Error Subcode |
| 1 � Message Header Error | 1 � Connection Not Synchronized |
| 2 � Bad Message Length | |
| 3 � Bad Message Type | |
| 2 � OPEN Message Error | 1 � Unsupported Version Number |
| 2 � Bad Peer AS | |
| 3 � Bad BGP Identifier | |
| 4 � Unsupported Optional Parameters | |
| 5 � Authentication Failure | |
| 6 � Unacceptable Hold Timer | |
| 7 � Unsupported Capability | |
| 3 � UPDATE Message Error | 1 � Malformed Attribute List |
| 2 � Unrecognized Well Know Attribute | |
| 3 � Missing Well-known Attribute | |
| 4 � Attribute Flags Error | |
| 5 � Attribute Length Error | |
| 6 � Invalid Origin Attribute | |
| 7 � AS Routing Loop | |
| 8 � Invalid NEXT_HOP Attribute | |
| 9 � Optional Attribute Error | |
| 10 � Invalid Network Field | |
| 11 Malformed AS_PATH | |
| 4 � Hold Timer Expired | |
| 5 � Finite State machine Error | |
| 6 � Cease (fatal error) | |
BGP ATTRIBUTES
BGP ATTRIBUTES:
Attributes Categories ◙ - ► Mandatory - > In Every Update.◙ - ► Discretionary - > Not Required In Every Update.
◙ - ► Transitive - > Silently Forward Attribute To Routers Without Considering Its Value.
◙ - ► Non-Transitive - > Router Will Remove; To Not Propagate To Peers.
BGP Attributes Allow AS’s To Implement Their Own Routing Policies And Attributes Are The Properties Associated With The Routes That Are Learned From BGP And Used To Determine The Best Route To A Destination, When Multiple Routes Are Available.
An Understanding Of How BGP Attributes Influence Route Selection Is Required For The Design Of Robust Networks.
The Number Of Attributes In A BGP Update Is Variable, Because Some Attributes Are MANDATORY Where As Others Are DISCRETIONARY.
Every Route Update Must Be Accompanied By All MANDATORY ATTRIBUTES, While DISCRETIONARY ATTRIBUTES May Or May Not Be Sent In The Update.
All BGP Attributes Fall Into One Of Another Two Categories: Well-Known Or Optional. A WELL-KNOWN ATTRIBUTE Must Be Recognized By All BGP Implementations. An OPTIONAL ATTRIBUTE Need Not Be Supported By All BGP Implementations.
Finally, All BGP Attributes Fall Into One Of Another Two Categories: TRANSITIVE Or NONTRANSITIVE.
A NONTRANSITIVE ATTRIBUTE Is Of Significance Only To The AS That Receives The Update The Attribute Is Not Advertised To Other ASs.
A TRANSITIVE ATTRIBUTE Is Of Global Significance And Is Forwarded In Updates To Other ASs.
LET’s SEE ONE BY ONE:
◙ BGP Attributes Are Broadly Divided Into Two Types -1) Well Known
2) Optional
◙ ~= ➤ Well Known: Well Known Attributes Are Must Be Recognized By Each Compliant Of BGP Implementations. Well Known Attributes Are Propagated To Other Neighbors Also.
◙ ~= ➤ Optional : Optional Attributes Are Recognized By Some Implementation Of BGP And Expected That Not Recognized By Everyone. Optional Attributes Are Propagated To Their Neighbors Based On The Meanings.
◙ Well Known Attributes Are Divided Into Two Types -
1) Mandatory
2) Descretionary
✓ Mandatory: Mandatory Is BGP Well Known Attributes. Mandatory Attributes Are Must Be Present In All Update Message Passed Between BGP Peers. It Is Present In Route Description.
✓ Descretionary: Discretionary Is BGP Well Known Attributes. Discretionary Attributes Are May Be Present On Update Message.
◙-◙ Mandatory Attributes Are Divided Into Three Types -
1) AS Path
2) Next Hop
3) Origin
✓ As Path: As Path Is BGP Well Known Mandatory Attributes. As Path Defines The List Of Autonomous System That A Route Has Passed Through. As Path Attributes Are Used In Path Selection Process & Lowest Path Attributes Will Be Preferred Over Highest One.
✓ Next-Hop: Next Hop Is BGP Well Known Mandatory Attributes. In BGP, Next Hop Is The IP Address Which Is Used To Reach The Advertising BGP Router.
For EBGP, Next Hop Is The Ip Address Of The Connection Between The Peers.
For IBGP, EBGP Next Hop Address Is Carried Into Local Autonomous System.
◙-◙ Origin Attributes Divided Into Three Types -
1) Internal(i)
2) External(e)
3) Incomplete(?)
✓ Origin: Origin Is BGP Well Known Mandatory Attributes. Origion Attributes Define How BGP Router Learned About The Particular Route. Origin Attribute Have Three Possible Values I.E. Internal (I), External (E) & Incomplete (?).
Internal (I): BGP Learned About The Route From Interior Routing Protocol.
External (E): BGP Learned About The Router From External BGP.
Incomplete (?): The Origin Of The Route Is Unknown Or Learned By Some Other Way. The Origin Of Incomplete Occurs When Routes Are Redistributed Into BGP.
◙-◙ Descretionary Attributes Are Divided Into Two Types -
A Well-Know Discretionary Attribute Does Not Need To Appear In A Route Description.
1) Local Preference
2) Atomic Aggregate
✓ Local Preference (Type Code 5): – Indicates To Routers In The AS Which Path Is Preferred To Exit The AS. A Path With A Higher Local Preference Is Preferred. Local Preference Is An Attribute That Is Configures On A Router And Exchanges Only Among Routers Within The Same AS. The Default Value For Local Preference On A Cisco Router Is 100.
✓ Atomic Aggregate (Type Code 6): - Indicates That The Route Has Been Summarized (Aggregated) And That The AS Path May Not Contain An Entire List Of The Transit AS. It Is Used By A BGP Speaker To Inform Other BGP Speakers That The Local System Selected A Less Specific Route Without Selecting A More Specific Route Which Is Included In It.
◙-◙ Optional Attributes Are Divided Into Two Types -
1) Transitive
2) Non Transitive
◙-◙ Transitive Attributes Are Divided Into Two Types -
1) Aggregator
2) Community
An Optional Attribute Does Not Need To Be Supported By All BGP Implementations; It Could Be A Private Attribute. An Optional Transitive Attribute That Is Not Implemented In A Router Should Be Passed To Other BGP Routers Untouched.
◙-◙ Community Attributes Are Divided Into For Types -
1) No-export
2) No advertise
3) Internet
4) Local AS.
◙-◙ Non Transitive Attributes Are Divided Into Three Types -
1) MED (Multi Exit Discriminator).
2) Originator
3) Cluster ID.
BGP Will Always Propagate The Best Path To Its Neighbors. BGP Receives Updates About Different Destinations From Different Autonomous Systems; The Protocol Will Have To Decide Which Paths To Choose In Order To Reach A Specific Destination. BGP Will Choose Only A Single Path To Reach A Specific Destination.
The Decision Process Is Based On Different Attributes, Such As Next Hop, Administrative Weights, Local Preference, The Route Origin, Path Length, Origin Code, Metric And So On.
BGP PATH SELECTION PROCESS (THE BGP DECISION PROCESS)
BGP SELECTS ROUTES POLICIES:
Exclude Inaccessible Next-Hop, Highest Weight, Highest Local Preference, Originated Routes, Shortest As Path, Lowest Origin Code, Lowest MED, EBGP Over IBGP, IBGP With Closest IGP Neighbor, EBGP With Oldest Path, Lowest BGP Router-ID.• STEP 0 - NEXT_HOP REACHABLE:
o Config-Router# Neighbor 2.2.2.2 Next-Hop-Self (EBGP Default)
o Config-Router# Neighbor 2.2.2.2 Next-Hop-Unchanged (IBGP Default)
• STEP 1 - LARGER ADMINISTRATIVE WEIGHT:
o Cisco Proprietary
o Identifies A Single Router's Best Route
o Scope - Single Router
o 0 For Learned; 32768 For Locally Injected; 0-65525 (2^16 - 1)
o Config-Route-Map# Set Weight
o Config-Router# Neighbor 2.2.2.2 Weight
• STEP 2 - HIGHEST LOCAL_PREF:
o Identifies Best Exit Point From As To Reach NLRI
o Scope - Throughout As Including Confederation Sub-As
o Default - 100
Config-Router# BGP Default Local-Preference <0-4,294,967,695>
o Config-Route-Map# Set Local-Preference
o Config-Router# Neighbor 2.2.2.2 Router-Map ("In" Param For EBGP Peer)
• STEP 3 - LOCALLY INJECTED
o BGP Assigns Weight Of 32768 For Locally Injected; Decision Is Made In Step 1
o Possibility
"Network 2.2.2.2" And "Redistribute Connected" Commands
Both Have Weight Of 32768
Default To Same Local_Pref
o Origin Code Used For This Step
• STEP 4 - SHORTEST AS_PATH:
o As_Set Only Counts As 1
o As_Confed_Seq & As_Confed_Set Do Not Count
o Config-Router# Neighbor 2.2.2.2 Remove-Private-As (64512 - 65535)
o Config-Router# Neighbor 2.2.2.2 Local-As No-Prepend
o Config-Router# BGP Bestpath As-Path Ignore (Skips This Entire Step)
o Config-Route-Map# Set As-Path Prepend
• STEP 5 - BEST ORIGIN:
o EGP(E) Should Not Occur Today
o Only One IGP(I) And Rest Unknown(?); IGP Will Be Best
o Config-Route-Map# Set Origin
• STEP 6 - SMALLEST MED:
o Tell A Neighbor How Good This Route Is
o Scope - Advertised From 1 As To Another; No Other AS's
o Default - 0
Config-Router# BGP Bestpath Med Missing-As-Worst (Makes Default Value The Highest Possible; 2^32 - 1)
o Config-Route-Map# Set Metric
o Config-Router# BGP Always-Compare-Med
o Config-Router# BGP Deterministic-Med (Processes Routes Per Adjacent As Picking Best From Each Neighboring As)
• STEP 7 - NEIGHBOR TYPE:
o EBGP > IBGP
• STEP 8 - SMALLEST IGP METRIC:
o Metric To Reach Next_Hop
o Router Looks For Route In Table
• STEP 9 - LOWEST RID:
o Examin EBGP Routes Only, Pick Lowest Rid Advertiser
o If Only IBGP Routes Exist, Pick Lowest Rid Advertiser
o Exception To Above Rules
When Already Has Best Route To NLRI
New Route To Known Prefix Is Advertised
Decision Process Is Applied
If No Decision And Existing Is EBGP; Then Do Not Replace
o Config-Router# BGP Bestpath Compare-RouterID (Always Use Lowest RID)
• STEP 10 - LOWEST NEIGHBOR ID:
o Lowest Rid Of All Current Neighbors Advertising The NLRI
COMMUNITIES:
• Group Routes Together So Routing Policies Can Be Applied
• Community Attribute; Transitive; Downstream Routers Will Receive
• New Format - Aa:Nn
o Aa Is 16-Bit Number, Potentially Represent ASn
o Nn Is A Value Set By That ASN
o Config# IP BGP-Community New-Format
• COMMUNITY LISTS:
o Standard:
Matches Multiple Communities With One Command
Limited To 16 Lines Per List
o Extended:
Supports Matching With Regular Expressions
More Than 16 Lines Per List
o Config# Ip Community-List [Standard|Extended] Word
o Config-Route-Map# Set Comm-List Word Delete (Deletes Ones That Match)
• Special Values:
o No_Export
Ffff:Ff01 - Do Not Advertise Outside The As; Can Advertise To Confederations
o No_Advert
Ffff:Ff02 - Do Not Advertise To Any Peer
o Local_As
Ffff:Ff03 - Do Not Advertise Outside The Local Confederation Sub-As
• Config-Route-Map# Match Community
• Config-Route-Map# Set Community None
• Config-Router# Neighbor 2.2.2.2 Send-Community [Both|Standard|Extended] (Needs To Be Set On Receiver Of Community Attribute)
ROUTER ID:
• Config-Router# BGP Router-Id
• Highest Up/Up Loopback
• Highest Up/Up Non-Loopback
MULTI-HOP & LOOPBACK:
• Even If Router Is 1 Hop Away, The Route From The In-Interface To The Loopback Still Counts As One, To 2 Hops Will Be Needed
Used When To EBGP Speakers Cannot Be Directly Connected. Its Configuration Must Include Static Routes Or Must Enable An IGP So That The Neighbors Can Reach Each Other. If You Have Multiple Physical Connections Between EBGP Neighbors, Using A Loopback Interface And Static Routes To The Loopback Interface Allows You To Load Balance The Traffic Between The Multiple Connections. The Multihop Is Used Only For External BGP And Not For Internal BGP.
NEIGHBOR CHECKS:
• TCP Connection Request's Source Address Needs To Be In "Network" Command
• ASN Must Match Neighbors Referenced In "Neighbor Remote-As" Command
• RID Of Two Routers Must Not Be The Same
• MD5 Authentication Must Pass If Configured
HOW BGP SELECTS ROUTES: The Most Important Parameters That Go Into Route Selection Are:
WEIGHT:
Weight Is A Purely Local Measure Of Which Route To Prefer. A Weight Is Given To A Route On A Particular Router (Via A Route Map, For Example) And Is Used Only Within That Router. The Weight Is Never Given To Other Routers. The Higher The Weight Of A Route, The Better The Route Is. Weight Is Configurable And Can Be Used To Select One Route Over Another.LOCAL PREFERENCE:
Local Preference Is Another Measure Of Which Route To Prefer. Unlike Weight, Local Preferences Are Shared Among IBGP Routers. However, They Are Not Shared With External BGP Routers. The Default Local Preference Is 100. As With Weight, Higher Numbers Indicate Better Routes.MULTI-EXIT DISCRIMINATOR (MED):
Med Values Describe Our Routes To External Routers. Unlike Preference And Weight, Med Actually Leaves Our Network And Tells Our Neighbor Routers Which Link We Want Them To Talk To. And Unlike The Other Metric Values, The Lower The Med Value, The Better The Route. The Default Med Value Is Zero (0).The Name "Multi-Exit Discriminator" Is Unfortunate And Makes The Concept Unnecessarily Confusing. The BGP Designers Were Thinking From The Point Of View Of Your ISP: Which Exit From The ISP's Network Should Be Used To Reach You? As A Result, The Med Will Make Much More Sense If You Turn It Around And Think Of It As A "Multi-Entrance Discriminator." That Is, You Use The Med To Tell Your ISPs Which Of Several Entrances To Your Network They Should Use.
You Should Use Med Values Only If You Are Multihomed To A Single Provider.
AS PATH:
BGP Routing Is Based On The List Of Autonomous Systems That Are Traversed In Order To Reach A Destination. This List Is Called An As Path. Shorter As Paths Are Preferred, But There Are Many Ways To Filter Routes Based On Their As Paths. As Paths Allow BGP To Detect Routing Loops.BGP Selects Only One Route For A Destination; This Route Is Added To The Route Table And Distributed To BGP Peers.
BGP PATH SELECTION; BGP Uses The Following Criteria, In The Order Presented, To Select A Path For A Destination:
When A BGP Router Learns Multiple Routes To The Same NLRI, It Must Choose A Single Best Route To Reach That NLRI. BGP Does Not Rely On A Single Concept Like An IGP Metric, But Rather Provides A Rich Set Of Tools That Can Be Manipulated To Affect The Choice Of Routes. The Following List Defines The Core Of The BGP Decision Process To Choose Routes.◙ STEP 0: NEXT_HOP REACHABLE? — Drop The Route Immediately If Its Next Hop Isn't Accessible. Many Texts, As Well As RFC 1771, Mention The Fact That If A Router Does Not Have A Route To The Next_Hop Pa For A Route, It Should Be Rejected In The Decision Process.
◙ STEP 1: ADMINISTRATIVE WEIGHT— If There Are Two Routes With Different Weights, Pick The Route With The Largest (Heaviest) Weight. This Is A Cisco-Proprietary Feature. The Administrative Weight Can Be Assigned To Each NLRI Locally On A Router, And The Value Cannot Be Communicated To Another Router. The Higher The Value, The Better The Route.
◙ STEP 2: HIGHEST LOCAL PREFERENCE (LOCAL_PREF) — If Weight Values Are Equal, Choose The Route With The Largest Local Preference Value. This Optional Nontransitive Pa Can Be Set On A Router Inside An As, And Distributed Inside The As Only. As A Result, This Feature Can Be Used By All BGP Routers In One As To Choose The Same Exit Point From Their As For Particular NLRI. The Higher The Value, The Better The Route.
The BGP LOCAL_PREF PA Allows Routers In An AS With Multiple Exit Points To Choose Which Exit Point Is Used To Reach A Particular NLRI. To Do So, The Router That Is The Desired Exit Point Sets The LOCAL_PREF For Its EBGP Route For That NLRI To A Relatively High Value, Then Advertises That Route Via IBGP. The Other Routers In The Same AS Can Learn Of Multiple Routes To Reach The NLRI, But They Will Choose The Route With The Higher LOCAL_PREF As The Best Route.
◙ STEP 3: CHOOSE BETWEEN LOCALLY INJECTED ROUTES BASED ON ORIGIN PA — If Local Preference Values Are Equal For Multiple Routes, Choose The Route That Originated With BGP On This Router.
Pick The Route Injected Into BGP Locally; (Using The Network Command, Redistribution, Or Route Summarization). (This Step Is Seldom Needed, And Is Sometimes Omitted From Other BGP References). This Logic Step Is Seldom Used, But It Is A Valid Part Of The BGP Decision Process. To Appreciate Why It Is So Seldom Needed, Consider The Following: BGP Assigns A Weight Of 32,768 To Routes Locally Injected Into BGP. As A Result, A Router Would Have Already Picked A Locally Injected Route As Best Because Of To Its High Weight.
Two General Cases Can Occur That Cause A Router To Use The Logic For This Step. The First Case Is Unlikely. A Router Must Locally Inject An NLRI, Learn The Same NLRI From A Neighbor, And Use An Inbound Route-Map To Set The Weight Of That Received NLRI To The Same Value As The Locally Injected Route. That Only Occurs In Lab Experiments.
The Second Case Occurs When A Router Attempts To Inject Routes Locally Via Multiple Methods, And The Same NLRI Is Injected From Two Different Sources.
◙ STEP 4: SHORTEST AS_PATH — If None, Or All, Of The Routes Originated On This Router, Choose The Route With The Shortest As Path. Routers Can Easily Determine The Shortest AS_PATH Length By Using A Few Rules That Define How To Account For All Four Parts Of The AS_PATH—The AS_SEQ, AS_SET, AS_CONFED_SEQ, And AS_CONFED_SET. Additionally, Routing Policies Can Change The Number Of ASNs In The AS_PATH.
◙ STEP 5: BEST ORIGIN PA — IGP (I) Routes Are Preferred Over EGP (E) Routes, Which Are In Turn Preferred Over Incomplete (?) Routes.
If All The As Path Lengths Are The Same, Choose The Path With The Lowest Origin Type. Origin Refers To Whether The Route Originated Via An Internal Gateway Protocol (IGP) Or An External Gateway Protocol (EGP). Routes That Have Entered The BGP Domain By Redistribution Are Considered Incomplete. IGP Is Lower Than EGP, And EGP Is Lower Than Incomplete.
◙ STEP 6: SMALLEST MULTI-EXIT DISCRIMINATOR (MED) PA— If All The Origin Types Are The Same, Choose The Path With The Lowest MED Value. Traditionally, This Pa Allows An ISP With Multiple Peer Connections To A Customer As To Tell The Customer As Which Of The Peer Connections Is Best For Reaching Particular NLRI. The Smaller The Value, The Better The Route.
The Multi-Exit Discriminator (MED) Or Metric Attribute Is Used As A Suggestion To An External AS Regarding The Preferred Route Into The AS That Is Advertising The Metric. The Term Suggestion Is Used Because The External AS That Is Receiving The MEDs May Be Using Other BGP Attributes For Route Selection.
The Purpose Of The MED (Or MULTI_EXIT_DISC) Is To Allow Routers In One AS To Tell Routers In A Neighboring AS How Good A Particular Route Is. In Fact, Because Of How MED Works, It Is Often Called The BGP Metric, Even Though It Is Not Close To The Top Of The BGP Decision Process.
◙ STEP 7: PREFER NEIGHBOR TYPE eBGP OVER iBGP — Prefer EBGP Routes Over IBGP. For This Step, Treat Confederation EBGP As Equal To IBGP.
This Step Is Rather Simple, And Needs Very Little Elucidation. Keeping In Mind That The Goal Is A Single Best Route For Each NLRI, This Decision Point Simply Looks To See If A Single EBGP Route Exists. If So, That Route Is Chosen. If Multiple EBGP Routes Exists, This Decision Point Cannot Determine The Best Route.
Interestingly, BGP Uses This Decision Point Frequently When Two Or More Enterprise Routers Connect To The Same ISP. Each Border BGP Router In The Enterprise Receives The Same Prefixes With The Same AS_PATH Lengths From The ISP, And Then These Border BGP Routers Advertise These Routes To Their IBGP Peers. So, Each Enterprise Border Router Knows Of One EBGP Route To Reach Each Prefix, And One Or More IBGP Routes To The Same Prefix Learned From That Enterprise’s Other Border Routers. With No Routing Policies Configured, The Routes Tie On All Decision Points Up To This One, Including AS_PATH Length, Because All The Prefixes Were Learned From The Same Neighboring ISP. The Decision Process Reaches This Step, At Which Point The One EBGP Route Is Picked As The Best Route.
◙ STEP 8: SMALLEST IGP METRIC TO THE NEXT_HOP — IGP Metrics For Each NLRI’s Next_Hop Are Compared. The Lower The Value, The Better The Route.
The Router Looks For The Route That Would Be Used To Reach The NEXT_HOP Listed In Each BGP Table Entry For A Particular Prefix. It Is Mentioned Here Just To Complete The List.
The Maximum-Paths Command And BGP Decision Process Tiebreakers The Goal Of The BGP Decision Tree Is To Find The One Best BGP Route To Each NLRI, From That Router’s Perspective. That Router Then Considers Only Its Best Routes For Advertising To Other Routers, Restricting Those Routes Based On AS_PATH Loop Prevention And Routing Policy Configuration. That Router Also Attempts To Add That Best Route, And That Best Route Only, To Its IP Routing Table. In Fact, As Long As Another Routing Source Has Not Found A Route To The Same Prefix, With A Better Administrative Distance, The Best BGP Route Is Placed Into That Router’s Routing Table.
If BGP Has Not Chosen A Best Route For A Particular NLRI After Steps 0 Through 8, Then Multiple Routes Tie For Being The Best Route. At This Point, BGP Needs To Make Two Important Decisions:
■ Which Route Is Best — BGP Uses Two Tiebreakers, Discussed Next, To Determine Which Route Is Best.
■ Whether To Add Multiple BGP Routes For That NLRI To The IP Routing Table — BGP Considers The Setting Of The Maximum-Paths Command To Make This Decision, As Described After The Discussion Of Steps 9 And 10.
Even If BGP Adds To The IP Routing Table Multiple BGP Routes To The Same Prefix, It Still Picks Only One As The Best Route In The BGP Table.
◙ STEP 9: LOWEST BGP ROUTER ID OF ADVERTISING ROUTER (WITH ONE EXCEPTION) — If The Distances To The Closest IGP Neighbor Are The Same, Choose The Path With The Lowest BGP Router ID (A Router's ID Is The IP Address Assigned To The Loopback Interface Or The Highest IP Address On An Active Interface At Boot Time).
The First Tiebreaker Is To Pick The Route With The Lowest RID. The Logic Is Actually Two Steps, As Follows:
1. Examine The Ebgp Routes Only, Picking The Route Advertised By The Router With The Lowest RID.
2. If Only IBGP Routes Exist, Pick The Route Advertised By The Router With The Lowest RID.
These Straightforward Rules Are Followed In Some Cases, But Not In Some Others. The Exception To This Rule Occurs When BGP Already Has A Best Route To The NLRI, But It Has Learned New BGP Information From Other Routers, Including A New BGP Route To Reach A Previously Known Prefix.
The Router Then Applies Its BGP Decision Process Again To Decide Whether To Change Its Opinion Of Which Route Is Best For That NLRI. If The Decision Process Does Not Determine A Best Route By This Step, This Step Uses The Following Default Logic:
If The Existing Best Route Is An EBGP Route, Do Not Replace The Existing Best Route, Even If The New Route Has A Smaller RID.
The Reasoning Is That Replacing The Route Could Result In Route Flaps, So Keeping The Same Route Is Fine. This Behavior Can Be Changed So That The Lowest RID Is Always Used, By Configuring The BGP Bestpath Compare-RouterID BGP Subcommand. Note That This Exception Only Applies To EBGP Routes; If The Currently Best Route Is An IBGP Route, The Decision Is Simply Based On The Lowest Advertising Router’s RID.
◙ STEP 10: LOWEST NEIGHBOR ID — If Step 9 Did Not Break The Tie, Then The Router Has At Least Two Neighbor Commands That Point To The Same Router, And That Router Happens To Have The Lowest RID Of All Current Neighbors Advertising The NLRI In Question. Typically, If Redundancy Exists Between Two Routers, The Configuration Uses Loopback Interfaces, A Single Neighbor Command, And The Neighbor EBGP-Multihop Command If The Neighbor Is An EBGP Neighbor. However, Using A Pair (Or More) Of Neighbor Commands Pointing To A Single Neighboring Router Is A Valid Configuration Option; This Final Tiebreaker Provides A Way To Break Ties For This Case.
At This Point, The Router Looks At The IP Addresses On The Neighbor Commands Corresponding To All The Neighbors From Which The Route Was Received, And It Picks The Lowest Neighbor IP Address.
Note That, As Usual, It Considers All Routes Again At This Step, So It May Not Pick The Neighboring Router With The Lowest RID At This Point.
THE BGP MAXIMUM-PATHS COMMAND:
BGP Defaults The Maximum-Paths Command To A Setting Of 1; In Other Words, Only The BGP Best Route In The BGP Table Could Possibly Be Added To The IP Routing Table. However, BGP Will Consider Adding Multiple Entries To The IP Routing Table, For The Same NLRI, Under Certain Conditions — Conditions That Differ Based On Whether The Best Route Is An EBGP Route Or An IBGP Route.First, Consider EBGP Routes. The Following Rules Determine If And When A Router Will Add Multiple EBGP Routes To The IP Routing Table For A Single NLRI:
1. BGP Must Have Had To Use A Tiebreaker (Step 9 Or 10) To Determine The Best Route.
2. The Maximum-Paths Number Command Must Be Configured To Something Larger Than The Default Of 1.
3. Only EBGP Routes Whose Adjacent ASNs Are The Same ASN As The Best Route Are Considered As Candidates.
4. If More Candidates Exist Than That Called For With The Maximum-Paths Command, The Tiebreakers Of Steps 9 And 10 Determine The Ones To Use.
Although The List Is Detailed, The General Idea Is That The Router Can Trust Multiple Routes, But Only If The Packets End Up In The Same Adjacent AS. Also, BGP Must Restrict Itself To Not Use Multipath If The Best Route Was Found Via Steps 0 Through 8 Of The Decision Process, Because Forwarding Based On Another Route Could Cause Loops.
Next, Consider IBGP Routes. The Rules For IBGP Have Some Similarities With EBGP, And A Few Differences, As Follows:
1. Same Rule As EBGP Rule 1.
2. The Maximum-Paths IBGP Number Command Defines The Number Of Possible IP Routes, Instead Of The Maximum-Paths Number Command Used For EBGP.
3. Only IBGP Routes With Differing NEXT_HOP Settings Are Considered As Candidates.
4. Same Rule As EBGP Rule 4.
The Rationale Is Similar To EBGP With Regard To Most Of The Logic. Additionally, It Does Not Help To Add Multiple IP Routes If The NEXT_HOP Settings Are Equal, So BGP Performs That Additional Check.
Finally, The Maximum-Paths Eibgp Number Command Seemingly Would Apply To Both IBGP And EBGP Routes.
BGP COMMUNITIES:
The BGP COMMUNITY PA Provides A Mechanism By Which To Group Routes So That Routing Policies Can Be Applied To All The Routes With The Same Community. By Marking A Set Of Routes With The Same COMMUNITY String, Routers Can Look For The COMMUNITY String And Then Make Policy Decisions — Like Setting Some PA That Impacts The BGP Decision Process, Or Simply Filtering The Routes. BGP Communities Are Powerful In That They Allow Routers In One AS To Communicate Policy Information To Routers That Are One Or More Autonomous Systems Distant. In Fact, Because The COMMUNITY PA Is An Optional Transitive PA, It Can Pass Through Autonomous Systems That Do Not Even Understand The COMMUNITY PA, And Then Still Be Useful At Another Downstream AS.BGP SYNCHRONIZATION RULE
Recent IOS Versions Have Synchronization Disabled By Default. It Is Usually Safe To Turn Off Synchronization When All Routers In The Autonomous System Run BGP. To Turn It Off In Earlier IOS Versions, Use The Command “NO SYNCHRONIZATION”Under BGP Router Configuration Mode.
BGP FINITE STATE MACHINE (BGP FSM)
BGP FINITE STATE MACHINE (Neighbor States):
When A BGP Routing Process Establishes A Peering Finite State Machine (FSM) Session with a Peer It Goes through the Following SIX STATE Changes DIAGRAM BELOW
2. CONNECT - > Listen For TCP.
3. ACTIVE - > Initiate TCP.
4. OPEN SENT - > TCP Up; Open Message Sent.
5. OPEN CONFIRM - > Open Message Received.
6. ESTABLISHED - > Neighbors Up.
For Each Peer-To-Peer Session, A BGP Implementation Maintains A State Variable That Tracks Which Of These Six States The Session Is In. The BGP Protocol Defines The Messages That Each Peer Should Exchange In Order To Change The Session From One State To Another.
The First State Is The “IDLE” State. In The “Idle” State, BGP Initializes All Resources, Refuses All Inbound BGP Connection Attempts And Initiates A TCP Connection To The Peer.
The Second State Is “Connect”. In The “CONNECT” State, The Router Waits For The TCP Connection To Complete And Transitions To The "OPENSENT" State If Successful. If Unsuccessful, It Starts The Connectretry Timer And Transitions To The "ACTIVE" State Upon Expiration. In The "ACTIVE" State, The Router Resets The Connectretry Timer To Zero And Returns To The "Connect" State.
In The "OPENSENT" State, The Router Sends An Open Message And Waits For One In Return In Order To Transition To The "OPENCONFIRM" State.
Keepalive Messages Are Exchanged And, Upon Successful Receipt, The Router Is Placed Into The “ESTABLISHED” State. In The “ESTABLISHED” State, The Router Can Send/Receive: Keepalive; Update; And Notification Messages To/From Its Peer.
IN TERMS OF BGP FINITE STATE MACHINE (FSM):
• IDLE STATE:o Refuse All Incoming BGP Connections
o Start The Initialization Of Event Triggers.
o Initiates A TCP Connection With Its Configured Bgp Peer.
o Listens For A TCP Connection From Its Peer.
o Changes Its State To Connect.
o If An Error Occurs At Any State Of The FSM Process, The BGP Session Is Terminated Immediately And Returned To The Idle State.
Some Of The Reasons Why A Router Does Not Progress From The IDLE State Are:
TCP Port 179 Is Not Open.
A Random TCP Port Over 1023 Is Not Open.
Peer Address Configured Incorrectly On Either Router.
As Number Configured Incorrectly On Either Router .
◙ IDLE STATE:Is A Initial State The BGP Routing Process Enters When The Routing Process Is Enabled Or When The Router Is Reset. In This State, The Router Waits For A Start Event, Such As A Peering Configuration With A Remote Peer. After The Router Receives A TCP Connection Request From A Remote Peer, The Router Initiates Another Start Event To Wait For A Timer Before Starting A TCP Connection To A Remote Peer. If The Router Is Reset Then The Peer Is Reset And The BGP Routing Process Returns To The IDLE STATE.
• CONNECT STATE:
o Waits For Successful TCP Negotiation With Peer.
o BGP Does Not Spend Much Time In This State If The TCP Session Has Been Successfully Established.
o Sends Open Message To Peer And Changes State To Opensent.
o If An Error Occurs, BGP Moves To The Active State.
Some Reasons For The Error Are:
TCP Port 179 Is Not Open.
A Random TCP Port Over 1023 Is Not Open.
Peer Address Configured Incorrectly On Either Router.
As Number Configured Incorrectly On Either Router.
◙ CONNECT STATE: In This State BGP Is Waiting For The Transport Protocol Connection To Be Completed. The BGP Routing Process Detects That A Peer Is Trying To Establish A TCP Session With The Local BGP Speaker.
If The Transport Protocol Connection Succeeds, The Local System Clears The Connectretry Timer, Completes Initialization, Sends An OPEN Message To Its Peer, And Changes Its State To OPENSENT.
If The Transport Protocol Connect Fails (E.G., Retransmission Timeout), The Local System Restarts The Connect Retry Timer, Continues To Listen For A Connection That May Be Initiated By The Remote BGP Peer, And Changes Its State To Active State.
In Response To The ConnectRetry Timer Expired Event, The Local System Restarts The ConnectRetry Timer, Initiates A Transport Connection To Other BGP Peer, Continues To Listen For A Connection That May Be Initiated By The Remote BGP Peer, And Stays In The Connect State.
Start Event Is Ignored In The Active State.
In Response To Any Other Event (Initiated By Either System Or Operator), The Local System Releases All BGP Resources Associated With This Connection And Changes Its STATE TO IDLE.
• ACTIVE STATE:
o If The Router Was Unable To Establish A Successful TCP Session, Then It Ends Up In The Active State.
o BGP FSM Tries To Restart Another TCP Session With The Peer And, If Successful, Then It Sends An Open Message To The Peer.
o If It Is Unsuccessful Again, The FSM Is Reset To The Idle State.
o Repeated Failures May Result In A Router Cycling Between The Idle And Active States.
Some Of The Reasons For This Include:
TCP Port 179 Is Not Open.
A Random TCP Port Over 1023 Is Not Open.
BGP Configuration Error.
Network Congestion.
Flapping Network Interface.
◙ ACTIVE STATE: In This State BGP Is Trying To Acquire A Peer By Initiating A Transport Protocol Connection / The BGP Routing Process Tries To Establish A TCP Session With A Peer Router Using The Connect Retry Timer.
If The Transport Protocol Connection Succeeds, The Local System Clears The Connectretry Timer, Completes Initialization, Sends An OPEN Message To Its Peer, Sets Its Hold Timer To A Large Value, And Changes Its State To Open Sent. A Hold Timer Value Of 4 Minutes Is Suggested.
In Response To The Connectretry Timer Expired Event, The Local System Restarts The Connectretry Timer, Initiates A Transport Connection To Other BGP Peer, Continues To Listen For A Connection That May Be Initiated By The Remote BGP Peer, And Changes Its State To Connect.
If The Local System Detects That A Remote Peer Is Trying To Establish BGP Connection To It, And The IP Address Of The Remote Peer Is Not An Expected One, The Local System Restarts The Connectretry Timer, Rejects The Attempted Connection, Continues To Listen For A Connection That May Be Initiated By The Remote BGP Peer, And Stays In The Active State.
Start Event Is Ignored In The Active State.
In Response To Any Other Event (Initiated By Either System Or Operator), The Local System Releases All BGP Resources Associated With This Connection And Changes Its STATE TO IDLE.
• OPENSENT STATE:
o BGP FSM Listens For An Open Message From Its Peer.
o Once The Message Has Been Received, The Router Checks The Validity Of The Open Message.
o If There Is An Error It Is Because One Of The Fields In The Open Message Doesn’t Match Between The Peers, E.G., BGP Version Mismatch, MD5 Password Mismatch, The Peering Router Expects A Different My As, Etc. The Router Then Sends A Notification Message To The Peer Indicating Why The Error Occurred.
o If There Is No Error, A Keepalive Message Is Sent, Various Timers Are Set And The State Is Changed To Openconfirm.
◙ OPENSENT STATE: The TCP Connection Is Established And The BGP Routing Process Sends An Open Message To The Remote Peer, And Transitions To The Open Sent State. The BGP Routing Process Can Receive Other Open Messages In This State. If The Connection Fails, The BGP Routing Process Transitions To The ACTIVE STATE.
There Are Three Possibilities From This State; BGP Can Either Progress To OPENCONFIRM STATE Or To Active State Or Back To IDLE STATE.
1) It Progresses To Openconfirm State If The Open Message Is Received From The Neighbor And The Open Message Has No Errors. Also A The Hold Time Is Negotiated And The Keepalive Timers Are Set. A Keepalive Message Is Also Sent Once It Transitions To OPENCONFIRM STATE.
2) It Transitions Back To Idle State If The Open Message Received Has Errors, A Notification Message Is Sent Indicating Error And BGP Transitions Back To IDLE STATE.
3) It Transitions To Active State If A TCP Disconnect Is Received Before The Open Message, Upon Receiving The TCP Disconnect, The BGP Connection Is Closed And The Connectretry Timer Is Reset.
• OPENCONFIRM STATE:
o The Peer Is Listening For A Keepalive Message From Its Peer.
o If A Keepalive Message Is Received And No Timer Has Expired Before Reception Of The Keepalive, BGP Transitions To The Established State.
o If A Timer Expires Before A Keepalive Message Is Received, Or If An Error Condition Occurs, The Router Transitions Back To The Idle State.
◙ OPENCONFIRM STATE: In This State BGP Waits For A Keepalive Or Notification Message.
If The Local System Receives A Keepalive Message, It Changes Its State To Established.
If The Hold Timer Expires Before A KEEPALIVE Message Is Received, The Local System Sends NOTIFICATION Message With Error Code Hold Timer Expired And Changes Its STATE TO IDLE.
If The Local System Receives A NOTIFICATION Message, It Changes Its STATE TO IDLE.
If The Keepalive Timer Expires, The Local System Sends A Keepalive Message And Restarts Its Keepalive Timer.
If A Disconnect Notification Is Received From The Underlying Transport Protocol, The Local System Changes Its STATE TO IDLE.
In Response To The Stop Event (Initiated By Either System Or Operator) The Local System Sends NOTIFICATION Message With Error Code Cease And Changes Its STATE TO IDLE.
Start Event Is Ignored In The Openconfirm State. In Response To Any Other Event The Local System Sends NOTIFICATION Message With Error Code Finite State Machine Error And Changes Its STATE TO IDLE.
Whenever BGP Changes Its State From Openconfirm To Idle, It Closes The BGP (And Transport-Level) Connection And Releases All Resources Associated With That Connection.
• ESTABLISHED STATE:
o In This State, The Peers Send Update Messages To Exchange Information About Each Route Being Advertised To The BGP Peer.
o If There Is Any Error In The Update Message Then A Notification Message Is Sent To The Peer, And BGP Transitions Back To The Idle State.
o If A Timer Expires Before A Keepalive Message Is Received, Or If An Error Condition Occurs, The Router Transitions Back To The Idle State.
◙ ESTABLISHED STATE: This State Indicates That The BGP Session To The Peer Is Fully Established And Both The BGP Peers Can Exchange Update, Notification, And Keepalive Messages With Its Peer.
If The Local System Receives An Update Or Keepalive Message, It Restarts Its Hold Timer, If The Negotiated Hold Time Value Is Non-Zero.
If The Local System Receives A Notification Message, It Changes Its STATE TO IDLE.
If The Local System Receives An Update Message And The Update Message Error Handling Procedure (See Section 6.3) Detects An Error, The Local System Sends A Notification Message And Changes Its STATE TO IDLE.
If A Disconnect Notification Is Received From The Underlying Transport Protocol, The Local System Changes Its STATE TO IDLE.
If The Hold Timer Expires, The Local System Sends A Notification Message With Error Code Hold Timer Expired And Changes Its STATE TO IDLE.
If The Keepalive Timer Expires, The Local System Sends A Keepalive Message And Restarts Its Keepalive Timer.
Each Time The Local System Sends A Keepalive Or Update Message, It Restarts Its Keepalive Timer, Unless The Negotiated Hold Time Value Is Zero.
In Response To The Stop Event (Initiated By Either System Or Operator), The Local System Sends A Notification Message With Error Code Cease And Changes Its STATE TO IDLE.
Start Event Is Ignored In The ESTABLISHED STATE.
In Response To Any Other Event, The Local System Sends Notification Message With Error Code Finite State Machine Error And Changes Its STATE TO IDLE.
Whenever BGP Changes Its State From Established To Idle, It Closes The BGP (And Transport-Level) Connection, Releases All Resources Associated With That Connection, And Deletes All Routes Derived From That Connection.
BGP CONFIGURATION
SHOW COMMANDS:
CLEAR IP BGP * - ➤ Resets A BGP Connection Using BGP Soft Reconfiguration.CLEAR IP BGP * [SOFT [IN|OUT]] - ➤ (Soft Reconfiguration)
BGP Feature Called Soft Reconfiguration. Soft Reconfiguration Allows A BGP Peer To Reapply Its Routing Policies Without Closing A Neighbor Connection. To Reapply The Policies, Cisco IOS Uses The Clear Command With Either The Soft, In, Or Out Options, As Shown In The Following Generic Clear Command Syntax:
Clear IP BGP {* | Neighbor-Address | Peer-Group-Name} [Soft [In | Out]]
The Soft Option Alone Reapplies The Policy Configuration For Both Inbound And Outbound Policies, Whereas The Inclusion Of The In Or Out Keyword Limits The Reconfiguration To The Stated Direction.
Cisco IOS Supports Soft Reconfiguration For Sent Updates Automatically, But BGP Must Be Configured To Support Soft Reconfiguration For Inbound Updates. To Support Soft Reconfiguration, BGP Must Remember The Actual Sent And Received BGP Update Information For Each Neighbor.
CLEAR IP BGP EXTERNAL To Clear External Border Gateway Protocol (Ebgp) Peers, Use The CLEAR IP BGP EXTERNAL Command In Privileged EXEC Mode.
Clear IP BGP External [In | Out]
Clear IP BGP External [Soft [In | Out]]
Clear IP BGP External {Ipv4 | Ipv6 {Multicast | Unicast [In | Out | Soft]}}
Clear IP BGP External [Vpn4 Unicast {In | Out | Soft}}
The Following Example Clears An Inbound Session With The EBGP Peers:
Router# Clear IP BGP External In
OR
Router# Clear IP BGP External Soft In
The Following Examples Clear An Outbound Address Family IPv4 Multicast Session With The EBGP Peers:
Router# CLEAR IP BGP External IPv4 Multicast Out
To Determine Whether A BGP Router Supports This Capability, Use The Show IP BGP Neighbors Command.
Show IP BGP Neighbors - ➤ Display Information About The TCP And BGP Connections To Neighbors.
The Neighbor NEIGHBOR-ID Soft-Reconfiguration Inbound Command Causes The Router To Keep A Copy Of The Received Updates From The Specified Neighbor. (IOS Keeps A Copy Of Sent Updates Automatically.) With These Updates Available, BGP Can Simply Reapply The Changed Filtering Policy To The Update Without Closing The Neighbor Connection.
Clearing The Neighbor Is Required To Pick Up The Changes To Routing Policies That Impact Updates Sent And Received From Neighbors. All Such Changes Can Be Implemented Using Soft Reconfiguration. However, For Configuration Changes That Impact The Local Injection Of Routes Into The BGP Table, Soft Reconfiguration Does Not Help. The Reason Is That Soft Reconfiguration Simply Reprocesses Updates, And Features That Inject Routes Into BGP Via The Redistribute Or Network Commands Are Not Injected Based On Update Messages.
SHOW IP BGP IPV4 MULTICAST [COMMAND] - ➤ Displays IPv4 Multicast Database-Related Information.
SHOW IP BGP NEIGHBORS [Neighbor-Address] - ➤ Displays Information About The TCP And BGP Connections To Neighbors.
SHOW IP BGP NEIGHBORS [NEIGHBOR-ADDRESS] [RECEIVED-ROUTES | ROUTES | ADVERTISED-ROUTES | PATHS REGEXP | DAMPENED-ROUTES | RECEIVED PREFIX-FILTER]] - ➤ Displays Information About The TCP And BGP Connections To Neighbors.
SHOW IP BGP - ➤ Command Shows The BGP Routing Table For Router.
SHOW IP BGP [Network] [Network-Mask] - ➤ Displays The Entries In The BGP Routing Table.
SHOW IP BGP SUMMARY - ➤ Displays The Status Of All BGP Connections.
SHOW IP BGP PATHS - ➤ This Command Is Used To Display All The BGP Paths In The Database.
SHOW TCP BRIEF ALL
SHOW IP BGP COMMUNITY [NO-EXPORT | LOCAL-AS | NO-ADVERT | WORD]
SHOW IP BGP RIB-FAILURE - ➤ Displays BGP Routes That Are Not Installed In The RIB, That The Displayed Routes Were Not Installed Because A Route Or Routes With A Better Administrative Distance Already Exist In The RIB.
SHOW IP BGP INJECTED-PATHS - ➤ Displays Information About Injected Paths.
DEBUG COMMANDS:
DEBUG IP BGP UPDATESDEBUG IP BGP EVENTS
Debug IP BGP [A.B.C.D. | Dampening | Events | In | Keepalives | Out | Updates | Vpnv4 | Mpls] - ➤ Displays Information Related To Processing Of The Border Gateway Protocol (BGP)
Debug IP BGP Groups [Index-Group | Ip-Address] - ➤ Displays Information Related To The Processing Of Border Gateway Protocol (BGP) Update-Groups.
Debug IP BGP Updates [Access-List | Expanded-Access-List] [In | Out] [Events] - ➤ Displays Information About The Processing Of Border Gateway Protocol (BGP) Updates.
For Troubleshooting - > Use The Ping Command To Check Basic Network Connectivity Between The BGP Routers And Use The SHOW IP VRF Command To Verify That The VRF Instance Has Been Created. After That:
CLEAR IP BGP * - ➤ Command Also Clears All The Internal Bgp Structures Which Makes It Useful As A Troubleshooting Tool. The Syntax Is CLEAR IP BGP ALL.
ENABLING BGP ROUTING:
Enable And Configure BGP Steps As Bellow. We Have Two Routers Router A And Router B Talk BGP. In The First Example Router A And Router B Are In Different Autonomous Systems. We Start By Defining The Router Process And Define The AS Number That The Routers Belong To.The Command Used To Enable BGP On A Router Is:
Router BGP Autonomous-System Router A# Router BGP 100
Router B# Router BGP 200
The Above Statements Indicates That Router A Is Running BGP And It Belongs To AS100 And Router B Is Running BGP And It Belongs To AS200 And So On. The Next Step In The Configuration Process Is To Define BGP Neighbors.
The Neighbor Definition Indicates Which Routers We Are Trying To Talk With BGP.
Router A# Router BGP 100
Neighbor 129.213.1.1 Remote-As 200
Router B# Router BGP 200
Neighbor 129.213.1.2 Remote-As 100
In The Above Example Router A And Router B Are Running EBGP.
Note: The Difference Between EBGP And IBGP Is Manifested By Having The Remote-As Number Pointing To Either An External Or An Internal AS.
INTERNAL BGP:
IBGP Is Used If An AS Wants To Act As A Transit System To Other ASs. You Might Ask, Why Can't We Do The Same Thing By Learning Via EBGP Redistributing Into IGP And Then Redistributing Again Into Another AS? We Can, But IBGP Offers More Flexibility And More Efficient Ways To Exchange Information Within An AS.An Important Point To Remember, Is That When A BGP Speaker Receives An Update From Other BGP Speakers In Its Own AS (IBGP), The Receiving BGP Speaker Will Not Redistribute That Information To Other BGP Speakers In Its Own AS.
The Receiving BGP Speaker Will Redistribute That Information To Other BGP Speakers Outside Of Its AS. That Is Why It Is Important To Sustain A Full Mesh Between The IBGP Speakers Within An AS.
Router A# Router BGP 100
Neighbor 190.10.50.1 Remote-As 100
Neighbor 170.10.20.2 Remote-As 300
Network 150.10.0.0
Router B# Router BGP 100
Neighbor 150.10.30.1 Remote-As 100
Neighbor 175.10.40.1 Remote-As 400
Network 190.10.50.0
Router C# Router BGP 400
Neighbor 175.10.40.2 Remote-As 100
Network 175.10.0.0
BASIC CONFIGURATION:
Router 1 And Router 2 Are IBGP Neighbors With AS 10. Router 3 And Router 4 Are IBGP Neighbors With AS 20. AS 10 With AS 20 Are EBGP Neighbors (Because They Belong To Different AS).To Configure BGP Start With Router BGP AS This Enters You To BGP Configuration Mode. Here AS Represents Autonomous System To Which The Router Belongs. Take Note That A Router Can Belong Only To One BGP Autonomous System.
Next, Configure BGP Neighbors With Neighbor (IP-Address | Peer-Group-Name) Remote-As AS Command. In This Lab Will Set Neighbors Based On IP Address Not On Peer Groups. To Tell To The Router What To Advertise Use This Command: Network Network-Number [Mask Network-Mask] [ Route-Map Map-Tag]. In This Lab Will Not Use Route Maps.
Router 1: Router1(config)#interface fa0/0
Router1(config-if)#ip address 192.168.0.2 255.255.255.0
Router1(config-if)#no shutdown
Router1(config)#router bgp 10
Router1(config-router)#neighbor 192.168.0.1 remote-as 10
Router 2: Router2(config)#interface fastEthernet 0/0
Router2(config-if)#ip address 10.0.0.1 255.255.255.0
Router2(config-if)#no shutdown
Router2(config-if)#interface fastethernet 0/1
Router2(config-if)#ip address 192.168.0.1 255.255.255.0
Router2(config-if)#no shutdown
Router2(config)#router bgp 10
Router2(config-router)#neighbor 192.168.0.2 remote-as 10
Router2(config-router)#neighbor 10.0.0.2 remote-as 20
Router2(config-router)#network 192.168.0.0 mask 255.255.255.0
Router 3: Router3(config)#interface fastEthernet 0/0
Router3(config-if)#ip address 10.0.0.2 255.255.255.0
Router3(config-if)#no shutdown
Router3(config-if)#interface fa0/1
Router3(config-if)#ip address 192.168.100.1 255.255.255.0
Router3(config-if)#no shutdown
Router3(config)#router bgp 20
Router3(config-router)#neighbor 10.0.0.1 remote-as 10
Router3(config-router)#neighbor 192.168.100.2 remote-as 20
Router3(config-router)#network 192.168.100.0 mask 255.255.255.0
Router 4: Router4(config)#interface fastEthernet 0/0
Router4(config-if)#ip address 192.168.100.2 255.255.255.0
Router4(config-if)#no shutdown
Router4(config)#router bgp 20
Router4(config-router)#neighbor 192.168.100.1 remote-as 20
BGP AND LOOPBACK INTERFACES:
Router Network Traffic And The Loopback Interface: The Pimary Job Of A Router Is Forwarding Traffic Between Networks, But Routers Also Generate Some Network Traffic. Routers And Other Network Devices Communicate Using Various Management Protocols, Such As Routing Protocols, SNMP, NTP, And TFTP. When The Router Initiates A Network Connection, That Connection Must Have Some Source Address; Typically A Router Will Select A Source Address From One Of The Addresses Bound To One Of Its Network Interfaces. This Can Be Problematic In Several Ways, Mainly Because The Source Address For Some Services Can Vary.In Addition To Physical Interfaces, Cisco IOS Routers Have The Ability To Define Internal Virtual Interfaces, Called Loopback Interfaces. It Is Considered Best Practice, In Configuring Cisco Routers, To Define One Loopback Interface, And Designate It As The Source Interface For Most Traffic Generated By The Router Itself. Adopting This Practice Yields Several Benefits For The Overall Stability And Security Management Of A Network, Because The Address Of The Loopback Interface Is Fixed.
When A Router Is Configured To Use The Loopback Interface For Services, It Is Possible To Configure The Security Of Other Devices In The Network More Tightly. (When A Service Is Configured To Use The Loopback Interface As Its Source, We Say That The Service Is Bound To That Interface. It Means That IP Packets Generated By The Router Will Have The Loopback Interface’s Address As Their Source Address. Also, The Loopback Interface’s Address Does Not Appear In Any Route-Based Network Maps; Hiding Administrative Aspects Of Your Network From Potential Attackers Is Usually Good Practice.
To Create A Loopback Interface, Simply Assign It An IP Address. Router1# Config T
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)# Interface Loopback0
Router1(Config-If)# Description Main Loopback Interface
Router1(Config-If)# Ip Address 14.2.11.250 255.255.255.255
Router1(Config-If)# End
Router1#
BGP AND LOOPBACK INTERFACES: Using A Loopback Interface To Define Neighbors Is Commonly Used With IBGP Rather Than EBGP. Normally The Loopback Interface Is Used To Make Sure That The IP Address Of The Neighbor Stays Up And Is Independent Of A Hardware That Might Be Flaky. In The Case Of EBGP, Most Of The Time The Peer Routers Are Directly Connected And Loopback Does Not Apply.
If The IP Address Of A Loopback Interface Is Used In The Neighbor Command, Some Extra Configuration Needs To Be Done On The Neighbor Router. The Neighbor Router Needs To Tell BGP That It Is Using A Loopback Interface Rather Than A Physical Interface To Initiate The BGP Neighbor TCP Connection.
The Command Used To Indicate A Loopback Interface Is:
NEIGHBOR IP-ADDRESS UPDATE-SOURCE IN LOOPBACK TERFACE
Router A: Router BGP 100
Neighbor 190.225.11.1 Remote-As 100
Neighbor 190.225.11.1 Update-Source Int Loopback 1
Router B: Router BGP 100
Neighbor 150.212.1.1 Remote-As 100
In The Above Example, Router A And Router B Are Running Internal BGP Inside Autonomous System 100. Router B Is Using In Its Neighbor Command The Loopback Interface Of Router A (150.212.1.1); In This Case Router A Has To Force BGP To Use The Loopback IP Address As The Source In The TCP Neighbor Connection.
Router A Will Do So By Adding The Update-Source Int Loopback Configuration (Neighbor 190.225.11.1 Update-Source Int Loopback 1) And This Statement Forces BGP To Use The IP Address Of Its Loopback Interface When Talking To Neighbor 190.225.11.1.
Note That Router A Has Used The Physical Interface IP Address (190.225.11.1) Of Router B As A Neighbor And That Is Why RTB Does Not Need To Do Any Special Configuration.
BGP PEER CONNECTIONS:
Config-Router# Neighbor 10.1.1.2 ShutdownConfig# Clear IP BGP *
BGP NEIGHBOR TIMERS:
To Set The Timers For A Specific BGP Peer Or Peer Group, Use The Neighbor Timers Command In Router Configuration Mode. To Clear The Timers For A Specific BGP Peer Or Peer Group, Use The No Form Of This Command.neighbor [ip-address | peer-group-name] timers keepalive holdtime
no neighbor [ip-address | peer-group-name] timers keepalive holdtime
IP-Address - > (Optional) A BGP Peer Or Peer Group IP Address.
Peer-Group-Name - > (Optional) Name Of The BGP Peer Group.
Keepalive - > Frequency (In Seconds) With Which The Cisco IOS Software Sends Keepalive Messages To Its Peer. The Default Is 60 Seconds.
Holdtime - > Interval (In Seconds) After Not Receiving A Keepalive Message That The Software Declares A Peer Dead. The Default Is 180 Seconds.
Defaults Keepalive: 60 Seconds Holdtime: 180 Seconds
The Timers Configured For A Specific Neighbor Or Peer Group Override The Timers Configured For All BGP Neighbors Using The Timers BGP Command.
The Following Example Changes The Keepalive Timer To 70 Seconds And The Hold-Time Timer To 210 Seconds For The BGP Peer 192.98.47.0:
Router BGP 109
Neighbor 192.98.47.0 Timers 70 210
NETWORK BACKDOOR ROUTES:
Having A Low Default AD (20) For EBGP Routes Can Cause A Problem In Some Topologies. BGP Offers An Elegant Solution To This Particular Problem Through The Use Of The Network Backdoor Command.To Specify A Backdoor Route To A BGP-Learned Prefix That Provides Better Information About The Network,Use The Network Backdoor Command In Address Family Or Router Configuration Mode. To Remove An Address From The List, Use The No Form Of This Command.
network ip-address backdoor
no network ip-address backdoor
A Backdoor Network Is Assigned An Administrative Distance Of 200. The Objective Is To Make Interior Gateway Protocol (IGP) Learned Routes Preferred. A Back Door Network Is Treated As A Local Network, Except That It Is Not Advertised. A Network That Is Marked As A Backdoor Is Not Sourced By The Local Router, But Should Be Learned From External Neighbors. The BGP Best Path Selection Algorithm Does Not Change When A Network Is Configured As A Back Door.
The Following Address Family Configuration Example Configures Network 10.108.0.0 As A Local Network And Network 192.168.7.0 As A Backdoor Network:
Router BGP 109
Address-Family Ipv4 Multicast - > Address Family Configuration Mode Was Added.
Network 10.108.0.0
Network 192.168.7.0 Backdoor
The Following Router Configuration Example Configures Network 10.108.0.0 As A Local Network And Network 192.168.7.0 As A Backdoor Network:
Router BGP 109
Network 10.108.0.0
Network 192.168.7.0 Backdoor
Address-Family Ipv4 - > Places The Router In Address Family Configuration Mode For Configuring Routing Sessions Such As BGP, RIP, Or Static Routing Sessions That Use Standard IP Version 4 Address Prefixes.
NETWORK ADVERTISEMENTS:
The Network Command Will Work If The Network You Are Trying To Advertise Is Known To The Router, Whether Connected, Static Or Learned Dynamically (Networks Are Originated).An Example Of The Network Command Follows:
Network Network-Number [Mask Network-Mask]
Config-Router# Network 10.5.1.0 Mask 255.255.255.0
Config-Router# No Synchronization
Config-Router# Neighbor 172.16.12.1 Next-Hop-Self (Tell Router That You Are The Next Hop)
The Mask Portion Is Used Because BGP4 Can Handle Subnetting And Supernetting. A Maximum Of 200 Entries Of The Network Command Are Accepted.
AN EXAMPLE: Router A#
Router BGP 1
Network 192.213.0.0 Mask 255.255.0.0
Ip Route 192.213.0.0 255.255.0.0 Null 0
The Above Example Indicates That Router A, Will Generate A Network Entry For 192.213.0.0/16. The /16 Indicates That We Are Using A Supernet Of The Class C Address And We Are Advertizing The First Two Octets (The First 16 Bits).
Note: That We Need The Static Route To Get The Router To Generate 192.213.0.0 Because The Static Route Will Put A Matching Entry In The Routing Table.
The Null 0 Interface Means Disregard The Packet. So If I Get The Packet And There Is A More Specific Match Than 192.213.0.0 (Which Exists Of Course) The Router Will Send It To The Specific Match Otherwise It Will Disregard It. This Is A Nice Way To Advertise A Supernet.
EBGP MULTIHOP:
In Some Special Cases, The Cisco Router Could Be Running External BGP With A Third Party Router That Does Not Allow The Two External Peers To Be Directly Connected. In This Case EBGP Multihop Is Used To Allow The Neighbor Connection To Be Established Between Two Non Directly Connected External Peers. The Multihop Is Used Only For External BGP And Not For Internal BGP.RouterA#
Router BGP 100
Neighbor 180.225.11.1 Remote-As 300
Neighbor 180.225.11.1 EBGP-Multihop
RouterB#
Router BGP 300
Neighbor 129.213.1.2 Remote-As 100
RouterA Is Indicating An External Neighbor That Is Not Directly Connected. RouterA Needs To Indicate That It Will Be Using EBGP-MULTIHOP.
On The Other Hand, RouterB Is Indicating A Neighbor That Is Directly Connected (129.213.1.2) And That Is Why It Does Not Need The EBGP-MULTIHOP Command.
Some IGP Or Static Routing Should Also Be Configured In Order To Allow The Non Connected Neighbors To Reach Eachother.
The Following Example Shows How To Achieve Load Balancing With BGP In A Particular Case Where We Have EBGP Over Parallel Lines.
RouterA#
Int Loopback 0
Ip Address 150.10.1.1 255.255.255.0
Router BGP 100
Neighbor 160.10.1.1 Remote-As 200
Neighbor 160.10.1.1 EBGP-Multihop
Neighbor 160.10.1.1 Update-Source Loopback 0
Network 150.10.0.0
Ip Route 160.10.0.0 255.255.0.0 1.1.1.2
Ip Route 160.10.0.0 255.255.0.0 2.2.2.2
RouterB#
Int Loopback 0
Ip Address 160.10.1.1 255.255.255.0
Router BGP 200
Neighbor 150.10.1.1 Remote-As 100
Neighbor 150.10.1.1 Update-Source Loopback 0
Neighbor 150.10.1.1 EBGP-Multihop
Network 160.10.0.0
Ip Route 150.10.0.0 255.255.0.0 1.1.1.1
Ip Route 150.10.0.0 255.255.0.0 2.2.2.1
In Above Example Illustrates The Use Of Loopback Interfaces, Update-Source And EBGP-Multihop.
This Is A Workaround In Order To Achieve Load Balancing Between Two EBGP Speakers Over Parallel Serial Lines. In Normal Situations, BGP Will Pick One Of The Lines To Send Packets On And Load Balancing Would Not Take Place. By Introducing Loopback Interfaces, The Next Hop For EBGP Will Be The Loopback Interface. Static Routes (It Could Be Some IGP Also) Are Used To Introduce Two Equal Cost Paths To Reach The Destination. RouterA Will Have Two Choices To Reach Next Hop 160.10.1.1: One Via 1.1.1.2 And The Other One Via 2.2.2.2 And The Same For RouterB.
BGP ROUTE MAPS (Filtering BGP Updates):
Route Maps Can Be Used For Both Redistribution And For Policy Routing. They Are Also Used Frequently In Large-Scale Border Gateway Protocol (BGP) Implementations. Policy Routes Are Nothing More Than Sophisticated Static Routes. Whereas Static Routes Forward A Packet To A Specified Next Hop Based On The Destination Address Of The Packet, Policy Routes Forward A Packet To A Specified Next Hop Based On The Source Of The Packet. Policy Routes Can Also Be Linked To Extended IP Access Lists So That Routing May Be Based On Such Things As Protocol Types And Port Numbers. Like A Static Route, A Policy Route Influences The Routing Only Of The Router On Which It Is Configured.In The BGP Context, Route Map Is A Method Used To Control And Modify Routing Information. This Is Done By Defining Conditions For Redistributing Routes From One Routing Protocol To Another Or Controlling Routing Information When Injected In And Out Of BGP. The Format Of The Route Map Follows:
Route-Map Map-Tag [[Permit | Deny] | [Sequence-Number]]
The Map-Tag Is Just A Name You Give To The Route-Map. Multiple Instances Of The Same Route Map (Same Name-Tag) Can Be Defined. The Sequence Number Is Just An Indication Of The Position A New Route Map Is To Have In The List Of Route Maps Already Configured With The Same Name.
For Example, If Define Two Instances Of The Route Map, Let Us Call It My Prem, The First Instance Will Have A Sequence-Number Of 10, And The Second Will Have A Sequence Number Of 20.
Route-Map My Prem Permit 10 - > (First Set Of Conditions Goes Here.)
Route-Map My Prem Permit 20 - > (Second Set Of Conditions Goes Here.)
When Applying Route Map My Prem To Incoming Or Outgoing Routes, The First Set Of Conditions Will Be Applied Via Instance 10. If The First Set Of Conditions Is Not Met Then We Proceed To A Higher Instance Of The Route Map.
Match And Set Configuration Commands. Each Route Map Will Consist Of A List Of Match And Set Configuration. The Match Will Specify A Match Criteria And Set Specifies A Set Action If The Criteria Enforced By The Match Command Are Met.
Define A Route Map That Checks Outgoing Updates And If There Is A Match For IP Address 1.1.1.1 Then The Metric For That Update Will Be Set To 5. The Above Can Be Illustrated By The Following Commands:
Match IP Address 10.10.10.1
Set Metric 5
Configuring Route Maps: Route Maps By Themselves Affect Nothing; They Must Be "Called" By Some Command. The Command Will Be Either A Policy Routing Command Or A Redistribution Command. Policy Routing Will Send Packets To The Route Map, Whereas Redistribution Will Send Routes To The Route Map. The Case Studies In This Section Demonstrate The Use Of Route Maps For Both Redistribution And Policy Routing.
Route Maps Are Identified By A Name. For Example, The Following Route Map Is Named My Prem: Route-Map My Prem Permit 10
Match Ip Address 110
Set Metric 100
Each Route Map Statement Has A "Permit" Or "Deny" Action And A Sequence Number. This Route Map Shows A Permit Action And A Sequence Number Of 10. These Settings Are The Defaults—That Is, If No Action Or Sequence Number Is Specified When The Route Map Is Configured, The Route Map Will Default To A Permit And A Sequence Number Of 10.
The Sequence Number Allows The Identification And Editing Of Multiple Statements. Consider The Following Configuration Steps: Nus(Config)#Route-My Prem20
Nus(Config-Route-Map)#Match Ip Address 111
Nus(Config-Route-Map)#Set Metric 50
Nus(Config-Route-Map)#Route-Map My Prem 15
Nus(Config-Route-Map)#Match Ip Address 112
Nus(Config-Route-Map)#Set Metric 80
Here A Second And Third Set Of Route Map Statements, Each With Their Own Match And Set Statements, Have Been Added To Route Map My Prem. Notice That A Sequence Number Of 20 Was Configured First And Then A Sequence Number Of 15. In The Final Configuration, Configuration, The IOS Has Placed Statement 15 Before 20 Even Though It Was Entered Later:
The Sequence Numbers Also Allow For The Elimination Of Individual Statements. For Example, The Statement: Nus(Config)#No Route-Map Hagar 15 - > Deletes Statement 15
Now, If The Match Criteria Are Met And We Have A Permit Then The Routes Will Be Redistributed Or Controlled As Specified By The Set Action And We Break Out Of The List.
If The Match Criteria Are Met And We Have A Deny Then The Route Will Not Be Redistributed Or Controlled And We Break Out Of The List.
If The Match Criteria Are Not Met And We Have A Permit Or Deny Then The Next Instance Of The Route Map (Instance 20 For Example) Will Be Checked, And So On Until We Either Break Out Or Finish All The Instances Of The Route Map. If We Finish The List Without A Match Then The Route We Are Looking At Will Not Be Accepted Nor Forwarded.
One Restriction On Route Maps Is That When Used For Filtering BGP Updates Rather Than When Redistributing Between Protocols, You Can NOT Filter On The Inbound When Using A "Match" On The IP Address.
Following Commands Show:
Config# Access-List 25 Deny 172.0.0.0 0.0.0.0 Permit Any (Match Specific Subnet)
Config-Router# Distribute-List 25 Out (Filter From All Routers)
Config-Router# Neighbor 10.14.1.2 Distribute-List 25 Out (Filter For Specific Neighbor)
Config# Ip Prefix-List Word Deny 172.0.0.0/8
Config# Ip Prefix-List Word Permit 0.0.0.0/0 Le 32 (Less Then Equal To 32)
Config-Router# Neighbor 10.12.1.1 Prefix-List Word Out
Config# Route-Map Word
Config-Route-Map# Match Ip Address 25
Config-Router# Neighbor 10.14.1.2 Route-Map Word Out
Route Maps And Redistribution: A Route Map Can Be Used With Redistribution By Adding A Call To The Route Map In The Redistribute Command.
EXAMPLE 1:
RouterA And RouterB Are Running Rip; RouterA And RouterC Are Running BGP.RouterA Is Getting Updates Via BGP And Redistributing Them To Rip. If RouterA Wants To Redistribute To RouterB Routes About 170.10.0.0 With A Metric Of 2 And All Other Routes With A Metric Of 5 Then We Might Use The Following Configuration:
RouterA#
Router Rip
Network 3.0.0.0
Network 2.0.0.0
Network 150.10.0.0
Passive-Interface Serial0
Redistribute BGP 100 Route-Map SETMETRIC
Router BGP 100
Neighbor 2.2.2.3 Remote-As 300
Network 150.10.0.0
Route-Map SETMETRIC Permit 10
Match Ip-Address 1
Set Metric 2
Route-Map SETMETRIC Permit 20
Set Metric 5
Access-List 1 Permit 170.10.0.0 0.0.255.255
In The Above Example, If A Route Matches The IP Address 170.10.0.0 It Will Have A Metric Of 2 And Then We Break Out Of The Route Map List. If There Is No Match Then We Go Down The Route Map List Which Says, Set Everything Else To Metric 5. It Is Always Very Important To Ask The Question, What Will Happen To Routes That Do Not Match Any Of The Match Statements Because They Will Be Dropped By Default.
EXAMPLE 2:
Suppose In The Above Example We Did Not Want AS100 To Accept Updates About 170.10.0.0. Since Route Maps Cannot Be Applied On The Inbound When Matching Based On An IP Address, We Have To Use An Outbound Route Map On RouterC:RouterC#
Router BGP 300
Network 170.10.0.0
Neighbor 2.2.2.2 Remote-As 100
Neighbor 2.2.2.2 Route-Map STOPUPDATES Out
Route-Map STOPUPDATES Permit 10
Match Ip Address 1
Access-List 1 Deny 170.10.0.0 0.0.255.255
Access-List 1 Permit 0.0.0.0 255.255.255.255
BGP ROUTE REFLECTORS & BGP CONFEDERATIONS:
BGP Offers Two Tools (Confederations And Route Reflectors) That Reduce The Number Of Peer Connections Inside An AS, Prevent Loops, And Allow All Routers To Learn About All Prefixes.■ 1. BGP Route Reflectors – > Simpler To Deploy And Run
■ 2. BGP Confederations – > More Complex, Corner Case Benefits
BGP ROUTE REFLECTORS:
- ► Reflector Receives Path From Clients And Non-Clients- ► Selects Best Path
- ► If Best Path Is From Client, Reflect To Other Clients And Non-Clients
- ► If Best Path Is From Non-Client, Reflect To Clients Only
- ► Non-Meshed Clients
- ► Described In RFC2796
Normal Route Reflector Operation For A Route Sent To The Reflector By A Client — It Is Reflected To All Clients And Nonclients. Normal Route Reflector Operation For Routes Received From A Nonclient — It Is Reflected Only To Clients.
Note:IBGP Peering Within An AS Is Route Reflectors (RRs). As The IBGP Section Demonstrates, A BGP Speaker Does Not Advertise A Route That The BGP Speaker Learned Via Another IBGP Speaker To A Third IBGP Speaker. You Can Relax This Restriction A Bit And Provide Additional Control, Which Allows A Router To Advertise, Or Reflect, IBGP Learned Routes To Other IBGP Speakers. This Route Reflection Reduces The Number Of IBGP Peers Within An AS.
BENEFITS OF ROUTE REFLECTOR:
- ► Solves IBGP Mesh Problem
- ► Packet Forwarding Is Not Affected
- ► Normal BGP Speakers Co-Exist
- ► Multiple Reflectors For Redundancy
- ► Easy Migration
- ► Multiple Levels Of Route Reflectors
BGP Cluster-ID - > Configures The Cluster ID If The BGP Cluster Has More Than One Route Reflector.
Neighbor Route-Reflector-Client - > Configures The Router As A BGP Route Reflector And Configures The Specified Neighbor As Its Client. (Neighbor IP-Address Route-Reflector-Client - > BGP Mode; Used On The RR Server, Identifies A Neighbor As An RR Client / Configs An IBGP Neighbor To Be A Client Of This Reflector)
◙ When Reflector Receives Route Directly, Route Reflectors Mesh With Other Route Reflctors And Non Clients No In Another Cluster.
◙ When Reflector Doesn’t Receive Route Directly Non-Reflector Only Allowed To Reflect To Clients.
Example:
Config-Router# BGP Cluster-ID 1
Config-Router# Neighbor 10.12.1.2 Route-Reflector-Client (Disable Split-Horizon To Client)
Example For Configuring a Route Reflector:
Router BGP 100
Neighbor 1.1.1.1 Remote-As 100
Neighbor 1.1.1.1 Route-Reflector-Client
Neighbor 2.2.2.2 Remote-As 100
Neighbor 2.2.2.2 Route-Reflector-Client
Neighbor 3.3.3.3 Remote-As 100
Neighbor 3.3.3.3 Route-Reflector-Client
Guidelines By Default, The Clients Of A Route Reflector Are Not Required To Be Fully Meshed And The Routes From A Client Are Reflected To Other Clients. However, If The Clients Are Fully Meshed, Route Reflection Is Not Required. Use The No BGP Client-To-Client Reflection Command To Disable Client-To-Client Reflection.
In The Following Router Configuration Mode Example, The Local Router Is A Route Reflector. The Three Neighbors Are Fully Meshed, So Client-To-Client Reflection Is Disabled.
Router BGP 5
Neighbor 10.24.95.22 Route-Reflector-Client
Neighbor 10.24.95.23 Route-Reflector-Client
Neighbor 10.24.95.24 Route-Reflector-Client
No BGP Client-To-Client Reflection
In The Following Address Family Configuration Mode Example, The Local Router Is A Route Reflector. The Three Neighbors Are Fully Meshed, So Client-To-Client Reflection Is Disabled.
Router BGP 5
Address-Family IPv4 Unicast
Neighbor 10.24.95.22 Route-Reflector-Client
Neighbor 10.24.95.23 Route-Reflector-Client
Neighbor 10.24.95.24 Route-Reflector-Client
No BGP Client-To-Client Reflection
BGP CONFEDERATIONS:
BGP Confederations, As Defined In RFC 3065, Separates Each Router In The AS Into One Of Several Confederation Sub-Autonomous Systems. Peers Inside The Same Sub-AS Are Considered To Be Confederation IBGP Peers, And Routers In Different Sub-Autonomous Systems Are Considered To Be Confederation EBGP Peers.Confederations Propagate Routes To All Routers, Without A Full Mesh Of Peers Inside The Entire AS. To Do So, Confederation EBGP Peer Connections Act Like True EBGP Peers In Some Respects. In A Single Sub-AS, The Confederation IBGP Peers Must Be Fully Meshed, Because They Act Exactly Like Normal IBGP Peers—In Other Words, They Do Not Advertise IBGP Routes To Each Other. However, Confederation EBGP Peers Act Like EBGP Peers In That They Can Advertise IBGP Routes Learned Inside Their Confederation Sub-AS Into Another Confederation Sub-AS.
Confederations Prevent Loops Inside A Confederation AS By Using The AS_PATH PA. BGP Routers In A Confederation Add The Sub-Autonomous Systems Into The AS_PATH As Part Of An AS_PATH Segment Called The AS_CONFED _SEQ And AS_CONFED_SET;.
To Configure A BGP Confederation, Issue This Command: BGP Confederation Identifier Autonomous-System - > The Confederation Identifier Is The AS Number Of The Confederation Group.
BGP Confederation Peers Autonomous-System [Autonomous-System] - > The Issue Of This Command Performs Peering Between Multiple Ass Within The Confederation.
Code: Router BGP Member-As-Number
BGP Confederation Identifier External-As-Number
BGP Confederation Peers List-Of-Intra-Confederation-As
Config# Router BGP
Config-Router# BGP Confederation Identifier
Config-Router# BGP Confederation Peers
Guidelines One Way To Reduce The Internal BGP (IBGP) Mesh Is To Divide An Autonomous System Into Multiple Autonomous Systems And Group Them Into A Single Confederation. Each Autonomous System Is Fully Meshed Within Itself And Has A Few Connections To Another Autonomous System In The Same Confederation. Even Though The Peers In Different Autonomous Systems Have External BGP (EBGP) Sessions, They Exchange Routing Information As If They Are IBGP Peers. Specifically, The Next Hop, Multi Exit Discriminator (MED), And Local Preference Information Is Preserved. The Preservation Of This Information 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.
In The Following Example, The Autonomous System Is Divided Into Autonomous Systems 4001, 4002, 4003, 4004, 4005, 4006, And 4007 And Identified By The Confederation Identifier 5. Neighbor 10.2.3.4 Is Someone Inside Your Routing Domain Confederation. Neighbor 10.4.5.6 Is Someone Outside Your Routing Domain Confederation. To The Outside World, There Appears To Be A Single Autonomous System With The Number 5.
Router BGP 4001
BGP Confederation Identifier 5
BGP Confederation Peers 4002 4003 4004 4005 4006 4007
Neighbor 10.2.3.4 Remote-As 4002
Neighbor 10.4.5.6 Remote-As 510
Note:The Implementation Of BGP Confederation Reduces The IBGP Mesh Inside An AS. The Trick Is To Divide An AS Into Multiple ASs And Assign The Whole Group To A Single Confederation. Each AS Alone Has IBGP Fully Meshed And Has Connections To Other ASs Inside The Confederation.
Even Though These ASs Have EBGP Peers To ASs Within The Confederation, The ASs Exchange Routing As If They Used IBGP.
In This Way, The Confederation Preserves Next Hop, Metric, And Local Preference Information. To The Outside World, The Confederation Appears To Be A Single AS.
BGP REDISTRIBUTION:
The Redistribute Command Redistributes Only Routes In That Router’s Current IP Routing Table. When Redistributing From A Given Routing Protocol, The Redistribute Command Takes Routes Listed In The IP Routing Table As Being Learned From That Routing Protocol. Interestingly, The Redistribute Command Can Also Pick Up Connected Routes. The BGP Redistribute Subcommand Can Redistribute Static, Connected, And IGP-Learned Routes. An Advertise BGP Via Redistribute To IGP (IGRP, OSPF, RIP, EIGRP, Etc.) Into BGP.Config# Router BGP 7000
Config-Router# Neighbor 10.12.1.1 Remote-Ad 7000
Config-Router# Redistribute OSPF 10
Config-Router# Neighbor 10.12.1.1 Next-Hop-Self
Config-Router# Neighbor 10.46.1.6 Route-Reflector-Client
Config-Router# No Synchronization
RouterA Is Announcing 129.213.1.0 And RouterC Is Announcing 175.220.0.0. Look At RouterC's Configuration:
RouterC#
Router EIGRP 10
Network 175.220.0.0
Redistribute BGP 200
Default-Metric 1000 100 250 100 1500
Router BGP 200
Neighbor 1.1.1.1 Remote-As 300
Network 175.220.0.0 Mask 255.255.0.0 (This Will Limit The Networks Originated By Your AS To 175.220.0.0)
If You Use Redistribution Instead You Will Have:
RouterC#
Router EIGRP 10
Network 175.220.0.0
Network 175.220.0.0
Redistribute BGP 200
Default-Metric 1000 100 250 100 1500
Router BGP 200
Neighbor 1.1.1.1 Remote-As 300
Redistribute EIGRP 10 (EIGRP Will Inject 129.213.1.0 Again Into BGP)
This Will Cause 129.213.1.0 To Be Originated By Your AS. This Is Misleading Because You Are Not The Source Of 129.213.1.0 But AS100 Is. So You Would Have To Use Filters To Prevent That Network From Being Sourced Out By Your AS. The Correct Configuration Would Be: RouterC#
Router EIGRP 10
Network 175.220.0.0
Redistribute BGP 200
Default-Metric 1000 100 250 100 1500
Router BGP 200
Neighbor 1.1.1.1 Remote-As 300
Neighbor 1.1.1.1 Distribute-List 1 Out
Redistribute EIGRP 10
Access-List 1 Permit 175.220.0.0 0.0.255.255
The Access-List Is Used To Control What Networks Are To Be Originated From AS200.
BGP STATIC ROUTES AND REDISTRIBUTION:
Static Routes To Originate A Network Or A Subnet. The Only Difference Is That Bgp Will Consider These Routes As Having An Origin Of Incomplete (Unknown). In The Above Example The Same Could Have Been Accomplished By Doing:RouterC#
Router EIGRP 10
Network 175.220.0.0
Redistribute BGP 200
Default-Metric 1000 100 250 100 1500
Router BGP 200
Neighbor 1.1.1.1 Remote-As 300
Redistribute Static
IP Route 175.220.0.0 255.255.255.0 Null0
The Null 0 Interface Means Disregard The Packet. So If I Get The Packet And There Is A More Specific Match Than 175.220.0.0 (Which Exists Of Course) The Router Will Send It To The Specific Match Otherwise It Will Disregard It. This Is A Nice Way To Advertise A Supernet.
We Have Discussed How We Can Use Different Methods To Originate Routes Out Of Our Autonomous System. Please Remember That These Routes Are Generated In Addition To Other BGP Routes That BGP Has Learned Via Neighbors (Internal Or External). BGP Passes On Information That It Learns From One Peer To Other Peers. The Difference Is That Routes Generated By The Network Command, Or Redistribution Or Static, Will Indicate Your As As The Origin For These Networks. Injecting BGP Into IGP Is Always Done By Redistribution.
BGP MD5 AUTHENTICATION:
BGP MD5 Authentication, Which Is The Only Type Of BGP Authentication Supported In Cisco IOS. BGP Peers Can Be Protected From Dos, Spoofing, And Man-In-The-Middle Attacks By Implementing RFC 2385, “Protection Of BGP Sessions Via The TCP MD5 Signature Option” . This Security Mechanism Operates Between Two BGP Peers And Requires The Configuration Of A Shared Key On Each Of These Peers. The Shared Key Is Used To Create And Verify The MD5 Signature (I.E. One-Way Hash) For Each Segment Transmitted And Received During The BGP Session Respectively. The Shared Key Takes The Form Of A Password Configured On Each Peer Router.Config-Router# Neighbor ... Password Word (MD5)
The Following Two-Part Example It’s Shows How The Network Administrators Of Router1In AS 26625 And The Network Administrators Of ISP Router2 In AS 27701 Would Use The MD5 Shared Key “PrEm4all”.
When Configuring MD5 Authentication For Their Peering Session With Router1 Via ISP Router2. The Commands Below Would Be Performed On Router1 With ISP Router2 Using MD5 Shared Key “PrEm4all”: Router1#Config T
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)# Router BGP 26625
Router1(Config-Router)# Neighbor 14.2.0.250 Remote-As 27701
Router (Config-Router)# Neighbor 14.2.0.250 Password PrEm4all
Router1(Config-Router)# End
Router1#
The Commands Below Would Have To Be Performed By The Network Administrators Of The ISP Router2 To Which Router1Has A BGP Peering Connection With MD5 Shared Key “PrEm4all”: Router2# Config T
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router2(Config)# Router BGP 27701
Router2(Config-Router)# Neighbor 14.2.0.20 Remote-As 26625
Router2(Config-Router)# Neighbor 14.2.0.20 Password PrEm4all
Router2(Config-Router)# End
Router2#
BGP SUMMARIZATION:
Route Summarization Creates A Single Route Whose Numeric Range, As Implied By The Prefix/Prefix Length, Is Larger Than The One Or More Smaller Component Routes.Manual BGP Route Summarization, Using The Aggregate-Address BGP Router Subcommand, Provides The Flexibility To Allow None, All, Or A Subset Of The Summary’s Component Subnets To Be Advertised Out Of The BGP Table. By Allowing Some And Not Others, The Aggregate-Address Command Can In Effect Filter Some Routes.
The Filtering Options On The Aggregate-Address Command Are As Follows:
◙ Filtering All Component Subnets Of The Summary From Being Advertised, By Using The Summary-Only Keyword
◙ Advertising All The Component Subnets Of The Summary, By Omitting The Summary-Only Keyword
◙ Advertising Some And Filtering Other Component Subnets Of The Summary, By Omitting The Summary-Only Keyword And Referring To A Route Map Using The Suppress-Map Keyword
The Logic Behind The Suppress-Map Option Can Be A Little Tricky. This Option Requires Reference To A Route Map, With Any Component Subnets Matching A Route Map Permit Clause Being Suppressed — In Other Words, Routes Permitted By The Route Map Are Filtered And Not Advertised. The Router Does Not Actually Remove The Suppressed Route From Its Local BGP Table; However, It Does Suppress The Advertisement Of Those Routes.
Config-Router# Aggregate-Address 172.0.0.0 255.0.0.0 Summary-Only (Only Send Summary To Everyone)
Config# Access-List 30 Permit 172.0.0 0.255.255.255 (Match All 172.X.X.X Routes)
Config# Route-Map Word
Config-Route-Map# Match Ip Address 30
Config-Router# Aggregate-Address 172.0.0.0 255.0.0.0 Suppress-Map Word (Dont Send Any Routes That Match The Route Map)
Config-Router# Neighbor 10.14.1.2 Unsuppress-Map Word (Invert The Route Map For This Network)
MORE REFFERENCE FOR BGP:
◙ - ► For More About - > BORDER GATEWAY PROTOCOL (BGP) NEIGHBORS CONCEPTS:
◙ - ► For More About - > BGP LAB (USING VIRTUAL LINK):
◙ - ► For More About - > BGP LAB FOR ROUTE REFLECTORS CLIENT:
◙ - ► For More About - > BGP LAB (REDISTRIBUTE BGP VERSUS OSPF):
◙ - ► For More About - > BGP REDISTRIBUTE VERSUS OSPF AND EIGRP:
◙ - ► For More About - > BGP MD5 AUTHENTICATION:
CONCLUSION:
The Goal Of This Article Is To Give An Easy Way To Understand The “BGP Quick References Method" And Also We Hope This Guide Will Help Every Beginner 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!Hands-On Experience Is An Invaluable Part Of Preparing For The Lab Exam And Never Pass Up An Opportunity To Configure Or Troubleshoot A Router ( If You Have Access To Lab Facilities, Take Full Advantage Of Them) There Is No Replacement For The Experience You Can Gain From Working In A Lab, Where You Can Configure Whatever You Want To Configure And Introduce Whatever Problems You Want To Introduce, Without Risk Of Disrupting A Production Network. Thank You And Best Of Luck.
This Article Written Author By: Premakumar Thevathasan - CCNA, CCNP, MCSE, MCSA, MCSA - MSG, CIW Security Analyst, CompTIA Certified A+ and Etc.
WARNING AND DISCLAIMER:
Routers Direct And Control Much Of The Data Flowing Across Computer Networks. This Guide Provides Technical Guidance Intended To Help All Network Students, Network Administrators And Security Officers Improve Of Their Demonstrated Ability To Achieve Specific objectives Within Set Timeframes.This Document Carries No Explicit Or Implied Warranty. Nor Is There Any Guarantee That The Information Contained In This Document Is Accurate. Every Effort Has Been Made To Make All Articles As Complete And As Accurate As Possible, But No Warranty Or Fitness Is Implied.
It Is Offered In The Hopes Of Helping Others, But You Use It At Your Own Risk. The Author Will Not Be Liable For Any Special, Incidental, Consequential Or Indirect Any Damages Due To Loss Of Data Or Any Other Reason That Occur As A Result Of Using This Document. But No Warranty Or Fitness Is Implied. The Information Provided Is On An "As Is" Basic. All Use Is Completely At Your Own Risk.
Home Page Of - > The School Of Cisco Networking (SCN)
Page Of - > SCN InF4 TECH
Contact Details / About Us Page
To Send Email
Window Minimize /
Window Maximize
No comments:
Post a Comment