Border Gateway Protocol
BGP-version 4- Part 1
First Internet-How BGP evolved.
ARPANET-first internet backbone(core Gateway and non-core Gateway)
In the ARPANET system, the core gateways which made up the backbone were maintained by a central authority, the Internet Network Operations Center(INOC). They provided reliable and authoritative routes for all possible Internet networks, and connected the ARPANET to the other Internet networks
Non core-gateways were maintained by the organizations responsible for the individual Autonomous Systems and forwarded information about networks in their areas to the core gateways using EGP.
NSFNET-replaced ARPANET with new technological backbone and completely based on AS concept.
Model was different in aspect that it provided space for multi-core Internet during development though it was also initially based on single core Internet(NSFNET in centre). Its routing architecture and protocols have evolved accordingly.
After evolution of BGP in NSFNET, this requirement was eliminated that NSFNET will play central role. Thereon Internet is multi-core network in its present form.
Why there was a need of a defined and true exterior gateway protocol like BGP
Therefore, even if one assumes extreme instabilities of BGP, its worst case behavior will be the same as the steady state behavior of EGP.
BGP History
State of BGP
Routes learned via BGP must be validated by any IGP (Routing table) before they are advertised to other autonomous systems (AS) by eBGP process. If synchronization is enables(ON) Router3 will not advertise 203.0.0.0/16 route to Router5 unless that route is learned via some IGP (RIP or OSPF). Here we should note that Router 5 is in different AS.
Therefore we have two solutions::
It is also not a good bgp design practice to redistribute all bgp routes to IGP and viceversa which increases configuration overhead and security risks, , therefore synchronization is kept disabled by default in order to discourage it. For many years this technique is being used and optimized.
In the diagram if Synchronisation is disabled (off) which is disabled by default on cisco router, Router 3 will advertise the route to Router 5 but it will not appear in the router table of R5(appear only in BGP table).Therefore those routes will appear as Non-best BGP routes in R5. That is the reason when R5 tries to send traffic to 203.0.0.1, the non-BGP Router (R2) will create back-hole in the path and will discard the packet.
Route Reflectors came to the rescue to get full use of BGP and optimize route learing process in BGP. Further more in conjunction with MPLS/IP VPN RRs have provided best of solution in the industry.With MPLS core routers do not require to involve in customer routing anymore.
Remember: BGP run over TCP which is Layer 4 protocol. It is layered approach that for Layer 4 to work perfectly, all layer below should be up and running. It means, Layer 1, Layer 2 and Layer 3 should be established.
This approach put BGP in Layer 4 whereas it is said to be Layer 7 protocol which claims that all 6 lower layers should be up and running perfectly. Whatever the approach we posses, there should have IP connectivity between the potential BGP neighbor to BGP to work perfectly.
Continues...
Next Read
BGP Split Horizon
BGP Attributes and more...
BGP-version 4- Part 1
First Internet-How BGP evolved.
- ARPANET core gateways used the Gateway-to-Gateway Protocol, to exchange routing information.In addition to this role, it had to route data grams that were passing through the core system.
- ARPANET used Exterior Gateway Protocol (EGP) to collect connectivity information from non-core Gateways.
In the ARPANET system, the core gateways which made up the backbone were maintained by a central authority, the Internet Network Operations Center(INOC). They provided reliable and authoritative routes for all possible Internet networks, and connected the ARPANET to the other Internet networks
Non core-gateways were maintained by the organizations responsible for the individual Autonomous Systems and forwarded information about networks in their areas to the core gateways using EGP.
NSFNET-replaced ARPANET with new technological backbone and completely based on AS concept.
Model was different in aspect that it provided space for multi-core Internet during development though it was also initially based on single core Internet(NSFNET in centre). Its routing architecture and protocols have evolved accordingly.
After evolution of BGP in NSFNET, this requirement was eliminated that NSFNET will play central role. Thereon Internet is multi-core network in its present form.
Why there was a need of a defined and true exterior gateway protocol like BGP
- Most significant reason is a Single Internet backbone concept resulted to slow core due to scarcity of resources. Therefore, solution was not salable at all.
- High processing time and CPU overhead for EGP updates (With EGP the complete information is exchanged periodically usually every 3 minutes).
- As part of the BGP authentication mechanism, the protocol allows BGP to carry an encrypted digital signature in every BGP message. There was no such mechanism in EGP.
- EGP did not have any support for CIDR and summarization.
- EGP did not allow an AS to advertise any route that doesn't belong to that particular AS. Means there was no concept of AS path.
- Recall that the EGP was designed as a protocol to exchange reachability information between autonomous systems, rather than a true routing protocol. Therefore, there was not any loop prevention mechanism to make it simple.
- No support for path attributes and policy routing.
Therefore, even if one assumes extreme instabilities of BGP, its worst case behavior will be the same as the steady state behavior of EGP.
BGP History
- BGP-4 is the successor of BGP v2 and v3 and replaced EGP
- Design to route traffic through Autonomous System.
- Two flavors- iBGP and eBGP
- BGP uses TCP port 179 and currently in verson 4
- Router with the higher BGP router-id initiates BGP session from a random port.
- BGP finds BEST PATH to a network by using the best AS-PATH. So somewhat acts like RIP by default.
- Routing Policies are configured using BGP attributes
- BGP converge slowly. BGP process waits for update timer to expire before sending updates. Explained below in details in BGP update interval section.
- Neighbor relationship is kept separate from actual network advertisement.
- If you are a service provider and configuring a transit AS
- If you have redundant connection to different ISPs and whant to utilize both the links
- Advance routing policies and traffic engineering.
- Min RAM 128 MB recommended by IETF (Cisco recommends 512 MB.)
- Requires upper end IOS version to run BGP in CISCO router.
- Neighbors do not need to be directly connected.
- Neighbors are manually configured.
- All neighbors start in IDLE state.
- Once Neighborship is formed HELLO messages are sent in form of KEEPALIVES in every 60 secs. Dead Time is 180 secs.
- BGP neighbors are capable of MD5 authentication.
BGP update interval
BGP is a reliable protocol and designed with scalability as first objective. After initial connection setup, process does not require to send periodic updates. Instead of sending periodic updates, BGP process waits for update interval to expire and send triggered and increamental updates.
When there is a change in the network, BGP process waits for update interval time. Instead of using flash updates triggered by a change BGP waits for the expiration of the BGP advertise-interval before sending out the BGP update.In this way If there are other changes that should be advertised or changes are restored during that time the BGP process can prepare a more efficient update.
BGP update interval: after 5 secs for IBGP and 30 secs for EBGP routes.
State of BGP
- IDLE
- Active
- OPEN sent
- OPEN confirmed
- Established
- OPEN (Initialize)
- KEEPALIVES (Hello)
- UPDATE (Routing updates)
- NOTIFICATION(Errors)
- Neighbor Table
- BGP Table
- Routing Table
Routes learned via BGP must be validated by any IGP (Routing table) before they are advertised to other autonomous systems (AS) by eBGP process. If synchronization is enables(ON) Router3 will not advertise 203.0.0.0/16 route to Router5 unless that route is learned via some IGP (RIP or OSPF). Here we should note that Router 5 is in different AS.
Therefore we have two solutions::
- First, Run BGP everywhere and keep the synchronization off.
- Second, redistribute BGP routes into IGP(RIP,OSPF,ISIS), do vice versa at other end and keep the synchronization on.
It is also not a good bgp design practice to redistribute all bgp routes to IGP and viceversa which increases configuration overhead and security risks, , therefore synchronization is kept disabled by default in order to discourage it. For many years this technique is being used and optimized.
In the diagram if Synchronisation is disabled (off) which is disabled by default on cisco router, Router 3 will advertise the route to Router 5 but it will not appear in the router table of R5(appear only in BGP table).Therefore those routes will appear as Non-best BGP routes in R5. That is the reason when R5 tries to send traffic to 203.0.0.1, the non-BGP Router (R2) will create back-hole in the path and will discard the packet.
Route Reflectors came to the rescue to get full use of BGP and optimize route learing process in BGP. Further more in conjunction with MPLS/IP VPN RRs have provided best of solution in the industry.With MPLS core routers do not require to involve in customer routing anymore.
Remember: BGP run over TCP which is Layer 4 protocol. It is layered approach that for Layer 4 to work perfectly, all layer below should be up and running. It means, Layer 1, Layer 2 and Layer 3 should be established.
This approach put BGP in Layer 4 whereas it is said to be Layer 7 protocol which claims that all 6 lower layers should be up and running perfectly. Whatever the approach we posses, there should have IP connectivity between the potential BGP neighbor to BGP to work perfectly.
Continues...
Next Read
BGP Split Horizon
BGP Attributes and more...
Please read BGP-version 4- Part 2 for more information.
No comments:
Post a Comment