Re: [Idr] draft-walton-bgp-hostname-capability-00

["Rajiv Asati (rajiva)" <[e-mail]>]

One minor point --

Q2 - how about lookup on bgp rtr id instead LL address to get the name ?

I don't lookup LL address. Router ID is typically the loopback IP address in DC,

The above is true for dual-stack or single-stack IPv4 networks (loop back IPv4 address usually is router ID), but not true for single-stack IPv6 networks in which the router ID (4 bytes) would barely be related to the loop back IPv6 address (128 bytes).

Cheers,
Rajiv

On May 16, 2015, at 3:01 AM, Dinesh Dutt <[e-mail]<mailto:[e-mail]>> wrote:

Hi Robert,

On Fri, May 15, 2015 at 11:27 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Dinesh,

Q1 - how do you ping physical interface not a loopback

In the DC, common practice I've seen is pinging node, not physical interface. The physical interface addresses aren't even advertised to be able to be reachable more than one hop away.


Q2 - how about lookup on bgp rtr id instead LL address to get the name ?

I don't lookup LL address. Router ID is typically the loopback IP address in DC,

Dinesh

Cheers,
R.


On Saturday, May 16, 2015, Dinesh Dutt <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

On Fri, May 15, 2015 at 11:01 PM, Robert Raszuk <[e-mail]> wrote:
Hi Daniel & Dinesh,

I very much like the intention, but have a concern how it would simplify troubleshooting in practice ...

Imagine we exchange the names in new capability when session comes up so we list it in summary output instead of link local address. But when you try to trace or ping that name (from pc or router) your local or global DNS will return not the LL address but most likely loopback so the results will be rather of questionable value.

I'm confused. Why would we send a hostname in this capability that is different from the one assigned to loopback ? Within the DC at least, people don't advertise link addresses at all, only the loopback.  So, the hostname exchanged in the capability would be the same as the one returned by traceroute/ping.

Dinesh


Would you not see this as a problem ? I hope you did not intended to just cover the cosmetic nature of few show commands which I must agree with others is rather a legacy way to operate the network these days anyway ;)).



Cheers,
R.


On Saturday, May 16, 2015, Daniel Walton <[e-mail]> wrote:
Many of our customers use a Clos architecture and bgp peer to the IPv6 LL address of every directly connected router.  To avoid configuring neighbor statements with LL addresses we support a "neighbor swpX interface" command ("swpX" is the default notation for an interface name in cumulus linux).  We then peer to the LL address on the other end of the swpX link (we only support this for point-to-point links).

When you run commands like "show ip bgp summary" you see a list of interface names instead of IP addresses. Typically if you are loopback peering you either become familiar with "10.0.0.1 is Chicago" because you see 10.0.0.1 in the 'show ip bgp summ' output of several different routers or you could use DNS to do a lookup on 10.0.0.1 and put the hostname in the output.  When every box is peering to LL addresses though ("swpX" for short for us) you can't easily tell who that peer is and you can't use DNS because they LL addresses

Before

leaf-11# show ip bgp summ
BGP router identifier 6.0.0.5, local AS number 65101
BGP table version 25
RIB entries 33, using 3960 bytes of memory
Peers 6, using 100 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
swp1            4 65000     196     198        0    0    0 00:02:51        9
swp2            4 65000     195     200        0    0    0 00:02:51        9
swp3            4 65000     197     200        0    0    0 00:02:51        9
swp4            4 65000     198     200        0    0    0 00:02:51        9
swp5            4 65201     207     200        0    0    0 00:02:51        2
swp6            4 65202     210     201        0    0    0 00:02:52        2

Total number of neighbors 6
leaf-11#

spine-3# show ip bgp summ
BGP router identifier 6.0.0.15, local AS number 65000
BGP table version 19
RIB entries 33, using 3960 bytes of memory
Peers 8, using 134 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
swp5            4 65101     675     675        0    0    0 00:10:49        5
swp6            4 65101     678     676        0    0    0 00:10:50        5
swp7            4 65101     667     668        0    0    0 00:10:48        5
swp8            4 65101     676     676        0    0    0 00:10:49        5
swp9            4 65102     701     692        0    0    0 00:11:04        5
swp10           4 65102     701     692        0    0    0 00:11:04        5
swp11           4 65102     701     691        0    0    0 00:11:04        5
swp12           4 65102     701     692        0    0    0 00:11:04        5

Total number of neighbors 8
spine-3#
spine-3#


After

leaf-11# show ip bgp summ
BGP router identifier 6.0.0.5, local AS number 65101
BGP table version 25
RIB entries 33, using 3960 bytes of memory
Peers 6, using 100 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
spine-1(swp1)   4 65000     211     213        0    0    0 00:03:07        9
spine-2(swp2)   4 65000     210     215        0    0    0 00:03:07        9
spine-3(swp3)   4 65000     212     215        0    0    0 00:03:07        9
spine-4(swp4)   4 65000     213     215        0    0    0 00:03:07        9
tor-11(swp5)    4 65201     222     215        0    0    0 00:03:07        2
tor-12(swp6)    4 65202     225     216        0    0    0 00:03:08        2

Total number of neighbors 6
leaf-11#

spine-3# show ip bgp summ
BGP router identifier 6.0.0.15, local AS number 65000
BGP table version 19
RIB entries 33, using 3960 bytes of memory
Peers 8, using 134 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
leaf-11(swp5)   4 65101    1119    1119        0    0    0 00:18:13        5
leaf-12(swp6)   4 65101    1122    1120        0    0    0 00:18:14        5
leaf-13(swp7)   4 65101    1110    1111        0    0    0 00:18:12        5
leaf-14(swp8)   4 65101    1119    1119        0    0    0 00:18:13        5
leaf-21(swp9)   4 65102    1144    1135        0    0    0 00:18:28        5
leaf-22(swp10)  4 65102    1144    1135        0    0    0 00:18:28        5
leaf-23(swp11)  4 65102    1144    1134        0    0    0 00:18:28        5
leaf-24(swp12)  4 65102    1144    1135        0    0    0 00:18:28        5

Total number of neighbors 8
spine-3#

It makes troubleshooting much easier.

Daniel


On Fri, May 15, 2015 at 9:58 PM, <[e-mail]> wrote:
Agree.. adding code for no real operational benefit

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Randy Bush
Sent: Friday, May 15, 2015 10:52 PM
To: Daniel Walton
Cc: idr wg; Dinesh Dutt
Subject: Re: [Idr] draft-walton-bgp-hostname-capability-00

one more unneeded place for things to go wrong

randy

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr



_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr