Hi. I'm on Christmas break from high school and I'm planning on taking the Routing Exam of January 4. It seems that my weakest point at the moment is BGP, and any questions can't be readily answered since I dont have a teacher around of course. So I figured I'd come here since you guys would probably know..

What is the conceptual reason for using Internal BGP? Why not just let OSPF or EIGRP handle it?

Thank you for your time.

__________________
Lain -- CCNA, CCDA
Assistant Network Administrator
Network Operations Center
Computer Services and Telecommunications
Information Technologies and Resources

Report this post to a moderator

Hey Lain,
I think in a way, we are both on the same boat.

IBGP is an internal version of bgp. It is always efficient and easier to deal with another igp(like eigrp and ospf) and work it with ebgp when your internal as routing is the priority. When you use IBGP then your going to have to turn the bgp sunchronization off so the bgp do not wait for an igp protocol to synchronize it's table.

BGP synchronization rule states that a bgp router should not use or advertise to an external neighbor a route learned by IBGP unless that route is local or is learned from the IGP.

Some isp's run total bgp cuz they cannot afford additional overhead of another routing process and by running ibgp you can also set internal policies which are not covered in our bscn courseware.
*When running IBGP only you also need to set route reflectore or have a fully meshed topology.

Hope that helps a bit.

__________________
Webmaster - Ditmas' Java
Ditmas Technologies
NYC CCIE club

Report this post to a moderator

quote:

---

Originally posted by The Ghost

BGP synchronization rule states that a bgp router should not use or advertise to an external neighbor a route learned by IBGP unless that route is local or is learned from the IGP.

---

__________________
Eat Fruit.

Report this post to a moderator

Eventually...

IBGP is an IGP...

__________________
Webmaster - Ditmas' Java
Ditmas Technologies
NYC CCIE club

Last edited by The Ghost on 01-05-02 at 03:52 PM

Report this post to a moderator

quote:

---

Originally posted by The Ghost
IBGP is an IGP...

---

Report this post to a moderator

quote:

---

Originally posted by dmaftei

If by "IGP" you mean "Internal Gateway Protocol" then no, iBGP is not an IGP.

---

__________________
Webmaster - Ditmas' Java
Ditmas Technologies
NYC CCIE club

Report this post to a moderator

First of all there is only one BGP: BGP , which is an EGP. iBGP and eBGP are not sepparate protocols, nor are they variants of BGP. See below.

In theory BGP is very simple. Two BGP routers (BGP speakers, as per RFC1771) establish a TCP connection to each other. Once the connection is established the routers are BGP peers, or BGP neighbors. The peer relationship is of two types, depending on the autonomous system each of the peers belong:

1. If the peers belong to different autonomous systems, the relationship is external (hence eBGP).
   
2. If the peers belong to the same autonomous system, the relationship is internal (hence iBGP).
   

Report this post to a moderator

OK very true.
BGP is one and there aint no varieties.

So an iBGP process which ofcourse is BGP can be categorized in EGP?

Why can't I say iBGP(the process) is IGP.

And why do we say "routers running iBGP"

__________________
Webmaster - Ditmas' Java
Ditmas Technologies
NYC CCIE club

Report this post to a moderator

Oh I also wouldn't mind you explaining BGP confederates... I only have the concept but not the indepth knowledge about it since its not covered in the bscn cisco press book.

__________________
Webmaster - Ditmas' Java
Ditmas Technologies
NYC CCIE club

Report this post to a moderator

quote:

---

Originally posted by The Ghost
So an iBGP process which ofcourse is BGP can be categorized in EGP?
Why can't I say iBGP(the process) is IGP.
And why do we say "routers running iBGP"

---

I don't know about others, but I don't say "routers running iBGP" or "routers running eBGP"; I say "routers running BGP". Also, the rfc doesn't have any reference to "iBGP process" or "eBGP process"; the processes referred to are the "internal update process", the "external update process", the "decision process", and maybe others which I'm missing now. As I said before, I think of iBGP and eBGP as types of connections (or peer relationships).

Now, I guess it's possible to have your own autonomous system and run BGP as your IGP. You would enable BGP on all the routers, you wouldn't establish any external connection, you would configure all the routers to advertise their local (directly connected) networks, etc. Every router would be connected to all the other routers (the full mesh), and all the peer relationships would be iBGP. Suppose you had 10 routers. At this point you would have 45 active TCP connections in your autonomous system only for your IGP. Now suppose you need to add another router. You would have to configure connections to all the other routers (10 of them), and then go to each and every router and configure a connection to the newly added router. The number of TCP connections to support your IGP is now 55... Why would anybody want to do something like this, beats me...

Contrast the above to running a regular IGP: RIP, OSPF, whatever. You have 10 routers, you need to add another one, you go to the new one, enable RIP, you're done. No full mesh, no configuring peers, no nothing.

You probably know that IGPs and EGPs are designed with different goals in mind. In short:

- an IGP is supposed to converge very fast, and to produce the best routing paths in the autonomous system.

- EGP's main goal is to allow control of routing information disemination. Little concern for convergence and optimal routing, which are IGP goals.


The confederations. As you know, all the internal BGP peers in a certain autonomous system have to be fully meshed. This leads to a huge number of TCP connections between the peers. Two solutions to this problem were devised: route reflectors, and confederations. AFAIK route reflectors is the winning solution, while confederations saw few, if any, deployments. The idea is to divide an autonomous system into smaller sub-autonomous systems. Each sub-autonomous system works like an independent AS, while the initial AS is now a confederation. The math goes like this: suppose your AS has 20 routers, for a total of 190 iBGP sessions. You "confederate" your autonomous system: you create four small sub-autonomous systems, each with five routers. Say you fully mesh the confederated autonomous sytems. You'll have 6 sessions between the sub-autonomous systems. Inside each of these you'll have 10 sessions, for a total of 40 sessions in the four sub-autonomous systems. The grand total is now 46 iBGP sessions. Not bad, huh?

Hope this answers your questions. Let me know if you have others.

PS
Oh, I forgot to add that the initial AS (the one that is now confederated) looks like a regular AS to the outside world.

Last edited by dmaftei on 01-06-02 at 08:38 PM

Report this post to a moderator