Hi, Alan

I’m not sure RyuBGPS needs to verify local/remote AS values match as you 
mentioned.
According to your network design policy, Network operator should decide the 
configuration whether the next_hop need to change or not. 
RyuBGPS can already handle the next_hop whether it is changed or not  as 
is_next_hop_self.

Case 1: use of iBGP internal peering
  If you don’t want to change the next_hop, you should configure BGP neighbor 
as “is_next_hop_self=False”.
  Please check the “neighbor_add” in detail.
  -> http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html 
<http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html>

Case 2: use of eBGP/iBGP peering (my situation in previous)
  If you want to change the next_hop, you should configure BGP neighbor as 
“is_next_hop_self=True”.

Maybe, it is useful to understand next_hop_self specification.
-> https://github.com/osrg/ryu/commit/75753841aa66ce1aab5f56d83ea618ede8d82193 
<https://github.com/osrg/ryu/commit/75753841aa66ce1aab5f56d83ea618ede8d82193>

Sorry for not understanding your situation.

Thanks
Toshiki

> 2015/02/13 6:06、Alan Quillin <alan.quil...@rackspace.com> のメール:
> 
> Toshiki, thanks for the info, I had not thought about that situation.  Before 
> submitting a another patch, I wanted to check if the fix is as simple as I 
> believe.  In the logic when checking if the path has a nexthop set, I can 
> also verify that the local and remote AS values match.  If they do, then use 
> the nexthop from the path, else fall into the other logic to use nexthop 
> value set on the peer or the ip of the RyuBGP1.  Please let me know if my 
> assumptions here are correct. 
> 
> Thanks,
> - Alan Quillin
> ________________________________________
> From: Toshiki Tsuboi [t.tsubo2...@gmail.com]
> Sent: Thursday, February 12, 2015 2:22 PM
> To: Alan Quillin
> Cc: ryu-devel@lists.sourceforge.net
> Subject: Re: [Ryu-devel] [PATCH] Modified BGP Update logic to use the path 
> nexthop value first
> 
> Hi, Alan
> 
> It seems your patch doesn’t work properly in the following topology.
> Because RyuBGP1 has sent BGP UPDATE(Nexthop: y.y.y.y) to R2.
> 
>                 iBGP                 eBGP
>    ------- R1 -----------> RyuBGP1 ---------> R2
>    x.x.x.x   y.y.y.y            z.z.z.z       => UPDATE(Nexthop: y.y.y.y)
> 
> When RyuBGP1 has received  BGP UPDATE Message from R1 of iBGP session,
> RyuBGP1 should change the nexhop from “y.y.y.y" to “z.z.z.z" for R2 of eBGP 
> session.
> 
> 
> Best regards.
> Toshiki Tsuboi
> 
> 
>> 2015/02/13 1:43、alan.quil...@rackspace.com のメール:
>> 
>> From: Alan Quillin <alanquil...@gmail.com>
>> 
>> If the path has a next hop value set, it should be used in the BGP
>> Update message first.  This changes to logic to use the check for the
>> next hop in the order prefix/path->peer config->speaker config.  This
>> will allow for sending the nexthop as part of the add_prefix message and
>> allow for overiding the nexthop of the peer if one is set.
>> 
>> Signed-off-by: Alan Quillin <alanquil...@gmail.com>
>> ---
>> ryu/services/protocols/bgp/info_base/base.py | 4 ++++
>> ryu/services/protocols/bgp/peer.py           | 8 ++++++--
>> 2 files changed, 10 insertions(+), 2 deletions(-)
>> 
>> diff --git a/ryu/services/protocols/bgp/info_base/base.py 
>> b/ryu/services/protocols/bgp/info_base/base.py
>> index 7cb14f3..3c3c180 100644
>> --- a/ryu/services/protocols/bgp/info_base/base.py
>> +++ b/ryu/services/protocols/bgp/info_base/base.py
>> @@ -806,6 +806,10 @@ class Path(object):
>> 
>>        return not interested_rts.isdisjoint(curr_rts)
>> 
>> +    def has_nexthop(self):
>> +        return not (not self._nexthop or self._nexthop == '0.0.0.0' or
>> +                    self._nexthop == '::')
>> +
>>    def __str__(self):
>>        return (
>>            'Path(source: %s, nlri: %s, source ver#: %s, '
>> diff --git a/ryu/services/protocols/bgp/peer.py 
>> b/ryu/services/protocols/bgp/peer.py
>> index 0dd48d7..a99cbe2 100644
>> --- a/ryu/services/protocols/bgp/peer.py
>> +++ b/ryu/services/protocols/bgp/peer.py
>> @@ -802,11 +802,15 @@ class Peer(Source, Sink, NeighborConfListener, 
>> Activity):
>>        """
>>        route_family = path.route_family
>> 
>> -        # By default we use BGPS's interface IP with this peer as next_hop.
>> -        if self._neigh_conf.next_hop:
>> +        # By default we use path's nexthop if has been set, else we check 
>> the
>> +        # BGPS's interface IP with this peer as next_hop.
>> +        if path.has_nexthop():
>> +            next_hop = path.nexthop
>> +        elif self._neigh_conf.next_hop:
>>            next_hop = self._neigh_conf.next_hop
>>        else:
>>            next_hop = self.host_bind_ip
>> +
>>        if route_family == RF_IPv6_VPN:
>>            next_hop = self._ipv4_mapped_ipv6(next_hop)
>> 
>> --
>> 2.3.0
>> 
>> 
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Ryu-devel mailing list
>> Ryu-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
> 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to