headers
Deepankar Gupta | 14 May 2013 18:32
Favicon

[quagga-dev 10535] AUTO: Deepankar Gupta is out of the office from 13/05 to 17/05 (returning Fri 05/17/2013)


I am out of the office from Mon 05/13/2013 until Fri 05/17/2013.

Due to personal reason, I am on leave from 13th/May to 17th/May. I will not
have access to email. In case of need please call me 9582030802.

Thanks & Regards
Deepankar Gupta

Note: This is an automated response to your message  "Quagga-dev Digest,
Vol 118, Issue 14" sent on 05/14/2013 16:30:01.

This is the only notification you will receive while this person is away.

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you
Permalink | Reply | 0 comments |
headers
'Chris Hall' | 13 May 2013 22:10

[quagga-dev 10532] bgp and Multiprotocol Extension Capability

If a neighbour sends no Multiprotocol Extension Capability (MP-Ext) at
all, Quagga will happily assume that the neighbour supports all the
afi/safi it is configured for.

This strikes me as broken.  RFC4760 says that one or more MP-Ext
capabilities implies that the BGP speaker "uses Multiprotocol
Extensions".  The RFC does not specify what the absence of any MP-Ext
means, but I think it reasonable to assume a BGP speaker that does not
"use Multiprotocol Extensions" is implicitly an unadorned IPv4 Unicast
BGP speaker.

Does anyone think it is unreasonable to treat current behaviour as a
bug ?

I guess most BGP implementations these days send MP-Ext for every
afi/safi supported, even if that is only IPv4 Unicast ?  I note that
BIRD has an option:

  advertise ipv4 switch

  Advertise IPv4 multiprotocol capability. This is not a correct
  behavior according to the strict interpretation of RFC 4760,
  but it is widespread and required by some BGP implementations
  (Cisco and Quagga). This option is relevant to IPv4 mode with
  enabled capability advertisement only.

  Default: on. 

It seems to me that if (say) IPv6 Unicast is announced by MP-Ext, and
if IPv4 Unicast is also required, then it must also be announced by
(Continue reading)

Permalink | Reply | 3 comments |
headers
hervé frantz | 10 May 2013 13:03
Picon

[quagga-dev 10530] Some GSOC proposals

Hi to everybody,
I have a set of proposition and questions that can be often used for GSOC and everyone is welcome to give is point of view

OpenFlow INTEGRATION

It is planned to join quagga in the SDN moving ? if Openflow should be integrated should be in the OS or Quagga itself?

Quagga and other routing protocols implementation

I have a question about quagga interoperability with other opensource software implementation (BIRD, XORP, OpenBGPd/OpenOSPFd) and even vendor implementation address to quagga developer and adminis . Does quagga work well in a heterogeneous environment? Is it a need to make quagga more interoperable with other implementation?

IDRP implementation

What do you think about some IDRP implementation within quagga ?

NETCONF integration for Quagga

What do you think about some IDRP integration within quagga ?



the discussion is open so don't hesitated

have a nice day, Frantz Kengne
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi to everybody,<br>
</div>
<div>I have a set of proposition and questions that can be often used for GSOC and everyone is welcome to give is point of view<br><br>
</div>
<div>OpenFlow INTEGRATION<br><br>
</div>
<div>It is planned to join quagga in the SDN moving ? if Openflow should be integrated should be in the OS or Quagga itself?<br>
</div>
<div>
<br>Quagga and other routing protocols implementation<br><br>
</div>
I have a question about quagga interoperability with other opensource software implementation (BIRD, XORP, OpenBGPd/OpenOSPFd) and even vendor implementation address to quagga developer and adminis . Does quagga work well in a heterogeneous environment? Is it a need to make quagga more interoperable with other implementation?<br><br>
</div>IDRP implementation<br><br>
</div>What do you think about some IDRP implementation within quagga ?<br><br>
</div>NETCONF integration for Quagga<br><br>What do you think about some IDRP integration within quagga ?<br><br><br><br>
</div>the discussion is open so don't hesitated <br><br>
</div>have a nice day, Frantz Kengne<br>
</div></div>
Permalink | Reply | 0 comments |
headers
Lokesh Pareta | 9 May 2013 07:41
Favicon

[quagga-dev 10527] RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version

Hi All,

Tata Consultancy Services (TCS) wants to contribute to Quagga development by providing the implementation code for RFC-6506, developed and tested on quagga-0.99.21 version.

Abstract of the RFC-6506:
  • Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets.
  • This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).  
  • In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used.  
  • RFC-6506 defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication.

Steps to test/run the developed patch file on quagga-0.99.21 :
  • As per RFC, implementation is done by TCS in order to provide authentication support on both interface and area.
  • Commands to be used are as follows:
  • For an interface(under interface <i/f name>)-
                ipv6 ospf6 sha-256-authentication                                [command to set AT-bit on interface]
                ipv6 ospf6 sha-256-key <key-id> sha-256 <password>                  [command to attach key-id and password to the packets]
  • For an area (under router ospf6)-
                area <area-id> sha-256-authentication                                [command to set AT-bit on area]
  • In order to authenticate OSPFv3 packets, please provide combination of both AT bit  on an interface/area and key-id with sha-256 password.

Please find following attachment:
  • Patch file of RFC-6506 implementation



Kindly revert in case of any queries or doubts and suggestions are also welcome.

Thanks & Regards,
Lokesh Pareta

Telecom Technology - NextGen R&D,
Tata Consultancy Services
TCS Towers, 249 D&E Udyog Vihar,
Phase IV, Gurgaon
Haryana, India
Cell:- +91 8506946082
Mailto: lokesh.pareta <at> tcs.com
Website: http://www.tcs.com

___________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
___________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Attachment (rfc-6506.patch): application/octet-stream, 61 KiB
<div>Hi All,
<br><br>Tata Consultancy Services (TCS) wants
to contribute to Quagga development by providing the implementation code
for RFC-6506, developed and tested on quagga-0.99.21 version. 
<br><br>Abstract of the RFC-6506:
<ul>
<li>Currently, OSPF for IPv6 (OSPFv3) uses
IPsec as the only mechanism for authenticating protocol packets.
</li>
<li>This behavior is different from authentication
mechanisms present in other routing protocols (OSPFv2, Intermediate System
to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next
Generation (RIPng)). &nbsp;
</li>
<li>In some environments, it has been found
that IPsec is difficult to configure and maintain and thus cannot be used.
&nbsp;
</li>
<li>RFC-6506 defines an alternative mechanism
to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend
upon IPsec for authentication.</li>
</ul>
<div>
<br>Steps to test/run the developed patch
file on quagga-0.99.21 :
<ul>
<li>As per RFC, implementation is done by
TCS in order to provide authentication support on both interface and area.
</li>
<li>Commands to be used are as follows:
</li>
<li>For an interface(under interface &lt;i/f
name&gt;)-</li>
</ul>&nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ipv6 ospf6 sha-256-authentication
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[command
to set AT-bit on interface]
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; ipv6 ospf6 sha-256-key &lt;key-id&gt; sha-256
&lt;password&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;[command to attach key-id and password to the packets]
<ul><li>For an area (under router ospf6)-</li></ul>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; area &lt;area-id&gt;
sha-256-authentication &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;[command to set AT-bit on area]
<ul><li>In order to authenticate OSPFv3 packets,
please provide combination of both AT bit &nbsp;on an interface/area and
key-id with sha-256 password.</li></ul>
<br>Please find following attachment:
<ul><li>Patch file of RFC-6506 implementation</li></ul>
<br><br><br>Kindly revert in case of any queries
or doubts and suggestions are also welcome.
<br><br>Thanks &amp; Regards,<br>
Lokesh Pareta
<br><br>
Telecom Technology - NextGen R&amp;D,<br>
Tata Consultancy Services<br>
TCS Towers, 249 D&amp;E Udyog Vihar,<br>
Phase IV, Gurgaon<br>
Haryana, India<br>
Cell:- +91 8506946082<br>
Mailto: lokesh.pareta <at> tcs.com<br>
Website: <a href="http://www.tcs.com/">http://www.tcs.com</a><br><br>
___________________________________________<br>
Experience certainty. &nbsp; &nbsp; &nbsp; &nbsp;IT Services<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;Business Solutions<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;Outsourcing<br>
___________________________________________</div>
<p>=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</p>

<p></p>
</div>
Permalink | Reply | 3 comments |
headers
Ján Janovic | 6 May 2013 20:11
Picon
Favicon

[quagga-dev 10525] Re: OSPF: External Prefix Summarization

Hello again!

It should be done according to your instructions, Joachim :)

Now, there is only one, squashed commit for feature branch ospfd/ext_summarization with edited documentation and GNU coding style applied. You can access it directly here:

https://bitbucket.org/janovic/quagga/commits/3e4a81207ae87f13d0a8be3ce0145618cd5b19e2

or you can clone whole repository:

git clone https://janovic <at> bitbucket.org/janovic/quagga.git

Please, review it and send your response. Thanks for the big support with this feature.

Regards
Jan Janovic


On 05/06/2013 01:18 AM, Joachim Nilsson wrote:
Hi again Ján!

Sorry for the delay, like I said in our private conversation, it's been quite a busy couple of weeks at work. I've just tested the latest fixes tonight, and it works great! :-)

A more click-friendly URL to Ján's OSPF summary-address is here:

    https://bitbucket.org/janovic/quagga/commits/all

Like I mentioned privately, if you:

    1. Squash the commits,
    2. Add texinfo documentation for the summary-address cmd, and
    3. Make some minor GNU coding style fixups

then I'd be more than happy to sign off on your work! :-)

Best regards
 /Joachim

On 04/23/2013 12:06 AM, Ján Janovic wrote:
Hi everybody.

I have updated my feature branch ospfd/ext_summarization at

https://janovic <at> bitbucket.org/janovic/quagga.git

Today I resolved all issues we talked about in this thread with Joachim. To be specific:
* summary-address command and its variation are now correctly saved to config file
* discard route is added for every configured summary route
* message "summary route for ... added" now appears only while debug ospf events is on

<at> Joachim: Could you please test it like before? I very appreciate any help.

<at> David: I've noticed from mailing list and git commits that you are quite "in charge" here. Can you please give me some instructions, what should I do next with code to get closer to the official release? I think it could be interesting and useful contribution :)

Thanks in advance.
Regards.
Jan Janovic


On 04/21/2013 06:45 PM, Joachim Nilsson wrote:
On 04/21/2013 03:30 PM, Ján Janovic wrote:
There is a one more idea in my head. Maybe you(or somebody else) could help me with
that. As you know for sure, when you start summarization on Cisco devices,
"discard" summary route is added to route table to prevent routing loops.
Is there a possibility to add such a route in linux? And from Quagga code?

Or is it a null route you're referring to?

zebra.conf:
    ip route 0.0.0.0 tun0
    ip route 0.0.0.0 eth0 10
    ip route 0.0.0.0 null0 255

If tun0 is up it runs as default gateway, otherwise, eth0 and as a last resort
the null0 route will act as a blackhole.

Regards
 /Joachim




_______________________________________________
Quagga-dev mailing list
Quagga-dev <at> lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev 





<div>
    Hello again!<br><div class="moz-forward-container">
      <div class="moz-cite-prefix"> <br>
        It should be done according to your instructions, Joachim :)<br><br>
        Now, there is only one, squashed commit for feature branch
        ospfd/ext_summarization with edited documentation and GNU coding
        style applied. You can access it directly here:<br><br><a moz-do-not-send="true" href="https://bitbucket.org/janovic/quagga/commits/3e4a81207ae87f13d0a8be3ce0145618cd5b19e2">https://bitbucket.org/janovic/quagga/commits/3e4a81207ae87f13d0a8be3ce0145618cd5b19e2</a><br><br>
        or you can clone whole repository:<br><br>
        git clone <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://janovic <at> bitbucket.org/janovic/quagga.git">https://janovic <at> bitbucket.org/janovic/quagga.git</a><br><br>
        Please, review it and send your response. Thanks for the big
        support with this feature.<br><br>
        Regards<br>
        Jan Janovic<br><br><br>
        On 05/06/2013 01:18 AM, Joachim Nilsson wrote:<br>
</div>
      <blockquote cite="mid:5186E8DC.6000908 <at> gmail.com" type="cite">Hi
        again J&aacute;n! <br><br>
        Sorry for the delay, like I said in our private conversation,
        it's been quite a busy couple of weeks at work. I've just tested
        the latest fixes tonight, and it works great! :-) <br><br>
        A more click-friendly URL to J&aacute;n's OSPF summary-address is here:
        <br><br>
        &nbsp;&nbsp;&nbsp; <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://bitbucket.org/janovic/quagga/commits/all">https://bitbucket.org/janovic/quagga/commits/all</a>
        <br><br>
        Like I mentioned privately, if you: <br><br>
        &nbsp;&nbsp;&nbsp; 1. Squash the commits, <br>
        &nbsp;&nbsp;&nbsp; 2. Add texinfo documentation for the summary-address cmd,
        and <br>
        &nbsp;&nbsp;&nbsp; 3. Make some minor GNU coding style fixups <br><br>
        then I'd be more than happy to sign off on your work! :-) <br><br>
        Best regards <br>
        &nbsp;/Joachim <br><br>
        On 04/23/2013 12:06 AM, J&aacute;n Janovic wrote: <br><blockquote type="cite">Hi everybody. <br><br>
          I have updated my feature branch ospfd/ext_summarization at <br><br><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://janovic <at> bitbucket.org/janovic/quagga.git">https://janovic <at> bitbucket.org/janovic/quagga.git</a>
          <br><br>
          Today I resolved all issues we talked about in this thread
          with Joachim. To be specific: <br>
          * summary-address command and its variation are now correctly
          saved to config file <br>
          * discard route is added for every configured summary route <br>
          * message "summary route for ... added" now appears only while
          debug ospf events is on <br><br>
           <at> Joachim: Could you please test it like before? I very
          appreciate any help. <br><br>
           <at> David: I've noticed from mailing list and git commits that
          you are quite "in charge" here. Can you please give me some
          instructions, what should I do next with code to get closer to
          the official release? I think it could be interesting and
          useful contribution :) <br><br>
          Thanks in advance. <br>
          Regards. <br>
          Jan Janovic <br><br><br>
          On 04/21/2013 06:45 PM, Joachim Nilsson wrote: <br><blockquote type="cite">On 04/21/2013 03:30 PM, J&aacute;n Janovic
            wrote: <br><blockquote type="cite">There is a one more idea in my head.
              Maybe you(or somebody else) could help me with <br>
              that. As you know for sure, when you start summarization
              on Cisco devices, <br>
              "discard" summary route is added to route table to prevent
              routing loops. <br>
              Is there a possibility to add such a route in linux? And
              from Quagga code? <br>
</blockquote>
            <br>
            Or is it a null route you're referring to? <br><br>
            zebra.conf: <br>
            &nbsp;&nbsp;&nbsp; ip route 0.0.0.0 tun0 <br>
            &nbsp;&nbsp;&nbsp; ip route 0.0.0.0 eth0 10 <br>
            &nbsp;&nbsp;&nbsp; ip route 0.0.0.0 null0 255 <br><br>
            If tun0 is up it runs as default gateway, otherwise, eth0
            and as a last resort <br>
            the null0 route will act as a blackhole. <br><br>
            Regards <br>
            &nbsp;/Joachim <br><br><br>
</blockquote>
        </blockquote>
        <br><br>
        _______________________________________________ <br>
        Quagga-dev mailing list <br><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Quagga-dev <at> lists.quagga.net">Quagga-dev <at> lists.quagga.net</a>
        <br><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.quagga.net/mailman/listinfo/quagga-dev">http://lists.quagga.net/mailman/listinfo/quagga-dev</a>
        <br><br><br>
</blockquote>
      <br><br>
</div>
    <br>
</div>
Permalink | Reply | 0 comments |
headers
Ján Janovic | 6 May 2013 18:25
Picon
Favicon

[quagga-dev 10523] Quagga documentation .tex

Hi,

is it possible to get .tex file of Quagga documentation please? I would 
like to add a description of new commands used for OSPF External Prefix 
Summarization (see another thread) there.

Thanks in advance
Ján Janovic
Permalink | Reply | 1 comment |
headers
spandan pradhan | 3 May 2013 07:21
Picon

[quagga-dev 10513] a quick hello

Hello everyone, I am new to the mailing list, and i feel kind of lost . I am interested in networking part, the hardware . 

--
From the PC of
Spandan Pradhan
Acme Engineering College
           spandanlovesu <at> hotmail.com
           info <at> spandan.com.np
               www.meroudayapur.com
          


<div><div dir="ltr">Hello everyone, I am new to the mailing list, and i feel kind of lost . I am interested in networking part, the&nbsp;hardware&nbsp;.&nbsp;<br clear="all"><div><br></div>-- <br><div>
<div>From the PC of</div>
<div>Spandan Pradhan</div>
<div>Acme Engineering College</div>
<div>Email : <a href="mailto:spandan_pradhan <at> yahoo.com" target="_blank">spandan_pradhan <at> yahoo.com</a>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:spandanlovesu <at> hotmail.com" target="_blank">spandanlovesu <at> hotmail.com</a><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:info <at> spandan.com.np" target="_blank">info <at> spandan.com.np</a>
</div>
<div>Website : <a href="http://www.spandan.com.np" target="_blank">www.spandan.com.np</a>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="http://www.meroudayapur.com" target="_blank">www.meroudayapur.com</a>
</div>
<div>Blogs : <a href="http://www.technetnepal.net/blogs/spandanp" target="_blank">www.technetnepal.net/blogs/spandanp</a>
</div>
</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
<div><br></div>
<div><br></div>
</div></div>
Permalink | Reply | 1 comment |
headers
MohammadJavad NoroozOliaee | 1 May 2013 22:22
Picon

[quagga-dev 10497] What should I do?

Hello,

I don't know what to do now? Help me please

Thanks,
MJ
<div><div dir="ltr">Hello,<div><br></div>
<div>I don't know what to do now? Help me please</div>
<div><br></div>
<div>Thanks,</div>
<div>MJ</div>
</div></div>
Permalink | Reply | 0 comments |
headers
Nathan Wilder | 1 May 2013 21:51
Picon
Favicon

[quagga-dev 10496] Additional GSoC Proposal

Quagga Community,

Unless you all have any objections, I would like to submit a second proposal for GSoC.  The OSPF replay and testing tool is still hands down my preferred project.  But as it seem to be a popular choice among potential GSoC students, I'd like to submit an additional proposal for the Zebra IPC clean-up in case I'm not selected to work on the OSPF tool.  It looks like an interesting endeavor that would get me familiar with all the Quagga components, although I do have some concerns about thorough testing, particularly with those protocols with which I have no experience (Babel, ISIS, and only have a little knowledge of RIP).  I'd assume that any testing I would do would be supplemented by and any code reviewed by the community before it's committed? 

So, the way I understand this clean-up project is that the Zebra IPC exchanges route information among the daemons and the local machine-specific route stack.  However, this IPC is interfaced to each daemon in different ways specific to that module's protocol.  So, the API needs to be cleaned up and standardized so all modules use a common interface, and one that is extensible for future protocols including MPLS.

I am thinking that the best approach would be to update zebra with the common API, then write a small program to talk to zebra via this new API to ensure things are generally working as expected.  At this point, I could then start to work my way thru the daemons updating them for the API, testing, and submitting them for review before moving on to the next one.

Does this generally sound like what you all had in mind, and do you have any more detailed insight into what would be involved or likely problem areas?

Thanks,

Nathan Wilder
<div><div>
<div><span>Quagga Community,</span></div>
<div><span><br></span></div>
<div><span>Unless you all have any objections, I would like to submit a second proposal for GSoC.&nbsp; The OSPF replay and testing tool is still hands down my preferred project.&nbsp; But as it seem to be a popular choice among potential GSoC students, I'd like to submit an additional proposal for the Zebra IPC clean-up in case I'm not selected to work on the OSPF tool.&nbsp; It looks like an interesting endeavor that would get me familiar with all the Quagga components, although I do have some concerns about thorough testing, particularly with those
 protocols with which I have no experience (Babel, ISIS, and only have a little knowledge of RIP).&nbsp; I'd assume that any testing I would do would be supplemented by and any code reviewed by the community before it's committed?&nbsp;</span></div>
<div><span><br></span></div>
<div><span>So, the way I understand this clean-up project is that the Zebra IPC exchanges route information among the daemons and the local machine-specific route stack.&nbsp; However, this IPC is interfaced to each daemon in different ways specific to that module's protocol.&nbsp; So, the API needs to be cleaned up and standardized so all modules use a common interface,
 and one that is extensible for future protocols including MPLS.</span></div>
<div><span><br></span></div>
<div><span>I am thinking that the best approach would be to update zebra with the common API, then write a small program to talk to zebra via this new API to ensure things are generally working as expected.&nbsp; At this point, I could then start to work my way thru the daemons updating them for the API, testing, and submitting them for review before moving on to the next one.</span></div>
<div><span><br></span></div>
<div><span>Does this generally sound like what you all had in mind, and do you have any more detailed insight into what would be involved or likely problem areas?</span></div>
<div><span><br></span></div>
<div><span>Thanks,</span></div>
<div><span><br></span></div>
<div><span>Nathan Wilder</span></div>
</div></div>
Permalink | Reply | 0 comments |
headers
Adrian Ban | 1 May 2013 13:39
Picon

[quagga-dev 10489] Adding "encapsulation dot1q" option to interfaces

Hi,

I want to try to add the possibility to create VLANs subinterfaces 
directly from Quagga.
The reason is that I hate to do it all the time from the OS with iproute 
or OS specific init.d scripts. More elegant is to do it from one 
combined CLI.

 From the point of view of the programming logic seems to not be to 
difficult.

But I'm not very familiarly with the quagga libs and I need some help 
from you or some points of start.

For the part of netlink/rtnetlink I can handle it (already found what I 
need and also the parameters I need to set in the netlink message, 
inspired from iproute, to be send to the kernel).

But before I send the message to the kernel I need to make some sanity 
checks before the "encapsulation dot1q <1-4094>" command to be send.

So this is what I want to do:

1. check the interface name to be in a format like this: eth0.243
2. extract the real interface from the interface name: eth0
3. check if the dot1q parameter is in the range 1-4094 (already done it)
4. check if the specific dot1q vlan id is already token by another 
subinterface of the same interface
5. send the message to the kernel to create the subinterface with the 
name and the specific vlan id
6. zebra should check automatically that a new interface is up and it 
should install all needed stuff (hope this is the flow from what I could 
get form the quagga sources).

The main step for me is the step 1 and 2. There are some regex functions 
in lib but really I don't know how to use them because I didn't found to 
be used anywhere in the sources.
Can anyone tell me an help for those functions or what alternatives I 
got in quagga to do a regex search, match and extraction?

If this command is interesting for the quagga project I can submit the 
code after I will finish it.
Else I will release on my personal site as an additional patch.

Best regards,
Adrian
Permalink | Reply | 25 comments |
headers
Charlet, Ricky | 1 May 2013 02:09
Picon
Favicon

[quagga-dev 10488] ripd/rip_interface.c memleak from inappropriate strdup() calls

Howdy,
        I'm new around these parts and just jumping into quagga code.

        During review, I believe I've spotted a few memory leaks in ripd/rip_interface.c.  In several places,
there are calls to stdlib.h's strdup() function. Memory returned from strdup() never seems to be free'd. 
For example:

/* Add interface to rip_enable_if. */
static int
rip_enable_if_add (struct rip *rip, const char *ifname)
{
  int ret;

  ret = rip_enable_if_lookup (rip, ifname);
  if (ret >= 0)
    return -1;

  vector_set (rip->rip_enable_interface, strdup (ifname));

  rip_enable_apply_all (rip); /* TODOVJ */

  return 1;
}

        I'm just tossing this out as an FYI cause I've been wrong before (especially when I'm in a new code base). So
will someone else put some eyeballs on that and see if you think those are true memleaks? And if they are not,
I would love to be educated.

Thanks.
--
Ricky Charlet
Software Dev / Routing Dude: Aries team, Roseville CA
ricky.charlet <at> hp.com<mailto:ricky.charlet <at> hp.com>
USA: 916.785.2090
Permalink | Reply | 3 comments |

Gmane