Why do we need i-BGP for the routes when we have the IGP protocols (OSPF, IS-IS) for internal communication within the AS?

at

 Why do we need i-BGP for the routes when we have the IGP protocols (OSPF, IS-IS) for internal communication within the AS?


IGPs like OSPF or ISIS, are link-state protocols that give us all the information of the network and allow for very interesting convergence options and traffic engineering options. Whereas, BGP knows a very limited view of the network as a whole because BGP handles very well filtering and modifying routing information.


See, the traffic in a network can be divided into 4 categories.

• Ingress: traffic arriving from outside the network, destined for hosts within the network.

• Egress: traffic originating inside the network destined for hosts outside the network.

• Internal: traffic where both the origin and destination are within the network.

• Transit: traffic where both the origin and destination are outside the network.


The IGP normally carries internal routes, so it can be used to directly route ingress and internal traffic, but what about egress and transit traffic?


There are three choices -

• Use iBGP

• Use default routes.

• Redistribute external routes into your iGP.


Redistributing the whole internet routing table into your iGP will not end well. iGPs simply are not designed to deal with hundreds of thousands of routes.


If you have only one router that connects to the outside world, then you don't need iBGP. You can simply use a default route to direct egress traffic to your border router. If you have multiple routers that connect to providers then you can still use default routes, but by doing so you lose some of the advantages of multi-homing.


So, we'll be using i-BGP because of Scalability.

Thus, iBGP is required unless you're willing to redistribute all the routes.



#ibgp #bgp #network #cisco #huawei #free #learning

Read more
Labels:
Subscribe to: Posts (Atom)

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...