Inferring the location points of traffic exchange between two networks

Wed Jan 13 18:15:23 UTC 2016

Thanks Joel. I like examples. :)

So say I issue the command on a router that is not the gateway. Would I get
the following?

       Network             Next Hop         Metric  LocPref Weight  Path
 * >   8.8.8.0/24          <IP in AS_a>     96      56      0       <AS_a>
15169 i

With respect to "show bgp summary", if I know the location of the router
and the router shows the BGP neighbor in the output, can I just rely on
this info and say the point of exchange is where the router is located? For
example the following show output from a router in city say "X"

  BGP4 Summary
  Router ID: 192.65.184.1   Local AS Number: 513
  Confederation Identifier: not configured
  Confederation Peers:
  Cluster ID: 513
  Maximum Number of IP ECMP Paths Supported for Load Sharing: 4
  Number of Neighbors Configured: 18, UP: 18
  Number of Routes Installed: 997637, Uses 85796782 bytes
  Number of Routes Advertising to All Neighbors: 2196009 (569816
entries), Uses 27351168 bytes
  Number of Attribute Entries Installed: 305962, Uses 27536580 bytes
  Neighbor Address  AS#         State   Time          Rt:Accepted
Filtered Sent     ToSend
  62.40.124.157     20965       ESTAB   76d23h58m     140497      0
    28       0
  83.97.88.33       21320       ESTAB   49d 5h11m     0           0
    28       0
  192.65.184.2      513         ESTAB   365d12h24m    243346      0
    493626   0
  192.65.184.3      513         ESTAB   405d12h31m    7010        0
    562695   0
  192.65.184.4      513         ESTAB   317d 9h 1m    0           0
    569704   0
  192.65.184.24     513         ESTAB   54d16h26m     0           0
    569704   0

  tells me that 513 is peering with 20965 that city, right?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Jan 13, 2016 at 10:02 AM, joel jaeggli <joelja at bogus.com> wrote:

> On 1/13/16 9:36 AM, Reza Motamedi wrote:
> > Hi NANOG,
> >
> > I am researcher at the University of Oregon and my question is rather
> > primitive. My research background is in networked systems and Internet
> > measurement so I know how things work in theory.
> >
> > My question is about BGP and what can be inferred from the output of
> > different "show" commands, regarding the point of traffic exchange of two
> > networks with different ASNs. I tried going through the some samples on
> > Juniper and Cisco documentations but I did not get my answer.
> >
> > Consider the following scenario; Say the point of traffic exchange
> between
> > AS_a and AS_b is in San Francisco and we run "show bgp summary"
>
> show bgp summary just tells you about your bgp neighbors.
>
> > and "show
> > ip bgp <prefix>"on a BGP router of AS_a in LA. Do we see the peering
> > between AS_a and AS_b in San Francisco using any of the two commands.
>
> You see AS path, and the nexthop the route was learned from (which is
> probably (nexthop self) the router on which the prefix is learned) in
> san francisco. that route is probably resolved by your igp.
>
> so in an extremely simple example
>
>        Network             Next Hop         Metric  LocPref Weight Path
>  * >   8.8.8.0/24          72.14.202.50     96      56      0       15169
> i
>
> the nexthop happens to be an attached google peer
>
> the as path is
> 15169 i
>
> > If
> > yes is there a way to infer that in fact the traffic is not exchanged
> > locally in LA? I think there should be a flag to differentiate records
> > showing iBGP vs eBGP.
>
> If the router in LA sees the path as being through a router in san
> francisco that is the direction it will forward it in.
>
> > On the same note, if we issue the commands on a router other than the
> > border router in San Fran, is there any difference in the output of show
> > commands?
> >
> > Now how are things different if we actually run the commands on that
> > gateway router in SF?
> >
> > Best Regards
> > Reza Motamedi (R.M)
> > Graduate Research Fellow
> > Oregon Network Research Group
> > Computer and Information Science
> > University of Oregon
> >
>
>
>