From: Marko Milivojevic (markom@markom.info)
Date: Tue Feb 17 2009 - 11:45:46 ARST
> Because Ebgp TTL is 1 by default but for IBGP TTL is 255 by default
...
> That's the way the RFC was written. It assumes EBGP peering will be done on
> a directly connected physical link to a neighbor.
While these are surely the technical reasons, which explain the
behaviour, they do nothing to help understand the deeper reason behind
it.
The reason lies in the very fact that BGP is not really a routing
protocol. It's a technical tool to implement non-technical decisions.
You must have noticed in the process of learning about BGP that most
of the tasks are pretty arbitrary, like "send traffic for X via Y" and
how easy it is to implement them. For example, in real life, sometimes
"the best path" is "the most expensive one" and we are supposed to use
it only when we must, not all the time... which would be the case with
most IGP's.
The reason for different behaviour in eBGP and iBGP is simple - the
primary function of BGP is to exchange information _between_
autonomous systems. The "routing" within AS is left for IGP.
When BGP speaks to another AS, it assumes that it's the only source of
routing information and it requires the other neighbor to be directly
connected for this particular reason.
On the other hand, when peering with internal neighbor, BGP assumes
that it's not the sole source of routing information and it accepts
the existence of IGP that will take care of intra-AS transport. In the
wonderful world of SP networks, this combined with MPLS transport
allows for great scalability and interesting solutions (BGP-free core,
etc.).
-- Marko CCIE #18427 (SP)Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:11 ARST