Page 1 of 1
Multicast, the proper answer
Posted: Wed Jan 03, 2007 7:15 am
by Snapdragon
6 network cards in the system. Each with their own bound IP and slave IP's. They are going out to the router and ARPing on the wrong interface.
Do I need to disable multicast to make them talk on their own interfaces? And if so, what the heck is the command for ifcfg-ethx, because I'm pulling my freakin hair out here trying to find it. All I can find is bonding bonding bonding I don't want to bond, I want to SEGREGATE!!!
Posted: Wed Jan 03, 2007 8:15 am
by Snapdragon
Maybe I'm just frustrated and don't understand what I'm doing. I gave up and came home.
This is my set, all in the same /24, currently being routed as .128/26 (subnet 191)
eth0 .136 + .131
eth1 .160
eth2 .161 + .165, .166
eth3 .162
eth4 .163
eth5 .164 + others
When I ping from the outside, the router ARP's a random interface, unless I ifdown all the wrong ones, and bring them up in the right order, and ping them on the way, but after a while the router doesn't see any traffic and drops the ARP.
So I have traffic for the IP's bouncing around all over the place. Instead of having a controlled set of IP's, I just have 6 Gb of connectivity to my switch that anyone can use.
The idea here is that 160 will be limited to x kb/sec, 161 will have slightly more kb/s, etc. People on 164 are entitled to 40 GB of traffic a month so they will get the highest throuput bias. Obviously this doesn't work if traffic is jumping all over the interfaces.
Do I have to hardcode the MAC in the router to make this happen?
FYI my upstream provider is using Microtik, and I've never liked it. This is not a "hardware" router, but I aim to buy my own router and stick it after his and before my switch.
Posted: Wed Jan 03, 2007 1:06 pm
by scott
Hell no

What kind of router are you using that it cant track MAC addresses correctly? How is it physically wired? Are you using auto-negotiate or fixed speeds on the ports?
Posted: Wed Jan 03, 2007 5:33 pm
by Snapdragon
It's called Microtik, it's some kind of stupid software that my upstream uses, I HATE it because it loves to bind IP's to a MAC and then not let them go, and now it won't bind when I want it to.
The NIC's are all plugged into a Dell 2724 gig switch, currently in unmanaged mode, then to a Cisco switch, a 2924 I think (or 1924), and then into the Nic card of his PC that's running the router.
So once I get my own proper router and slam it after his, I shouldn't have this non-binding problem anymore? What about the cross talk between interfaces?
And I'm guessing I should leave Multicast turned on, that has to do with downstream broadcasting, not cross talking NIC's right?
Posted: Wed Jan 03, 2007 11:37 pm
by scott
well unless they're doing VLAN's or something, your MAC address shouldnt be going past that Dell switch. Multicasting isnt in play here, if its a layer 2 the only things that come to mind would be that the switch has ACL's to bind a MAC to a port, there are VLANS in the mix, or its a spanning tree protocol issue.
Posted: Thu Jan 04, 2007 8:11 am
by Snapdragon
So if I put the switch into managed mode, will it route the traffic properly to the right IP/card then?
I still am back to the issue of traffic spamming across all the interfaces.
Posted: Thu Jan 04, 2007 3:35 pm
by scott
That would depend on the way its configured. If you're seeing traffic from all interfaces on every port of the switch, then its not actually being a switch, or its got some kind of goofy vlan configuration. Id reset the config on it if you can, then see what happens.
Posted: Fri Jan 05, 2007 2:15 am
by Snapdragon
OK. All I want is confirmation that the fault lies in the switch and not in CentOS configuration or drivers. To me it looked like the OS was sending the data wherever it wanted to, but if you say it's the switch, I will play with it.
To me, I just see all 7 activity lights blink together, so I really can't tell at this point, but I haven't played with any of the settings in the switch yet, yet it's in unmanaged mode too right now, which might be all the problem.