Hi again Zadd,

Could you keep the Ryu-devel mailing list <ryu-devel@lists.sourceforge.net>, 
please?

> Could you please show me some simple ryu zebra server use cases.

For the use case I assumed when implemented, please refer to the first patch of 
Ryu Zebra server.
  https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg13094.html

At that time, Ryu has already supported the BGP protocol service like Quagga's 
BGPd, but has no
feature for RIP, OSPF or else.
So I wondered if Ryu can communicate the existing routers by using non OpenFlow 
protocols which
Quagga already has (e.g., RIP, OSPF).
Many of Ryu Zebra server features are working progress though...


> How to commute with other zebra daemons or routers.

To communicate with other Zebra daemons (e.g., RIPd, OSPFd), Ryu assumes 
incoming connection via
the unix domain socket or TCP socket (see the above commit message).
On the other hand, to communicate with other routers (e.g., Cisco, Juniper, 
other Quagga), assumes
the connected Zebra daemons can communicate with them, so Ryu can advertise 
routes (e.g., locally
generated, from the OpenFlow networks) to other routers via the Zebra daemons.
Or directory communicate with other routers via Ryu BGP service.


Thanks,
Iwase

On 2017年11月21日 22:13, zadd wrote:

Hi
Sorry I still have some questions. Could you please show me some simple ryu zebra server use cases. How to commute with other zebra daemons or routers.
zadd

On Nov 13, 2017 10:51, "Iwase Yusuke" <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:

    Hi Zadd,

    Please keep mailing list <ryu-devel@lists.sourceforge.net 
<mailto:ryu-devel@lists.sourceforge.net>>.

    Your question is whether Ryu can act as multiple zebra daemons against 
different Quagga's OSPFd,
    right?
    Tow OVS instances are connecting to single Ryu and you need to define pairs 
of Ryu Zebra and OSPFd?

    When I implemented Zebra service on Ryu, I didn't suppose such situation 
and Zebra server instance
    maintains only single DB for routes and interfaces information.
    But, I haven't implement a lot of how to handle connections to Zebra 
clients (e.g., OSPFd) and
    received routes from clients, it just generates events to notify message 
receptions.
    So it might be possible to act as separated Zebra daemons if RyuApp handle 
these events to act so.
    (Sorry, I have no plan to implement it though...)

    Thanks,
    Iwase

    On 2017年11月13日 01:55, zadd wrote:

        Hi,

        Thanks for the help before. I still have some questions about the zebra 
service. For a
        hybrid topo of several ospf routers and sdn switches like this:

            router---ovs----router
        |        |                   |
        |        |                   |
        ovs--router---------router
        sdn switches and routers are crossly deployed. Can zebra service handle 
this situation.

        is it possible to make ryu act as multiple zebra daemons to parse ospf 
messages from
        different sdn switches so as to make the  sdn switches or areas act 
like a router.

        On Mon, Sep 4, 2017 at 6:28 PM, zadd <zadd1...@gmail.com 
<mailto:zadd1...@gmail.com>
        <mailto:zadd1...@gmail.com <mailto:zadd1...@gmail.com>>> wrote:

             Thank you.I will try it.

             On Sep 4, 2017 10:00, "Iwase Yusuke" <iwase.yusu...@gmail.com
        <mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
        <mailto:iwase.yusu...@gmail.com>>>
             wrote:

                 Hi Zadd,

                 Would you add CC for Ryu-devel mailing list?


                 On 2017年09月04日 00:38, zhang dong wrote:

                     Hello
                               I am working on the hybrid SDN network(routers 
connected to ovs). I'm
                     wondering if I can use the zebra protocol in ryu to deal 
with the packet_In  OSPF
                     message from the router connected to the ovs. If not,could 
you please
        enlighten me how
                     i can make the hosts in ospf area and openflow area 
communicate with each other.


                 I guess receiving OSPF packets via Packet-In is difficult.
                 How about adding an additional port which OSPFd listening on?

                 For example, the following topology has a port which 
connecting to OSPFd's
        interface and
                 forwards
                 OSPF packets for OSPFd then Ryu communicates with OSPFd via 
Zebra daemon.
                 (Also, Ryu can acts as Zebra daemon against OSPFd, I guess.)

                                    +---Zebra---+
                                    |           |
                       +-----------Ryu         OSPFd
                       |            |           |
                 (Open Flow)  (Open Flow)   (OSPF pcakets)
                       |            |           |
                 (OpenFlow NW)----OVS----------+
                                    |
                                    +----------(OSPF NW)

                 Thanks,
                 Iwase


                               I'm looking forward to your reply.

                     Thanks,
                     zadd



------------------------------------------------------------------------------
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