Print

[fukawi2]

My searching has returned nothing, so I apologize if this is answered, but I have been unable to find the information.

I have a pair of CentOS 6 boxes acting as a H/A perimeter firewall/router, using keepalived to control the Master/Slave operation. I have native IPv6 connectivity, and the boxes handle the routing and firewalling fine, using radvd to send router advertisements and isc dhcpd to handle out leases. (Both radvd and dhcpd are stopped/started by keepalived in accordance with which box is master and which is slave)

All is working well, however the boxes do not respond to FF01::2 "all-routers" address so I have a few of questions regarding that:

1. Should they respond to all-routers address? (Just the master, or both boxes?)
2. What are implications of them not being part of that address since everything is already working?
3. How do I get them to join that address?

[snarked]

...  All is working well, however the boxes do not respond to FF01::2 "all-routers" address so I have a few questions....

Did you try FF02::2?

[fukawi2]

I'm assuming that was a typo on my behalf in my original post.  FF02::2 still doesn't work:

Code: [Select]

fw1 ~ # ip a a ff02::2/16 dev bond0.42
RTNETLINK answers: Cannot assign requested address
fw1 ~ # ip a a ff02::2 dev bond0.42
RTNETLINK answers: Cannot assign requested address
fw1 ~ # ip a a ff02::2/64 dev bond0.42
RTNETLINK answers: Cannot assign requested address

[snarked]

Next issue: Are they configured as multicast routers?  That requires an additional kernel configuration item (and if you use modules, an additional module need be loaded).  The configuration item is called CONFIG_IP_MROUTE, so look for a module with "mroute" in its name if you use modules.  (CentOS uses the Linux kernel).

You cannot assign a multicast address to an interface as it is not valid to use as a SOURCE address.  "netstat -g" will tell you for which multicast addresses you're listening.

[fukawi2]

Thanks for your help on this

These are CentOS boxes; that kernel option is enabled:

Code: [Select]

fw1 ~ # grep CONFIG_IP_MROUTE /boot/config-2.6.32-696.13.2.el6.x86_64
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
It appears the boxes have joined the multicast group, but only on some interfaces:

Code: [Select]

fw1 ~ # netstat -g | grep ip6-allrouters
eth0            1      ip6-allrouters
eth1            1      ip6-allrouters
eth2            1      ip6-allrouters
eth3            1      ip6-allrouters
bond0.3114      1      ip6-allrouters
bond0.3115      1      ip6-allrouters
bond0.3116      1      ip6-allrouters
bond0.3199      1      ip6-allroutersOther interfaces not listed above: bond0.20, bond0.42, bond0.3111, bond0.3112, bond0.3118, bond0.3130

So, how does the kernel decide which interfaces to join on?  Nothing stands out to me as being different between these interfaces.

[snarked]

Interfaces have a "multicast" flag.  See if that flag matches the ones you see (it should) and if it is absent from the other interfaces.  If that's the case, then you need to use "ip" or "ifconfig" to set the multicast flag, and see if that fixed the issue.

Virtual interfaces based on a real one (or set, such as bond0) usually reflect the multicast flag of the real one(s).  Could it be that one of your bonded interfaces has an incorrect flag?  (That shouldn't happen, but it can).

I don't use the CentOS distribution, so you've probably reached the limit of my help and suggestions.

[fukawi2]

Well if we focus on bond0.42, it does has the multicast flag set:

Code: [Select]

fw1 ~ # ip a s bond0.42 | head -n1
16: bond0.42@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
Thanks again for all your input on such an old thread.  Obviously things have been working fine, but I still want to know how it's supposed to work!   You've given me some good guidance; I'll keep playing with it and see what I can work out.

EDIT: It seems the interfaces that I run radvd on are joined to the group; those that I don't send RA's on are not joined. Which makes sense!  It's radvd that takes care of the mcast group membership; not the kernel or CentOS userspace.  I'll dig in to radvd to see if I can trick it in to joining without sending RA's.