nanog mailing list archives

Re: distinguishing eBGP from show ip BGP


From: Jared Mauch <jared () puck Nether net>
Date: Wed, 11 Mar 2015 14:51:32 -0400

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.


Current thread: