How to add multicast mac address?

E

ekta

I am looking for a command similar to ipmaddr in linux.
I want to configure multicast mac address 01:00:00:00:00:01 to my network card. How can I achieve this.

In linux I can do this using ipmaddr command. What is the equivalent command in FreeBSD?
 
ifconfig(5) (not very clearly described, I must admit)

ifconfig your_if ether 00:11:00:11:00:11

Not sure is it's different for multicast.
 
Thanks for your reply.

But if i do like that i will loose my unicast mac address. I dont want that. I want my interface to have both unicast as well as multicast address
 
I never heard of the possibility to use more than one ethernet address on a ethernet card at a given time.
Some switches consider that some 'destination addresses' are 'multicast addresses', which instructs them to send a pachet on multiple (possible not all) ports, even if it's not sent to the broadcast address or to a unknown ethernet address.
Some well-konwn multicast addresses are listed here.
FreeBSD can be a multicast receiver out-of-the-box. To route traffic, a recompiled kernel and mrouted are needed, see this for details.
 
Hi there

A multicast mac address is derived from the multicast group and should fallow the IEE-registered standard with 01-00-5E.
A multicast mac address is used as destination and not as source so there is no reason for you to configure this on your nic . Your nic will automatically accept traffic destined to a particular multicast mac
 
Some multicast MAC addresses don't correspond to IP multicast groups

The OS has to tell your NIC which destination MAC addresses it should listen to. That happens automatically for your standard incoming MAC address, and for IP multicast groups that you join.

However, for things like LLDP or CDP, they are link-level protocols and have no corresponding IP multicast groups. In order for your NIC to start receiving packets sent to those link-level-only multicast addresses, it has to be told you're interested in that traffic. So, as was mentioned earlier, on Linux you use the ip maddress add to tell the NIC to listen for that link-level-only multicast address. For LLDP the multicast address is 01:80:c2:00:00:0e and for CDP it's 01:00:0c:cc:cc:cc.

You could always turn on promiscuous mode, but that would be a little sub-optimal ;)
 
Forgot to say - I'd like the answer to this question too :)

My CDP/LLDP code works nicely on Linux without having to enable promiscuous mode - I'd like to do the same for FreeBSD.

But, unless I'm mistaken none of the previous posts say how to do that. DutchDaeomn gave a suggestion, which etka said wouldn't be useful for this purpose.

So, if anyone knows how to _add_ a multicast MAC address not corresponding to an IP-layer multicast group without deleting or changing your NIC's current MAC address, I'd love to hear how to do it.
 
There is one question about your requirement. Are you sure you need to configure this kind of address on your device? For example, a CDP/LLDP-enabled device will ALWAYS send packets having the destionation MAC address set to a well-known LLADDR (01:80:c2:00:00:0e, 01:00:0c:cc:cc:cc and so on), regardless of the configuration on the other side of the link. Those packets sent to specific link addresses are received by a process, such as net-mgpd/cdpd, which runs usually in promiscuous mode.
Having the protocol LLADDR configured on the physical interface alone won't make the receiver CDPD and/or LLDP enabled, you still need to run a specific program which receive and analyze packets sent to a specific link-level address. The only advantage is that you can have a physical interface with more than one receive channels, and a filter process running on one channel won't be able to read other channels' data.
Anyway, you can have multiple MAC addresses appearing on a single physical interface (read this thread), but you still need a low-level packet filter, bpf/pcap-style. Using the link above, the filter runs at netgraph level (in kernel) for all traffic, where it is split on multiple ngeth interfaces, so you can run the bpf/pcap filter application with lower amounts of traffic.
 
Still trying to avoid promiscuous mode...

Thanks for the reply ecazamir,

Promiscuous mode is strongly discouraged in many shops and in some shops disallowed completely. One should avoid it if one can. With modern switched networks, it is of less practical concern than it once was, but that doesn't always influence people's opinions...

My code listens to LLDP and CDP and avoids promiscuous mode on Linux. My code turns on promiscuous mode if it is unable to set up the multicast MAC addresses properly. I'd rather avoid it on FreeBSD just like I do on Linux... Promiscuous mode is not required for CDP or LLDP. Cisco and the IEEE did not design basic protocols that require promiscuous mode.

I use libpcap - for exactly the reasons you cite - and for portability (my code also runs on Windows!). But I don't enable promiscuous mode if I can avoid it...

Well... I looked over the link you cited, and the references it gives. It's not exactly obvious, is it? ;-). This looks analogous to the netlink layer of Linux - which is also not obvious either - but on Linux there's a command on top of it [ip] which is passably easy to use.

It looks like all the script example really does is set up a new interface name (which I don't need) and then just puts the hardware in promiscuous mode - which is what I'm trying to avoid - sigh...

The FreeBSD kernel has to do the work I want it to do whenever it joins an IP multicast group (that is, it has to add a new MAC address to listen to to the NIC). I want to add the multicast MAC address to the NIC without joining an IP multicast group. I presume that those other multicast MAC addresses (those from IP multicast groups) don't put the interface into promiscuous mode, and I'd like to avoid it too...

The netgraph interface might do what I need, but it's not yet obvious to me how to make it do that...
 
The way I understand, "promiscuous mode" IS required on interfaces which should pass traffic for other MAC addresses than device's lladdr. If Linux can use multiple lladdrs, with or without explicit promiscuous mode, it may put the interface in promiscuous mode without telling you. The only difference is that you may call this "limited promiscuous mode".
There are commercial solutions which don't work without promiscuous mode, such as VMWare, I never heard of VMWare admins complaining about 'permanent promiscuous mode'. Also, the 'bridge' facility of any OS won't work without promiscuous mode, whether is done on usersace or kernel space.
And the last thing: cisco protocols are desogned fir cisco devices. The hardware on those devices is not the same as on your desktop or server, so don't expect them to perform identically. These devices use specialized hardware, with filters and queues implemented in silicon.
Now I have a question for you: assuming that you configure a protocol-specific lladdr on a device, do you think that other devices, using the same protocol on the same network segment, will remain unaffected?
 
All NICs have the ability to listen to multiple MAC addresses - for example its native MAC address and ff-ff-ff-ff-ff-ff. There is another feature in Linux (cluster IPs where you assign a multicast MAC address to the whole cluster), and of course as I mentioned, joining multicast IP groups does the same thing. Every time you join a multicast group (up to some limit), your NIC should not go into promiscuous mode.

LLDP is an IEEE protocol. There are actually a number of other well-known non-IP multicast groups for non-IP protocols.

LLDP and CDP messages are not allowed to be forwarded by anyone else - including bridges, and are only visible to the recipient at the other end of the link. So, yes, I know for sure that no one else is affected by my listening to these two addresses. [I suspect most hardware managed bridges provide their own LLDP or CDP packets].

How this works in practice is that about once every minute or so, your switch creates a unique packet that it sends to only you - and it contains information that is unique to your port - like the port number you're connected to, and the settings of the port you're connected to. This packet is not sent in any sense on the broader "network" - it is a private communication between your switch and you. If there is a switch between you and your LLDP-conforming switch, it is supposed to block that traffic and not forward it. You are not allowed to forward it - at least in theory ;-). My old, cheap, unmanaged 100mbit switches pass LLDP through - but my newer cheap unmanaged gbit switches block it.

The VMware solutions probably put the NIC into promiscuous mode when they overflow the MAC table of the NIC - or maybe they just give up and do it from the start - because they know they will overflow it.

What I hear you saying is that you don't believe there's any way I can get FreeBSD to do what I want it to - followed by justifications and explanations of why it's not important. I wasn't trying to judge FreeBSD - just trying to take best advantage of its features - and explain why this is something I try to do when I can. And maybe you're right, in the grand scheme of things maybe it is unimportant.

Thanks for your time and patience!
 
AlanR said:
All NICs have the ability to listen to multiple MAC addresses - for example its native MAC address and ff-ff-ff-ff-ff-ff.
Click to expand...
This is a design feature. But the packets sent to FF:FF:FF:FF:FF:FF are known as 'broadcast packets' instead of unicast.

AlanR said:
LLDP and CDP messages are not allowed to be forwarded by anyone else - including bridges, and are only visible to the recipient at the other end of the link.
Click to expand...
I don't take this for granted, this should be written 'LLDP and CDP messages should not be allowed'...

AlanR said:
I suspect most hardware managed bridges provide their own LLDP or CDP packets.
Click to expand...
They provide their own source ethernet address, but send the packet to the well-known protocol address. A filter on the receive side decides where the packet should be processed or discarded.

AlanR said:
If there is a switch between you and your LLDP-conforming switch, it is supposed to block that traffic and not forward it. You are not allowed to forward it - at least in theory ;-). My old, cheap, unmanaged 100mbit switches pass LLDP through - but my newer cheap unmanaged gbit switches block it.
Click to expand...
Sure, depending what protocol you have in mind. If you talk about a 802.1d-aware switch, then this will not forward packets sent to 01:80:c2:00:00:00. But if it an unmanaged switch, then it will flood the packet on all the ports, if the target address is not known on the switch forwarding table. That's why I asked you before: Are you sure the other devices will remain unaffected? If you use an unmanaged switch, and then connect to a port a device which uses the 01:80:c2:00:00:00 MAC address, then all the packets for STP will be sent only through that port. Same for other protocols, such as LLDP.

AlanR said:
The VMware solutions probably put the NIC into promiscuous mode when they overflow the MAC table of the NIC - or maybe they just give up and do it from the start - because they know they will overflow it.
Click to expand...
No. The physical interface is ALWAYS in promiscuous mode. The VMWare hosts uses filters to decide where it needs to send specific packets. This is true for other virtualization solutions which are using bridging: VirtualBox

AlanR said:
What I hear you saying is that you don't believe there's any way I can get FreeBSD to do what I want it to - followed by justifications and explanations of why it's not important.
Thanks for your time and patience!
Click to expand...

Well, If you really need it, then probably you can write yourself a driver and/or userland tools to implement this 'limited promiscuous mode'. For me (and probably many others), 'promiscuous mode' means 'processing packets which are not sent to the broadcast address and not to the ethernet device address'. If it's two or two thousand, it doesn't matter. It's promiscous mode, plain and simple.
I find your problem intrestingly enough, but I don't have the possibility to code what you require. I just tried to clear things up, so we can talk about the same thing: promiscuous mode or not. If you have any reference where I could find why a device using more than one ethernet address at a time should not be called as 'working in promiscuous mode', I would be happy to read it.

Thanks for your time and patience!
Click to expand...
You're welcome ;-)
 
You must log in or register to reply here.
Back
Top