distinguishing eBGP from show ip BGP
Hi Nanog, For a research I want to distinguish the external AS peering from "show ip BGP". In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use "Next Hop" to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.160 2 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.165 2 0 2828 209 i * 65.106.7.144 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
On 11/Mar/15 20:32, Reza Motamedi wrote:
Hi Nanog,
For a research I want to distinguish the external AS peering from "show ip BGP". In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use "Next Hop" to identify such entries?
I just included a sample report from a public looking glass in XO.
show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.160 2 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.165 2 0 2828 209 i * 65.106.7.144 2 0 2828 209 i
There are two uses of the "i" code in IOS: 1. "i" for Status codes refers to the route being learned via iBGP. 2. "i" for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP). In IOS "show ip bgp" output, the "i" for Status code (iBGP) is to the left of the prefix. On the other hand, the "i" for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH. So you need to be more interested in the "i" to the left of the prefix. In your output above, no such "i" exists; ergo, these are eBGP-learned routes from this router's point of view. Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from. Mark.
Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. On Wed, Mar 11, 2015, 2:51 PM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 11/Mar/15 20:32, Reza Motamedi wrote:
Hi Nanog,
For a research I want to distinguish the external AS peering from "show ip BGP". In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use "Next Hop" to identify such entries?
I just included a sample report from a public looking glass in XO.
show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.160 2 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.165 2 0 2828 209 i * 65.106.7.144 2 0 2828 209 i
There are two uses of the "i" code in IOS:
1. "i" for Status codes refers to the route being learned via iBGP. 2. "i" for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP).
In IOS "show ip bgp" output, the "i" for Status code (iBGP) is to the left of the prefix. On the other hand, the "i" for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH.
So you need to be more interested in the "i" to the left of the prefix. In your output above, no such "i" exists; ergo, these are eBGP-learned routes from this router's point of view.
Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from.
Mark.
On 11/Mar/15 21:22, Reza Motamedi wrote:
Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS?
Status-code "i" just means the entry was learned by "this" router via iBGP. It does not mean the entry belongs to "this AS". A locally-generated route can be thought of as "belonging to this AS", however, a router cannot assert that a locally-generated route "belongs to this AS". It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case.
What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS.
So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router? Mark.
What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:30 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 11/Mar/15 21:22, Reza Motamedi wrote:
Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS?
Status-code "i" just means the entry was learned by "this" router via iBGP. It does not mean the entry belongs to "this AS".
A locally-generated route can be thought of as "belonging to this AS", however, a router cannot assert that a locally-generated route "belongs to this AS". It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c.
Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case.
What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS.
So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router?
Mark.
On 11/Mar/15 21:42, Reza Motamedi wrote:
What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right?
Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop.
Yes - the route was not learned via iBGP; which means it was learned via eBGP. But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations). The next-hop may be local to "this router", but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop. Mark.
Thanks again, Mark. So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane. Is that a fair statement? What if the "Next Hop" is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:50 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 11/Mar/15 21:42, Reza Motamedi wrote:
What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right?
Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop.
Yes - the route was not learned via iBGP; which means it was learned via eBGP.
But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations).
The next-hop may be local to "this router", but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop.
Mark.
On 11/Mar/15 22:27, Reza Motamedi wrote:
Thanks again, Mark.
So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane.
Not reliably as far as I can tell, no. Someone else can chime in here if they have another perspective. One could rely on traceroutes, but that is crude and sometimes unavailable if you're looking to gather any meaningful data (even though it might be the closest piece of information you'll get without engaging with the network operator).
What if the "Next Hop" is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help?
Control-plane-wise, that could be eBGP Multi-Hop. Forwarding-plane-wise, that is likely a tunnel operation. Technically, one can build such a topology. I'd hazard that at least someone is doing this out there somewhere. However, it's not typical by any means. Mark.
On Wed, Mar 11, 2015 at 02:32:33PM -0400, Reza Motamedi wrote:
Hi Nanog,
For a research I want to distinguish the external AS peering from "show ip BGP". In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use "Next Hop" to identify such entries?
I would take a different route to diagnose the relationship between networks. I would look at the route-views or RIS datasets and parse the MRT data taking a close look at the communties that are tagged on the routes. NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one: http://www.onesc.net/communities/ You will likely get far more accurate data. You can also attempt to validate these relationships leveraging the RIPE ATLAS project. You can then perform tests and validate them via traceroutes performed by this global network of probes. You can also look at the NLNOG-RING project as another location to perform these tests from. aside: if you want RIPE Atlas credits, let me know, my cup overflows with credits.
I just included a sample report from a public looking glass in XO.
show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.160 2 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.165 2 0 2828 209 i * 65.106.7.144 2 0 2828 209 i
these next-hops can tell you information about the internal of a network, how they are configured, eg: with route-reflectors, next-hop-self or other policies internally. The i at the end is an "origin" code, which is used as a tie-breaker for the BGP decision process. This can be influenced by people to set it to internal, external or unknown to cause shifts in traffic. internal tagged routes will have a higher preference when reaching a network, so there are some networks that may reset the origin to influence the policy of a 3rd party network. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On 11/Mar/15 20:51, Jared Mauch wrote:
NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one:
http://www.onesc.net/communities/
You will likely get far more accurate data.
The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed. Mark.
On Mar 11, 2015, at 2:59 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 11/Mar/15 20:51, Jared Mauch wrote:
NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one:
http://www.onesc.net/communities/
You will likely get far more accurate data.
The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed.
True, they also can get marked, remarked, or dropped at various network edges. This is why I was suggesting taking the data directly from the MRT files at route-views. I’ve been using this for the routing leak detector just processing the updates over the years and it’s way easier to process a smaller update file than diff the entire RIB dump. (at least for that use-case). <rant=start> Many people who do BGP don’t do a good job with their policy which is how you end up with these full table leaks and seemingly random routes appear that hairpin through networks. eg: 59.188.253.0/24 2497 701 6453 45474 174 17444 It’s unlikely that 6453 or 701 should really be using 45474 to reach 174 or their customer 17444. This has a lot to do with IOS devices which by default send all routes to all configured peers. Cisco does a particularly poor job of educating it’s CCIE and other graduates of this fact. IOS-XR can be made to do the same thing, but requires explicitly enabling this problematic behavior. Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config. <rant=end> - Jared
On 11/Mar/15 21:18, Jared Mauch wrote:
Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config.
One has the same issue in IOS XR, where BGP communities are only signaled by default for iBGP neighbors. One needs to enable signaling of communities to eBGP neighbors. Junos does the right thing :-). Mark.
participants (4)
-
Jared Mauch -
Jared Mauch
-
Mark Tinka -
Reza Motamedi