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

Reply via email to