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

[Dinesh Dutt <[e-mail]>]

Hi Robert,

On Fri, May 15, 2015 at 11:27 PM, Robert Raszuk <[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]> 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
>>>>>
>>>>
>>>>
>>