Re: BGP manage advertisement

[Mattia Milani]

>
> Yes, there are some minor deviations from RFCs like in this case.
> It is true that we should explicitly document them.
>

It will be so appreciated from users and future users.

Thanks,
Mattia

>

RE: Constant delete / add route after upgrade to 1.6.3

[Xavier Trilla]

Hi Ondrej,

Thanks for your reply, know I see why it's done this way. But Im wondering, 
could that lead to packed loss or the remove/add is fast enough? I mean, we 
just push to the kernel the best paths, so in this scenario a destination could 
be without a destination for a brief period of time, or the update is fast 
enough to not even affect a high traffic connection? 

The alternative I'm seeing is publishing all routes to kernel with weights, but 
that's something I would like to avoid (I don't want to publish several million 
routes to the kernel :/ )

Thanks!

Saludos Cordiales,
Xavier Trilla P.
Clouding.io

¿Un Servidor Cloud con SSDs, redundado
y disponible en menos de 30 segundos?

¡Pruébalo ahora en Clouding.io!

-Mensaje original-
De: Ondrej Zajicek  
Enviado el: miércoles, 9 de mayo de 2018 15:48
Para: Xavier Trilla 
CC: Maria Jan Matějka ; bird-users@network.cz
Asunto: Re: Constant delete / add route after upgrade to 1.6.3

On Tue, May 08, 2018 at 08:29:06PM +, Xavier Trilla wrote:
> Hi Maria,
> 
> For what I'm seeing, looks like every time birds gets a route update via BGP 
> the route is replaced, I enabled debug in kernel protocol and I'm seeing this:
> 
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 
> 80.84.147.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 80.84.147.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 80.84.147.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 
> 78.40.178.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 78.40.178.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 78.40.178.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 
> 64.17.246.0/23 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 64.17.246.0/23 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 64.17.246.0/23 via 
> 172.17.0.1 on vlan10
> 
> 
> But does it make sense? I mean, deleting and reading the route to replace it 
> when a route update is received doesn't seem to make much sense considering 
> the gateway does not change.

Hi

It is true that we send a route to the kernel if there is any change in the 
route, even if the change is irrelevant for the kernel itself. They may be 
export filters in kernel that are dependent on any route attributes so it is 
hard to predict whether the change is relevant or not.

> Also, I guess removing and adding the route again could lead to some packet 
> loss.

We could use replace netlink operation instead of remove/add, but that has some 
other problems (like insufficient protection against overwriting alien routes).

> Maybe bird needs to keep some information in the route in order to keep sync 
> and that's why it needs to replace it? Or there is anything I'm missing...

We could keep that information but that essentialy means double memory 
footprint for simple setups.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted 
e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to 
blame it on a computer is even more so."

Re: BGP manage advertisement

[Ondrej Zajicek]

On Wed, May 09, 2018 at 04:35:11PM +0200, Mattia Milani wrote:
> > No. Perhaps sometimes in the future, but no definite plan.
> >
> 
> yeah but on your site,
> http://bird.network.cz/?get_doc=20=bird-6.html#ss6.3 that is the user's
> guide 2.0, there is this written:
> 
> Supported standards
> 
> 
>- RFC 4271  - Border Gateway
>Protocol 4 (BGP)
> 
> In the RFC 4271 is mentioned several times the MRAI or
> MinRouteAdvertisementIntervalTimer if you prefer, so why it isn't
> implemented?

Yes, there are some minor deviations from RFCs like in this case.
It is true that we should explicitly document them.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BGP manage advertisement

[Mattia Milani]

>
> This is an open source project, it depends on the efforts and
> contributions the BIRD community.
>

Yeah i know it but for @admin, for future users it could be helpful to
write on the site what of the standards is supported and what is not support

Thanks,
Mattia

>

Re: BGP manage advertisement

[Job Snijders]

On Wed, May 09, 2018 at 04:35:11PM +0200, Mattia Milani wrote:
> > No. Perhaps sometimes in the future, but no definite plan.
> 
> yeah but on your site, 
> http://bird.network.cz/?get_doc=20=bird-6.html#ss6.3
> that is the user's guide 2.0, there is this written:
> 
> Supported standards
> 
>- RFC 4271 - Border Gateway Protocol 4 (BGP)
> 
> In the RFC 4271 is mentioned several times the MRAI or
> MinRouteAdvertisementIntervalTimer if you prefer, so why it isn't
> implemented?

Actually in the IETF there has been an effort to deprecate MRAI, you can
review this Internet-Draft https://tools.ietf.org/html/draft-ietf-idr-mrai-dep

This follow-up discussion may interest you as well:
https://mailarchive.ietf.org/arch/msg/idr/uNhHCoxLWLSiKH69LT4xEr6G2Jg

This is an open source project, it depends on the efforts and
contributions the BIRD community.

Kind regards,

Job

Re: [PATCH 3/3] babel: Add option to randomise router ID

[Ondrej Zajicek]

On Wed, May 09, 2018 at 04:29:54PM +0200, Toke Høiland-Jørgensen wrote:
> Ondrej Zajicek  writes:
> 
> > On Thu, May 03, 2018 at 03:14:58PM +0200, Toke Høiland-Jørgensen wrote:
> >> Ondrej Zajicek  writes:
> >> > Ignoring global setting is OK, i just wonder whether some global
> >> > EUI-64-based unique ID should not be provided directly by the nest
> >> 
> >> That might be convenient, yeah. There's the issue of picking the right
> >> interface, though; some kind of logic that says "first interface with a
> >> configured protocol"? Or should it be a per-protocol type thing?
> >
> > It would make sense to use an analogous mechanism to 32bit router id,
> > just use IPv6-LL address instead of IPv4 address. See 'router id' /
> > 'router id from' options and function if_choose_router_id().
> 
> Right, that makes sense. A 'v6-ll/64bit router id [from]' config option?

Something like that. I would prefer '64bit', but unfortunately keywords
in BIRD have to use {alpha}{alnum}* format.

It should also check if the address is really EUI-64 and skip configured
ones like fe80::1.

> The nest could provide proto_get_router_id64() which would return an
> LL-based ID if configured/available and the 32-bit version if it isn't?

Yes. Or just 64-bit ID could be set based on 32-bit value as a last resort.

> > One issue is that if BIRD is started during boot then IPv6-LL
> > addresses may not be available immediately after start due to waiting
> > for duplicate address detection.
> 
> Hmm, true. Should we deal with this (by deferring startup of protocols
> that need them, I guess?), or leave it up to administrators to fix their
> init scripts? With the fallback option mentioned above it would not be
> strictly necessary, we could just fall back to 32-bit... :)

Well, ignoring it is ugly and leads to nondeterministic behavior. Deferring
protocol startup could be hacked, but it is still problematic (e.g., you
have to rerun router id election when DUD finished for initial addresses).

Another option would be be to process even tentative addresses but mark
them in such way, so protocols could ignore them while router-id selection
could still use them.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BGP manage advertisement

[Mattia Milani]

> Or perhaps not wait for MRAI timers to collapse, and just immediately
> process & propagate any changes as they come in? If you want to reduce
> convergence timing, is it helpful to hold back communicating state
> changes to your neighbors?
>

you didn't think that this is a waste of packets? if i waite some time in
some topology i can send one packets instead of hundred

My point is that there is contention around the topic of MRAI and there
> are widely deployed 'misimplementations'. Geoff Huston's comments on
> this topic are quite insightful.
>
>
i know that around the topic there is contention, for that i want to study
it with a deamon and simulations.

kind regards,
Mattia

Re: BGP manage advertisement

[Mattia Milani]

> No. Perhaps sometimes in the future, but no definite plan.
>

yeah but on your site,
http://bird.network.cz/?get_doc=20=bird-6.html#ss6.3 that is the user's
guide 2.0, there is this written:

Supported standards


   - RFC 4271  - Border Gateway
   Protocol 4 (BGP)

In the RFC 4271 is mentioned several times the MRAI or
MinRouteAdvertisementIntervalTimer if you prefer, so why it isn't
implemented?

Re: [PATCH 2/3] babel: Short-circuit route selection for routes we originate ourselves

[Toke Høiland-Jørgensen]

Ondrej Zajicek  writes:

> On Tue, May 01, 2018 at 01:22:47PM +0200, Toke Høiland-Jørgensen wrote:
>> This behaviour relies on the fact that the route was initially learned
>> from the kernel, so from the nest's perspective it has very low
>> preference. I'm not sure that is actually desirable in Babel's case? Why
>> are routes learned from the kernel assigned the lowest preference?
>
> I think that it is some legacy issue. Perhaps the original idea was
> that routes learned from kernel were some initial routes used during
> boot, which were later replaced by routes from dynamic routing. But as
> BIRD (on Linux) currently do not allow to overwrite alien routes
> anyway, it would make sense that these routes would have higher
> priority, like static routes.

Yeah, I agree. The current behaviour was certainly surprising to me ;)

-Toke

Re: [PATCH 3/3] babel: Add option to randomise router ID

[Toke Høiland-Jørgensen]

Ondrej Zajicek  writes:

> On Thu, May 03, 2018 at 03:14:58PM +0200, Toke Høiland-Jørgensen wrote:
>> Ondrej Zajicek  writes:
>> > Ignoring global setting is OK, i just wonder whether some global
>> > EUI-64-based unique ID should not be provided directly by the nest
>> 
>> That might be convenient, yeah. There's the issue of picking the right
>> interface, though; some kind of logic that says "first interface with a
>> configured protocol"? Or should it be a per-protocol type thing?
>
> It would make sense to use an analogous mechanism to 32bit router id,
> just use IPv6-LL address instead of IPv4 address. See 'router id' /
> 'router id from' options and function if_choose_router_id().

Right, that makes sense. A 'v6-ll/64bit router id [from]' config option?
The nest could provide proto_get_router_id64() which would return an
LL-based ID if configured/available and the 32-bit version if it isn't?

> One issue is that if BIRD is started during boot then IPv6-LL
> addresses may not be available immediately after start due to waiting
> for duplicate address detection.

Hmm, true. Should we deal with this (by deferring startup of protocols
that need them, I guess?), or leave it up to administrators to fix their
init scripts? With the fallback option mentioned above it would not be
strictly necessary, we could just fall back to 32-bit... :)

-Toke

Re: BGP manage advertisement

[Job Snijders]

On Wed, May 09, 2018 at 04:12:12PM +0200, Mattia Milani wrote:
> > Why do you need (configurable) MRAI timers?
> 
> Because i'm studing a way to programmaticaly decide the MRAI timer in way
> to reduce the convergence of BGP after a node fail, so i need a MRAI
> configurable or at least implemented in the code to modify it like I think
> Maybe  thees could help you :
> https://www.noction.com/blog/bgp-path-hunting

Or perhaps not wait for MRAI timers to collapse, and just immediately
process & propagate any changes as they come in? If you want to reduce
convergence timing, is it helpful to hold back communicating state
changes to your neighbors?

If you think some form of MRAI timing is useful you can of course
attempt to implement this yourself and submit a patch.

> Look for the word "MRAI" in these RIPE Routing-WG minutes
> > https://www.ripe.net/participate/ripe/wg/routing/minutes/routing-working-group-minutes-ripe-75
>
> i didn't catch why you linked me that, i read where appear the word
> "MRAI", could you please explain what do you want to notice me?

My point is that there is contention around the topic of MRAI and there
are widely deployed 'misimplementations'. Geoff Huston's comments on
this topic are quite insightful.

Kind regards,

Job

Re: BGP manage advertisement

[Ondrej Zajicek]

On Wed, May 09, 2018 at 01:24:13PM +, Mattia Milani wrote:
> And you have a plane to inculude it in the next release?

No. Perhaps sometimes in the future, but no definite plan.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: [PATCH 3/3] babel: Add option to randomise router ID

[Ondrej Zajicek]

On Thu, May 03, 2018 at 03:14:58PM +0200, Toke Høiland-Jørgensen wrote:
> Ondrej Zajicek  writes:
> > Ignoring global setting is OK, i just wonder whether some global
> > EUI-64-based unique ID should not be provided directly by the nest
> 
> That might be convenient, yeah. There's the issue of picking the right
> interface, though; some kind of logic that says "first interface with a
> configured protocol"? Or should it be a per-protocol type thing?

It would make sense to use an analogous mechanism to 32bit router id,
just use IPv6-LL address instead of IPv4 address. See 'router id' / 
'router id from' options and function if_choose_router_id().

One issue is that if BIRD is started during boot then IPv6-LL addresses
may not be available immediately after start due to waiting for duplicate
address detection.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BGP manage advertisement

[Mattia Milani]

> Why do you need (configurable) MRAI timers?
>
>
Because i'm studing a way to programmaticaly decide the MRAI timer in way
to reduce the convergence of BGP after a node fail, so i need a MRAI
configurable or at least implemented in the code to modify it like I think
Maybe  thees could help you :
https://www.noction.com/blog/bgp-path-hunting


Look for the word "MRAI" in these RIPE Routing-WG minutes
> https://www.ripe.net/participate/ripe/wg/routing/
> minutes/routing-working-group-minutes-ripe-75
>
>
i didn't catch why you linked me that, i read where appear the word "MRAI",
could you please explain what do you want to notice me?

thanks,
Mattia


2018-05-09 15:41 GMT+02:00 Job Snijders :

> Dear Mattia,
>
> On Wed, May 9, 2018 at 3:24 PM, Mattia Milani
>  wrote:
> > And you have a plane to inculude it in the next release?
>
> Why do you need (configurable) MRAI timers?
>
> Look for the word "MRAI" in these RIPE Routing-WG minutes
> https://www.ripe.net/participate/ripe/wg/routing/
> minutes/routing-working-group-minutes-ripe-75
>
> Kind regards,
>
> Job
>

Re: Constant delete / add route after upgrade to 1.6.3

[Ondrej Zajicek]

On Tue, May 08, 2018 at 08:29:06PM +, Xavier Trilla wrote:
> Hi Maria,
> 
> For what I'm seeing, looks like every time birds gets a route update via BGP 
> the route is replaced, I enabled debug in kernel protocol and I'm seeing this:
> 
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 80.84.147.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 80.84.147.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 80.84.147.0/24 via 172.17.0.1 
> on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 78.40.178.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 78.40.178.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 78.40.178.0/24 via 172.17.0.1 
> on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP > added [best] 64.17.246.0/23 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  icewall_01_BGP < rejected by protocol 
> 64.17.246.0/23 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32  kernel1 < replaced 64.17.246.0/23 via 172.17.0.1 
> on vlan10
> 
> 
> But does it make sense? I mean, deleting and reading the route to replace it 
> when a route update is received doesn't seem to make much sense considering 
> the gateway does not change.

Hi

It is true that we send a route to the kernel if there is any change in
the route, even if the change is irrelevant for the kernel itself. They
may be export filters in kernel that are dependent on any route
attributes so it is hard to predict whether the change is relevant or not.

> Also, I guess removing and adding the route again could lead to some packet 
> loss.

We could use replace netlink operation instead of remove/add, but that has some 
other
problems (like insufficient protection against overwriting alien routes).

> Maybe bird needs to keep some information in the route in order to keep sync 
> and that's why it needs to replace it? Or there is anything I'm missing...

We could keep that information but that essentialy means double memory 
footprint for simple setups.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BGP next hop

[Ondrej Zajicek]

On Wed, May 09, 2018 at 07:38:31AM +, Arvin Gan wrote:
> Hi all,
>
>I notice below description in user guide, my understand is source
> address mainly used for BGP session for TCP connection ,don't understand
> why this source is also used as next_hop_addr calculation.

Hi

Generally, BGP speaker have to select reasonable bgp_next_hop address
from its IP addresses. BIRD uses by default the source address of BGP
session if applicable (like matching AF or ext_next_hop), otherwise it
takes preferred IPv4 or IPv6 address of the same iface where is the
source address. Or could be explicitly configured by 'next hop address'
option. See function bgp_channel_start() for details.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: [PATCH] babel: Set onlink flag for IPv4 routes with unreachable next hop

[Toke Høiland-Jørgensen]

Ondrej Zajicek  writes:

> On Mon, May 07, 2018 at 08:57:43PM +0200, Toke Høiland-Jørgensen wrote:
>> Toke Høiland-Jørgensen  writes:
>> 
>> > If the next hop of a route is not a reachable address, the route should be
>> > installed as onlink. This enables a configuration common in mesh networks
>> > where the mesh interface is assigned a /32 and babel handles the routing by
>> > installing onlink routes.
>> 
>> Any feedback on this? :)
>
> Hi
>
> There are some minor issues (like there should be check for error values
> from neigh_find2()), but that can i fix. I just wonder whether we would
> want this behavior as a default or whether it should be configurable.
> What do you think?

Well, always-on matches what babeld does, that's why I went with that.
Is there a case where this is not desirable behaviour?

-Toke

Re: BGP manage advertisement

[Mattia Milani]

And you have a plane to inculude it in the next release?

Il mer 9 mag 2018, 15:22 Ondrej Zajicek  ha scritto:

> On Wed, May 09, 2018 at 01:09:48PM +0200, Mattia Milani wrote:
> > Hello all,
> > Sorry but searching on the wiki i didn't find anyting about that.
> > My question is, bird implements the MRAI minimum rout adverisement
> interval
> > timer? what in the RFC 4271 is called "MinRouteAdverisementIntervalTimer"
> > you can see it on section 9.2.1.1, page 85.
> > There is a version of bird that implement it? and if I can use it how
> can i
> > mange it?
>
> Hello
>
> We do not have support for MRAI.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>

Re: ROA 2.x

[Ondrej Zajicek]

On Mon, May 07, 2018 at 02:35:17PM +0300, Mikhail Mayorov wrote:
> Hi all!
> 
> In version 1.x I used rtconfig for build import/export BGP check.
> It was separate files for every protocol included in main config file.
> 
> roa4 table isp1_v4 {
> roa4 95.174.96.0/19 max 24 as 49037;
> roa4 185.230.240.0/22 max 24 as 49037;
> roa4 185.9.184.0/22 max 24 as 49037;
> }
> 
> And after I use filter:
> if roa_check(isp1_v4, net, 1) = ROA_VALID then return true;
> 
> Now I find new protocol RPKI, but I don't understand how can add/delete
> ROA in table.

HI

There are no explicit commands to add/delete ROA records dynamically by
birdc. For static ROA records like in your example you can use a static
protocol connected to roa4 table to fill static ROA records.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: [PATCH] babel: Set onlink flag for IPv4 routes with unreachable next hop

[Ondrej Zajicek]

On Mon, May 07, 2018 at 08:57:43PM +0200, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen  writes:
> 
> > If the next hop of a route is not a reachable address, the route should be
> > installed as onlink. This enables a configuration common in mesh networks
> > where the mesh interface is assigned a /32 and babel handles the routing by
> > installing onlink routes.
> 
> Any feedback on this? :)

Hi

There are some minor issues (like there should be check for error values
from neigh_find2()), but that can i fix. I just wonder whether we would
want this behavior as a default or whether it should be configurable.
What do you think?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

BGP manage advertisement

[Mattia Milani]

Hello all,
Sorry but searching on the wiki i didn't find anyting about that.
My question is, bird implements the MRAI minimum rout adverisement interval
timer? what in the RFC 4271 is called "MinRouteAdverisementIntervalTimer"
you can see it on section 9.2.1.1, page 85.
There is a version of bird that implement it? and if I can use it how can i
mange it?

Thanks a lot,
Mattia

BGP next hop

[Arvin Gan]

Hi all,
   I notice below description in user guide, my understand is source address 
mainly used for BGP session for TCP connection ,don't understand why this 
source is also used as next_hop_addr calculation. If source address is related 
with next hop calculation, this case is may not support: used MP_REACH_NLRI to 
support IPV4 route with IPV4 next hop ,but TCP connection type is IPV6. Since 
to support MP_REACH_NLRI for ipv4 channel, need to enabled ext_next_hop, if 
enabled ext_next_hop, if  ipv6 source address is selected as next_hop_addr if 
no others configuration for next_hop_addr. Does my understand is correct ?

source address ip

Define local address we should use for next hop calculation and as a source 
address for the BGP session. Default: the address of the local end of the 
interface our neighbor is connected to.

Thanks
Arvin