Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Pages: 1 ... 8 9 [10]
 on: October 25, 2017, 02:37:36 AM 
Started by bbecker79 - Last post by bbecker79
I've looked into the MTU, my IPv4 connection uses 1492 (due to pppoe) and the IPv6 tunnel comes out at 1472 (had this set lower).
After adjusting the tunnel MTU, things got better. TLS handshake works now but not all page content loads.
Interestingly enough I can open the URLs that cannot be loaded if I visit them directly. Will investigate this further later. Thanks for pointing out the MTU  :)

 on: October 24, 2017, 04:47:36 PM 
Started by fukawi2 - Last post by 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.

 on: October 24, 2017, 01:05:37 PM 
Started by mafische - Last post by matthiaspfaller

you seem to be located in germany, so you might be affected by

regards, Matthias

 on: October 24, 2017, 12:21:49 AM 
Started by fukawi2 - Last post by 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.

 on: October 23, 2017, 03:58:18 PM 
Started by PleasingSticks - Last post by PleasingSticks
Thanks for the help everyone!

 on: October 23, 2017, 03:25:14 PM 
Started by fukawi2 - Last post by 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

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-allrouters
Other 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.

 on: October 23, 2017, 01:40:02 PM 
Started by fukawi2 - Last post by 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.

 on: October 23, 2017, 01:30:17 PM 
Started by ralphrmartin - Last post by snarked
A6 might still be implemented by some DNS software that never was updated to remove it.  Snoop around.

 on: October 23, 2017, 04:46:18 AM 
Started by PleasingSticks - Last post by cholzhauer
Terminating this on your router is probably easiest/best.  As snarked said, you should use 6in4

 on: October 22, 2017, 10:12:44 PM 
Started by fukawi2 - Last post by 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

Pages: 1 ... 8 9 [10]