I understand that only the best path is advertised to eBGP neighbors, but is this true of iBGP? If I peer with two providers, I was under the impression that anyone else peering with both of my providers would have two paths to me. After inspecting a number of looking glasses, it appears this isn't so.
BGP always only advertises the best path onward to its peers. This is true for eBGP, iBGP, route reflection (which is merely a special case of iBGP), and any other way you might use BGP.
But, yes, you are correct, if you are sending advertisements to providers A and B, and I have connections and BGP sessions also with providers A and B, then I should see both paths in my BGP tables. I may not see multiple routes created in my routing tables...that's a question of the configuration of my devices and whether I allow multiple routes of equal AS Path lengths to be inserted into the routing table...typically BGP will only install a single route. The BGP tables, though, should show advertisements from both providers.
Actually...even if I'm peering with providers B and C, or even C and D, I should still see multiple paths in my BGP tables as long as you are reachable through B, C, and D. All other things being equal, my devices should pick B because that should be the shortest AS PATH, but I would still see the paths with the longer AS PATHs from C and D. Now, perhaps C and D have both decided that the path through A is better than the path through B, then the paths that I would see would have AS PATHs of "A C" and "A D", so it would appear as if you weren't connected to B at all, but if the path through A went away, then the path through B would get propagated onward through C and D.
If you can give some specifics...maybe even your blocks that you're advertising if you're willing to share that....others can take a look at what we're seeing and perhaps give some more specific guidance.
One aspect not yet covered by these answers is BGP "add-path" which lets a BGP peer send not only their best route, but some or all of their alternates as well.
This is most useful (as well as likely to work) on iBGP, and gives better ECMP.
For EBGP if you have multiple sessions to the same peer on a single router you should be using BGP "multipath" to allow ECMP. Depending on how and where route reflection is done in an SP network this can result in using all sessions quite evenly.
Here's a presentation from Dave Ward (then at Juniper, now at Cisco) about add-path:
Typically, BGP peers can only send a single path to eachother, with any updates for that path replacing the existing one.
However, there is an extension to BGP, typically known as
additional-paths which puts an identifier on each route sent to a peer and thus enables BGP peers to exchange multiple routes to a path, thereby giving you not only a greater scope for traffic engineering, but also a reduced convergence time in the event of path withdrawal since the non-bestpath prefix(es) can be installed in the FIB as a backup route(s) that will be used the moment the bestpath gets withdrawn - this is particularly significant if you're running full internet tables as the BGP scanner on a Cisco router will run every 30 seconds at best and walking over 300,000 routes takes its toll.
Note that BGP additional-paths has nothing to do with ECMP since obviously, we're talking about receiving multiple prefixes with the same next-hop - with the only exception being cases where you're running iBGP and not using
next-hop-self (or doing dirty things with eBGP where the nexthop is preserved)
Since it is an extension, both routers must support it and negotiate the feature at connection time (or alternatively, have negotiated dynamic capability). It is usable with both eBGP and iBGP.
Trying to look for your own routes in looking glasses does not always work the way you expect, particularly if you buy from someone who purchases a lot of transit. For example, Internap buys transit from many other large ISPs. If you buy from Internap and then someone else, there is a good chance that your route on the other provider would be hidden by virtue of not being best. Most ISPs prefer their own customer routes. Seeing or not seeing your own routes in a looking glass has very little to do with if your route is propagating correctly or not.
There's so much filtering between you and the LG (looking glass) that can get your prefix removed from on path or another. What's the length of your advertised prefix? Do you have PI or PA space? Since the bestpath is advertised to peers, you two paths can be competing with one another upstream and only one is making it to the LG. If you shutdown one of your paths, does it then show up in the LG after convergence? That will tell you you're losing one to bestpath. Try LG's with your providers to confirm your prefix is there first, then try to work your way up to the next SP.
For your iBGP bestpath question, default is to only advertise one.
The answer is not a simple "yes" or "no", but I think essentially your observation is indeed true that "this isn't so."
For more detail, see here.
For the sake of curation, SE prefers against answers that are purely links to other pages, however, so I'll reproduce some of that here in case the source someday disappears or changes.
How the Best Path Algorithm Works
BGP assigns the first valid path as the current best path. BGP then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths. This list provides the rules that are used to determine the best path:
1) Prefer the path with the highest WEIGHT.
Note: WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.
2) Prefer the path with the highest LOCAL_PREF.
Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference command, or to have a value of 100 by default.
3) Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.
Local paths that are sourced by the network or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address command.
4) Prefer the path with the shortest AS_PATH.
Note: Be aware of these items:
This step is skipped if you have configured the bgp bestpath as-path ignore command.
An AS_SET counts as 1, no matter how many ASs are in the set.
The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.
5) Prefer the path with the lowest origin type.
Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.
6) Prefer the path with the lowest multi-exit discriminator (MED).
Note: Be aware of these items:
This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored.
In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
If bgp always-compare-med is enabled, MEDs are compared for all paths.
You must disable this option over the entire AS. Otherwise, routing loops can occur.
If bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE.
These paths originated within the local confederation.
THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is changed before insertion into the BGP table. The MED changes to to 4,294,967,294.
Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst .
If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a MED of 4,294,967,294.
The bgp deterministic-med command can also influence this step.
Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a demonstration.
7) Prefer eBGP over iBGP paths.
If bestpath is selected, go to Step 9 (multipath).
Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.
8) Prefer the path with the lowest IGP metric to the BGP next hop.
Continue, even if bestpath is already selected.
9) Determine if multiple paths require installation in the routing table for BGP Multipath.
Continue, if bestpath is not yet selected.
10) When both paths are external, prefer the path that was received first (the oldest one).
This step minimizes route-flap because a newer path does not displace an older one, even if the newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).
Skip this step if any of these items is true:
You have enabled the bgp best path compare-routerid command.
Note: Cisco IOS Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E introduced this command.
The router ID is the same for multiple paths because the routes were received from the same router.
There is no current best path.
The current best path can be lost when, for example, the neighbor that offers the path goes down.
11) Prefer the route that comes from the BGP router with the lowest router ID.
The router ID is the highest IP address on the router, with preference given to loopback addresses. Also, you can use the bgp router-id command to manually set the router ID.
Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.
12) If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.
This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.
13) Prefer the path that comes from the lowest neighbor address.
This address is the IP address that is used in the BGP neighbor configuration. The address corresponds to the remote peer that is used in the TCP connection with the local router.
That said, however, I could be wrong. I'm rather a novice in this field.