Quagga OSPF Error IP_ADD_MEMBERSHIP
-
Hi there,
Just testing the Quagga OSPF package, have setup to 2 test machines and so far have being unable to get them to exchange information or in fact show each other as neighbours, seeing the following error on both sides (different IP's of course)
ospfd[21850]: can't setsockopt IP_ADD_MEMBERSHIP (fd 10, addr 172.16.16.247, ifindex 1, AllSPFRouters): Invalid argument; perhaps a kernel limit on # of multicast group memberships has been exceeded?
Package Version: 0.99.20_3 v0.1.1
pfsense Version: 2.0.1-RELEASE (amd64)Thanks in advance
J
-
that's one I haven't seen before, I've installed and setup the quagga package several times (I created the package).
What kind of interface is that IP (172.16.16.247) on? Can you show the contents of the config files in /usr/local/etc/quagga/ and also "ifconfig -a"?
-
Morning,
Here is the output from the other end (as can't access the 172.16.16.247 end from here)
ospfd[50010]: can't setsockopt IP_ADD_MEMBERSHIP (fd 10, addr 172.16.16.254, ifindex 1, AllDRouters): Invalid argument; perhaps a kernel limit on # of multicast group memberships has been exceeded?
This file was created by the pfSense package manager. Do not edit!
password ******
log syslog
interface em0
ip ospf priority 1router ospf
ospf router-id 127.0.0.1
ospf rfc1583compatibility
network 172.16.16.0/24 area 0.0.0.0em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:3a:b1:4e
inet6 fe80::20c:29ff:fe3a:b14e%em0 prefixlen 64 scopeid 0x1
inet 172.16.16.254 netmask 0xffffff00 broadcast 172.16.16.255
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:3a:b1:58
inet 192.168.80.254 netmask 0xffffff00 broadcast 192.168.80.255
inet6 fe80::20c:29ff:fe3a:b158%em1 prefixlen 64 scopeid 0x2
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
nd6 options=3 <performnud,accept_rtadv>pflog0: flags=100 <promisc>metric 0 mtu 33664
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
enc0: flags=41 <up,running>metric 0 mtu 1536
em0_vlan99: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=3 <rxcsum,txcsum>ether XXX.XXX.XXXX.XXX
inet6 XXX.XXX.XXXX.XXX%em0_vlan99 prefixlen 64 scopeid 0x8
inet XXX.XXX.XXXX.XXX netmask 0xfffff800 broadcast XXX.XXX.XXXX.XXX
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 99 parent interface: em0It may well be something I have done, but is happening at both end straight out the box
Many thanks for your time on this
J</full-duplex></performnud,accept_rtadv></rxcsum,txcsum></up,broadcast,running,simplex,multicast></up,running></promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></pointopoint,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast>
-
Can you try to remove the "priorty" setting from that interface to see if it changes anything? If not, add it back.
I also haven't tried the rfc1583compatibility option so you might try toggling that also.
-
Hi there,
Same error either removing/enablong rfc and the priority settings.
J
-
OK, so it's probably not anything in Quagga itself, but the OS preventing it on that interface.
Guess it could be because you're doing that on the VLAN parent interface. We don't recommend using the default (untagged) vlan parent interface when performing VLAN trunking. You should only assign tagged interfaces (em0_vlanXXX) once you define them.
That or maybe there is some other daemon latched onto that interface doing something.
-
I updated quagga last night and at least one person who was previously seeing this error is working fine now. So if you try it again on this setup, it may be working.
-
Cool will give it a shout tonight and confirm in the morning
Many thanks for keeping me updated
J
-
Hi there,
Managed to test, looking better but still can't get them talking, basically have one running on the WAN interface and one on the LAN, LAN sees the one on the WAN interface, but stays in a state of :
172.x.x.x 1 Init/DROther 30.164s 172.x.x.x em0:172.x.x.x 0 0 0
The one on the WAN never sees this one at all.
Getting the following error on the LAN side..
ospfd[55865]: Packet 172.x.x.x (WAN_Address) [Hello:RECV]: NetworkMask mismatch on em0:172.x.x.x (LAN_Address) (configured prefix length is 24, but hello packet indicates 32).
Just to clarify, basically the one I refer to us WAN is actually an internal child network used for testing, am sure this is really obvious and just a setting, i'll have a play and come back, if you know instantly whats wrong let me know
Cheers
J
-
Ok, just converted pfsense to router on the inside interface as I am making the massive jump that multicast's are not accepted on the WAN interface and everything working as expected.
Assuming I am right about multicasts, I can't imagine many situations where OSPF will be enabled on a WAN interface, but would be useful to know if there is a way to accept these?
If however I am wrong (and yes did have a rule allowing all to WAN so can't imagine this was a rule blocking) any other others?
Many thanks for all your work on this
J
-
Sorry guys, all fixed, added a rule in for OSPF itself and of course the WAN address in my previous rule is incorrect, it needs to be multicast address. Anyway, all perfect and working
Many thanks
J
-
Hi there,
Just as an update, it looks like the do not redistrubite option doesn't have any affect, I have added in a connected network to not be redistrubited but is still showing on the other fw as an ospf route, checking the config it is within the ospf.conf file as:
no network 192.x.x.x/24 area 0.0.0.0
Any ideas?
Cheers
J
-
Quagga probably needs some fancier syntax there that I don't know yet – perhaps some kind of route map exclusion.
I haven't had a situation to use that with yet, so I didn't get to fully vet that part.
If you (or someone else) can track down some syntax examples for that in quagga (or cisco, quagga's config is nearly identical to ios) I can fix the code.
-
Hi mate, Just seen it works the other way i.e. no ticking the box distributes the route so for me thats perfect anyway, will do some research and see if I can work out how to do the excludes.
At the moment this is perfect for me, so seriously many thanks, the whole project is fantastic
J
