|
Home > Archive > CCNP > May 2002 > IBGP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| 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. | |
| The Ghost 2001-12-25, 3:03 am |
| 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. | |
| bencher 2002-01-04, 3:50 pm |
| 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.
So, if there is no IGP configured, it will advertise BGP but not IBGP? | |
| The Ghost 2002-01-05, 10:48 am |
| Eventually...
IBGP is an IGP... | |
| dmaftei 2002-01-05, 11:00 pm |
| quote:
Originally posted by The Ghost
IBGP is an IGP...
If by "IGP" you mean "Internal Gateway Protocol" then no, iBGP is not an IGP. | |
| The Ghost 2002-01-06, 1:54 am |
| quote:
Originally posted by dmaftei
If by "IGP" you mean "Internal Gateway Protocol" then no, iBGP is not an IGP.
Hmmm so IBGP is an EGP meaning that it interconnects and communicates in an inter-AS environment?
Can you elaborate then... | |
| dmaftei 2002-01-06, 3:15 am |
| 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:
- If the peers belong to different autonomous systems, the relationship is external (hence eBGP).
- If the peers belong to the same autonomous system, the relationship is internal (hence iBGP).
Functionally, the main difference between eBGP and iBGP is that a BGP speaker will not propagate to an internal peer routes learned from another internal peer. (With route reflectors or confederations things are a bit different, but that's a level of detail we should skip for now.) This is because internal peers are required to be fully meshed; with the full mesh, a BGP speaker advertises directly its routes (routes learned from an external peer, that is) to all the other internal peers. In this conditions, routes passed around between internal peers would most likely lead to loops.
Why the full mesh? Because you want all the BGP speakers inside an autonomous system (the iBGP peers) to have the same view of what's going on outside that autonomous system. And so the iBGP peers will pass among them only BGP routes, and will not pass any kind of IGP (RIP, IGRP, OSPF, whatever) routing information.
Hmm, I don't know how much better that that I can do. Let me know if you have more specific questions. | |
| The Ghost 2002-01-06, 1:14 pm |
| 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" | |
| The Ghost 2002-01-06, 1:22 pm |
| 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. | |
| dmaftei 2002-01-06, 3:27 pm |
| 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. | |
| Forest Phatty 2002-01-07, 1:24 am |
| great posts guys!!
very informative | |
|
|
| The Ghost 2002-01-07, 4:06 am |
| Cool info dmaftei...
and oh by the way everyone says "routers running iBGP" especially the cisco book... but anyway you are right you don't have to type again... and thanks for the info! | |
| CyberMonkey 2002-05-21, 6:01 pm |
| Excellent source of information. Helped eliviate the confusion. Thanx. | |
| CyberMonkey 2002-05-21, 6:36 pm |
| Excellent source of information. Helped eliviate the confusion. Thanx. | |
| LANlord 2002-05-23, 11:42 am |
| BGP is too complex to cover all of the aspects here...so I'll just briefly give my take on it.
As far as running BGP internally: Unless you are an ISP, you should not do this on your internal network - makes no sense. One of the main functions of BGP is the load sharing between ISP's. Notice I did NOT say load balancing (BGP does not load balance). If you are going to use BGP to load share between ISP's you must be very careful. It is very easy to leave out a couple of things in the configuration and advertise your AS and your BGP routing tables to your ISP's. What's the problem with that? You then become a transitive AS between your two (or more) ISP's. So they are using your backbone to forward traffic to their customers. Not good for you.
The Full mesh of iBGP speakers: Do not confuse this with having to be directly connected. If you're also running an IGP (EIGRP,RIP) your iBGP peers do not have to be directly conected to be fully meshed. However, eBGP peers must be directly connected.
Know who your ISP's are: You could run into a situation where one of your ISP's is a customer of the other. i.e. You have a tier 1 provider and a tier 2 provider. Your tier 2 is actually a customer of your tier 1. You may see some funky routing going on that may confuse you (and your ISP). Reference reverse path filtering if you want to know more about what can happen there.
Anyway, I could keep going...but I won't...unless there is a specific question.
Happy Networking | |
| tatosala 2002-05-23, 4:45 pm |
| Guauuuuuu¡¡
This post was really helpfull .Thanks to all of you¡¡¡¡
 | |
| SureshHomepage 2002-05-26, 5:23 pm |
| Thank you very much you guys dmaftei and LANlord. Excellant explanation on BGP in simple terms! Good luck! |
|
|
|
|