[quagga-users 12541] Re: Virtual Machines Network

Or TCP connects in qemu/kvm, or OpenVPN tunnels....

JR

On Oct 24, 2011, at 3:54 PM, Lennart Sorensen wrote:

> On Mon, Oct 24, 2011 at 11:29:37PM +0100, Alex Bligh wrote:
>> 
>> 
>> --On 24 October 2011 20:09:31 -0200 Roberto Schuster
>> <robertoaschuster@...> wrote:
>> 
>>> The problem is that I don't know how to do this comunication between the
>>> VMs and I would apreciate if you guys could give some tips...
>> 
>> Each eth device on the vm will appear as a tap device in the host. Put
>> these into bridges with brctl, and off you go.
> 
> Or if using qemu or kvm you can use the "vlans" to create virtual networks
> of virtual devices in each VM.
> 
> -- 
> Len Sorensen
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@...
> http://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 12542] QUAGGA and multiple routing tables

Hi All,

while the "table" parameter is present in the list of supported zebra params,
it's unclear if Quagga is capable to support multiple routing tables concurrently for all (or some)
routing protocols.

Can OSPF v2/v3 populate two routing tables the same time: the default table with default routing and
additional table with "preferred" routers?

[quagga-users 12543] Re: QUAGGA and multiple routing tables

2011/11/2 Ros Molodyko <rmolodyko@...>:
> Hi All,
>
> while the "table" parameter is present in the list of supported zebra params,
> it's unclear if Quagga is capable to support multiple routing tables concurrently for all (or some)
routing protocols.
>
> Can OSPF v2/v3 populate two routing tables the same time: the default table with default routing and
additional table with "preferred" routers?

No. Support for multiple routing tables is fairly incomplete.

Just as an example, there are several functions calling vrf_table()
with the 'id' parameter set to '0'. In addition to that, the
rib_weed_tables() function removes from zebra all routes that doesn't
belong to the main routing table at startup.

I would recommend you to try another approach to solve your problem.

[]s

--

-- 
Renato Westphal

[quagga-users 12544] Regarding smux peer command in quagga ripngd

Hi,

Regarding “smux  peer” command support in  quagga daemons observation:--

Even though OID’s are mentioned for all Quagga routing protocols in
the quagga document,It is observed in ripngd that,  'smux peer' commnd
is not recognizing and throwing error.

And also  I verified in quagga 0.99.18 source code that  ripngd is not
containing  “smux peer” registration part is not available.
Is ripng  not supporting smux configuration? Any issues in this regard

Thanks,
Ganesh

Reference:--
16.3 MIB and command reference
The following OID numbers are used for the interprocess communication
of snmpd and the
Quagga daemons. Sadly, SNMP has not been implemented in all daemons yet.
(OIDs below .iso.org.dod.internet.private.enterprises)
zebra .1.3.6.1.4.1.3317.1.2.1 .gnome.gnomeProducts.zebra.zserv
bgpd .1.3.6.1.4.1.3317.1.2.2 .gnome.gnomeProducts.zebra.bgpd
ripd .1.3.6.1.4.1.3317.1.2.3 .gnome.gnomeProducts.zebra.ripd
ospfd .1.3.6.1.4.1.3317.1.2.5 .gnome.gnomeProducts.zebra.ospfd
ospf6d .1.3.6.1.4.1.3317.1.2.6 .gnome.gnomeProducts.zebra.ospf6d
The following OID numbers are used for querying the SNMP daemon by a client:
zebra .1.3.6.1.2.1.4.24 .iso.org.dot.internet.mgmt.mib-2.ip.ipForward
ospfd .1.3.6.1.2.1.14 .iso.org.dot.internet.mgmt.mib-2.ospf
bgpd .1.3.6.1.2.1.15 .iso.org.dot.internet.mgmt.mib-2.bgp

[quagga-users 12545] Topology in Quagga

Hi,

How can I configure the topology on quagga?
Can be anyone. I just need to know wich one it is and how to configure it.
Thanks a lot!

[quagga-users 12546] QUAGGA does not pupulate the non-default routing table on virtual node

Hi All,

I detected the issue with the secondary routing table support in QUAGGA when it runs on virtual Boing's CORE node.

If QUAGGA is configured for non-default routing table (the parameter "table <number>" in the quagga
config file), QUAGGA still build the valid routes but marks them as "inactive" and does not place routes
onto the appropriate routing table (see attachment).

I retested that case with the real nodes, the second routing table is populated fine.

What is the reason or condition to make the links "inactive"?

RH1# show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route, o - OSPFv3

C>* 10.0.0.1/32 is directly connected, eth0
o   10.0.0.2/32 [110/3] via 10.0.0.3 inactive, 00:00:21
K * 10.0.0.2/32 via 10.0.0.3, eth0 inactive
o   10.0.0.3/32 [110/2] is directly connected, eth0, 00:00:26
K>* 10.0.0.3/32 is directly connected, eth0
o   10.0.0.11/32 [110/3] via 10.0.0.3 inactive, 00:00:21
C>* 10.0.3.0/24 is directly connected, eth1
o   10.0.14.0/24 [110/3] via 10.0.0.3 inactive, 00:00:21
K * 10.0.14.0/24 via 10.0.0.3, eth0 inactive
C>* 127.0.0.0/8 is directly connected, lo
o   192.168.10.0/24 [110/3] via 10.0.0.3 inactive, 00:00:21
C>* 192.168.10.0/24 is directly connected, ctrl0

[quagga-users 12547] Regarding aggregate-address command in Quagga ripngd

_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 12548] Re: bgp - quagga-0.99.18

On Oct 23, 2011, at 9:15 PM, Ingo Flaschberger wrote:
> with the core2-quad and desktop intel e1000 cards (it's an appliance) I'm able to move 400kpps / 200mbit
64-byte packets;
> with server-cards, especially 10gige cards 1mpps should be possible.

Right now, with a modern kernel on a mid-range E3 quad-core Xeon, using an 82576 multiqueue ethernet card,
you can handle a full gigabit ethernet of minimum-sized packets, with a bit of CPU left over for random
other stuff. You don't need a 10gig card, though it would return some CPU to you for other uses. OTOH, it
might make more sense to invest that money in a hexacore chip instead. I like being hardware limited to
1gbps on those interfaces, so I know that a DDoS can't take down the router. If you really need more
bandwidth than that, you still need a Cisco or Juniper (unless you're in a "safe" environment).

> check also manpage of network card (rx/tx buffer tuning) and:
> net.isr.maxthreads=
> net.isr.bindthreads=
> net.inet.ip.intr_queue_maxlen=

Be careful what you do with buffers. See http://www.bufferbloat.net/ if you don't understand how big
buffers can be bad.  I have to admit, I am not yet satisfied with how we're handling buffering, and I'd like a
dynamic solution. However, in practice, we seem to be doing OK.

/a

[quagga-users 12549] ospfd daemon (quagga-0.99.20_1) not work FreeBSD 9.0-RC1 amd64

ospfd daemon  (quagga-0.99.20_1)  not work FreeBSD 9.0-RC1 amd64
ospfd.log:
2011/11/07 04:17:38 OSPF: OSPFd 0.99.20 starting: vty <at> 2604
2011/11/07 04:17:38 OSPF: interface 10.147.254.202 [1] join AllSPFRouters Multicast group.
2011/11/07 04:17:38 OSPF: LSA[Type5:0.0.0.0]: Not originate AS-external-LSA for default
2011/11/07 04:17:40 OSPF: ospf_recv_packet read length mismatch: ip_len is 96, but recvmsg returned 76
2011/11/07 04:17:40 OSPF: ospf_recv_packet read length mismatch: ip_len is 96, but recvmsg returned 76
2011/11/07 04:17:40 OSPF: ospf_recv_packet read length mismatch: ip_len is 84, but recvmsg returned 64
2011/11/07 04:17:44 OSPF: ospf_recv_packet read length mismatch: ip_len is 84, but recvmsg returned 64
2011/11/07 04:17:44 OSPF: ospf_recv_packet read length mismatch: ip_len is 84, but recvmsg returned 64
2011/11/07 04:17:50 OSPF: ospf_recv_packet read length mismatch: ip_len is 96, but recvmsg returned 76
2011/11/07 04:17:50 OSPF: ospf_recv_packet read length mismatch: ip_len is 104, but recvmsg returned 84
2011/11/07 04:17:50 OSPF: ospf_recv_packet read length mismatch: ip_len is 96, but recvmsg returned 76
it's bug ?

Sergey V. Legkih

[quagga-users 12550] Re: bgp - quagga-0.99.18

On 06/11/2011 20:52, Alexis Rosen wrote:
> Be careful what you do with buffers. See http://www.bufferbloat.net/ if
> you don't understand how big buffers can be bad.  I have to admit, I am
> not yet satisfied with how we're handling buffering, and I'd like a
> dynamic solution. However, in practice, we seem to be doing OK.

bufferbloat.net rails on about stupidly large buffers, i.e. several seconds
worth of buffering that you would get in CPE devices.  For a core router
interface running at 1G/10G, if you're pushing more than 100-150ms on any
particular queue, then that queue is too large.  FreeBSD will not buffer
that much by default.

Nick