Hi Gabriele,
Thank you for your suggestion!
Your suggestion is it is useful to optimize the NEXT_HOP attribute if routers
share the same segment, right?
You mean Ryu should update the NEXT_HOP attribute?
Thanks,
Iwase
On 2017年12月20日 23:57, Gabriele Lospoto wrote:
Dear Ryu Team,
I'm implementing a BGP scenario involving 3 Ryu controllers (each of
them is running the Ryu BGP application) on a shared LAN (setting is
enclosed to this email).
This is the control plane BGP table at controller 1 (90.0.0.1):
[
{
"paths":
[
{
"origin": "i",
"aspath": [2],
"prefix": "25.0.0.0/8",
"bpr": "AS Path",
"localpref": "",
"nexthop": "90.0.0.2",
"metric": "",
"labels": null,
"best": true
},
{
"origin": "i",
"aspath": [3, 2],
"prefix": "25.0.0.0/8",
"bpr": "",
"localpref": "",
"nexthop": "90.0.0.3",
"metric": "",
"labels": null,
"best": false
}
],
"prefix": "25.0.0.0/8"
},
{
"paths":
[
{
"origin": "i",
"aspath": [3],
"prefix": "35.0.0.0/8",
"bpr": "AS Path",
"localpref": "",
"nexthop": "90.0.0.3",
"metric": "",
"labels": null,
"best": true
},
{
"origin": "i",
"aspath": [2, 3],
"prefix": "35.0.0.0/8",
"bpr": "",
"localpref": "",
"nexthop": "90.0.0.2",
"metric": "",
"labels": null,
"best": false
}
],
"prefix": "35.0.0.0/8"
},
{
"paths":
[
{
"origin": "i",
"aspath": [],
"prefix": "15.0.0.0/8",
"bpr": "Only Path",
"localpref": "",
"nexthop": "0.0.0.0",
"metric": "",
"labels": null,
"best": true
}
],
"prefix": "15.0.0.0/8"
}
]
As you can see, for prefix 25.0.0.0/8 and 35.0.0.0/8 there are two
different alternatives, but I was expecting that the next hop stays
unchanged due to the "shared segment (or media)" optimization. Even RFC
4271 opens to this possibility in the section 5.1.3 at point 2) when
they say:
"Otherwise, if the route being announced was learned from an external
peer the speaker can use an IP address of any adjacent router (known
from the received NEXT_HOP attribute) that the speaker itself uses for
local route calculation in the NEXT_HOP attribute, provided that peer X
shares a common subnet with this address. This is a second form of
"third party" NEXT_HOP attribute".
I know, this is just an optimization, but it is implemented in other BGP
implementation (e.g. Quagga), as you can see in the following (control
plane BGP table on BGP speaker 90.0.0.1 in a scenario with Quagga BGP
speaker in place of a Ryu BGP speaker):
r1# show ip bgp
BGP table version is 0, local router ID is 90.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 15.0.0.0 0.0.0.0 0 32768 i
* 25.0.0.0 90.0.0.2 0 3 2 i
*> 90.0.0.2 0 0 2 i
* 35.0.0.0 90.0.0.3 0 2 3 i
*> 90.0.0.3 0 0 3 i
Am I wronging something?
Thanks in advance.
Gabriele
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
