ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Daniel Ouellet
Pass abuse makes BGPd & CARP not available to be use in most interesting
places due to valid MAC address registrations requirements.

One question on mac address for CARP interface. Is it possible to change
the default mac address use by carp interface from the default:

0000.5e00.0100 to 0000.5e00.01ff

Based on man page, mac address can be changed, but not on carp interface.

The ifconfig carp2 lladdr 00:01:23:45:67:89 doesn't work for example.

The reason I asked is kind of silly and based on the success of CARP and
BGPd I guess. (:>

The situation is, one of the major peering point on the east coast of
the US, because of pass abuse of less then proper ISP, now required and
register access to the peering point based on mac address and needs to
be register with them, makes it a bit harder to replace your routers
with multiple BGPd and CARP for reliability. Also, a bit more
interesting is the fact that multiple ISP using CARP, for easy of use I
guess pick the same CARP interface and end up with MAC address conflict,
but more over, the MAC address registration now needs to be valid
meaning one of the valid register here:

http://standards.ieee.org/regauth/oui/oui.txt

Where the 0000:5exx.xxxx is register to:

00-00-5E   (hex) USC INFORMATION SCIENCES INST
00005E     (base 16) USC INFORMATION SCIENCES INST
                                INTERNET ASS'NED NOS.AUTHORITY
                                4676 ADMIRALTY WAY
                                MARINA DEL REY CA 90292-6695
                                UNITED STATES

and it not accepted as equipment to do peering, meaning not Cisco,
routers, or Juniper routers, etc.

So, the funny part of it is that, this is not an OpenBSD problem what so
ever, nor is it that the CARP with BGPd doesn't work, all the opposite I
must admit, but then, how can one adjust the mac address of a CARP
interface to either replace it by the valid MAC address previously used
by the Cisco or Juniper routers, going on the self next, so that the
public peering switch doesn't see the changes and peering session
continue to work without registration changes, or use an other valid
IEEE mac address on the CARP interface, or not have two ISP that setup
their CARP interface using CARP 1 and end up with a MAC address
conflict. Yes, easy to change the CARP 1 setup to CARP 2 for example,
but before you see that this is the problem, you don't always see it
right away. (:>

Again, not an OpenBSD problem other then be stuck by it's own success
now where the MAC address are not accepted anymore.

Any word of wisdom on this silly issue? (:>

I find it more funny then not, however still a real problem, specially
as it is the new year, but this is not an April fools either...

I thought some others may find it funny as well, but in the end, any
suggestions on the issue a hand? Worst case simply changing the source
code default MAC address can address that on both servers, as long as
you don't forget to do so each time you reload a new current on these boxes!

Oups... Did I say someone forget to do so sometimes! (:> Finger slapping
needed...

Thanks

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Stuart Henderson
> The situation is, one of the major peering point on the east coast of
> the US, because of pass abuse of less then proper ISP, now required and
> register access to the peering point based on mac address and needs to
> be register with them, makes it a bit harder to replace your routers
> with multiple BGPd and CARP for reliability. Also, a bit more
> interesting is the fact that multiple ISP using CARP, for easy of use I
> guess pick the same CARP interface and end up with MAC address
> conflict, but more over, the MAC address registration now needs to be
> valid meaning one of the valid register here:

The 00:00:5e:xxx MAC used by CARP (and VRRP) is multicast. I don't
think you can change a multicast lladdr to a unicast one.

Wouldn't it make more sense to have multiple (non-carp) addresses on
the peering lan, ask your peers to setup a session with both routers,
and just use carp to cater for any of your own boxes that need a
static route?

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Daniel Ouellet
Stuart Henderson wrote:
> The 00:00:5e:xxx MAC used by CARP (and VRRP) is multicast. I don't
> think you can change a multicast lladdr to a unicast one.

CARP does use multicast yes, but unless I forgot something, or don't
understand something, there isn't any MAC address that are specifically
assign to multicast only like the IP address range 224.x are? Am I
missing something here? Sorry if that's so stupid of me.

> Wouldn't it make more sense to have multiple (non-carp) addresses on
> the peering lan, ask your peers to setup a session with both routers,
> and just use carp to cater for any of your own boxes that need a
> static route?

Technically possible of course, economically not however. At $2,500.00
to $4,000.00 a month for a new one at current prices now there, oppose
to the one in use now for many years that is grand farther in, ( I was
the forth contract signed at the time and in the first 10 active
sessions then) I don't see it as a viable option at this time. Not cheap
as a choice.

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Daniel Ouellet
In reply to this post by Stuart Henderson
Stuart Henderson wrote:
> The 00:00:5e:xxx MAC used by CARP (and VRRP) is multicast. I don't
> think you can change a multicast lladdr to a unicast one.

Looks like the standard required to use the MAC address for multicast in
the range of:

Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.

which has the lowest bit of the first byte set to '1'.

but here the CARP doesn't follow that, so I am not sure why it would be
required?

Again, I sure can agree that I am missing something. I would welcome
more details for sure. If that was a requirements, why wouldn't CARP use

01:00:5e:xxx instead then?

I may learn something new and interesting today. Nice way to start the
new year. What am I missing?

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Stuart Henderson
In reply to this post by Daniel Ouellet
> Stuart Henderson wrote:
> >The 00:00:5e:xxx MAC used by CARP (and VRRP) is multicast. I don't
> >think you can change a multicast lladdr to a unicast one.
>
> CARP does use multicast yes, but unless I forgot something, or don't
> understand something, there isn't any MAC address that are specifically
> assign to multicast only like the IP address range 224.x are? Am I
> missing something here? Sorry if that's so stupid of me.

0x:00:5e are multicast-specific MAC addresses - I learned about this
because shortly after the lladdr option to ifconfig was introduced there
was a thread here where somebody tried to assign one by mistake, as a
result ifconfig verifies that the requested MAC is of the correct class.

http://www.rhyshaden.com/multicas.htm has some details on this.

> Technically possible of course, economically not however. At $2,500.00
> to $4,000.00 a month for a new one at current prices now there, oppose
> to the one in use now for many years that is grand farther in, ( I was
> the forth contract signed at the time and in the first 10 active
> sessions then) I don't see it as a viable option at this time. Not cheap
> as a choice.

Ah, I see. I only know a little about peering points (and all of that
European) - I know many (most?) restrict traffic on the 'normal' lan to
unicast IP/ARP (I guess partly to ensure the core switches don't encounter
frames more likely than usual to trigger unexpected behaviour) and the
number of MAC addresses per port is often restricted, but I haven't
heard of charging separately for IP addresses before (though I guess a
restriction of 1 MAC address on a port does the same thing).

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Stuart Henderson
In reply to this post by Daniel Ouellet
> Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
> which has the lowest bit of the first byte set to '1'.

afaict: CARP traffic itself goes to the group hence 1, whereas traffic to
the shared address is just for an individual member, hence the 0. But I am
no multicast guru.

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Daniel Ouellet
Stuart Henderson wrote:
>> Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
>> which has the lowest bit of the first byte set to '1'.
>
> afaict: CARP traffic itself goes to the group hence 1, whereas traffic to
> the shared address is just for an individual member, hence the 0. But I am
> no multicast guru.

Very interesting in dead! Doing more reading and definitely interested
to know more. May explain why possible issue on the CARP usage at public
peering points might be. I don't know if any peering point would filter
all MAC in range xx.xx.5E.nn.nn.nn and obviously in that case eliminate
the usage of CARP to establish BGP sessions directly for a reliable setup.

Very interesting... I never thought of it in that perspective before!

May be I should have revised my question then as to if any known
restrictions in the use of CARP for BGPd usage in public peering points
is know at this time?

Very interesting!

Thank you for giving me something to chew on for a while Stuart! I
obviously overlooked a detail.

Many thanks for your time!

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Stuart Henderson
In reply to this post by Stuart Henderson
> > Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
> > which has the lowest bit of the first byte set to '1'.
>
> afaict: CARP traffic itself goes to the group hence 1, whereas traffic to
> the shared address is just for an individual member, hence the 0. But I am
> no multicast guru.

...ah, but of course the virtual address is what you're concerned about
(assuming you are preventing 01:00:5e CARP protocol packets from reaching
the peering lan some other way e.g. by a switch that doesn't forward
multicast out of the public port).

So, it looks like your original question stands then. Looking at
carp_set_enaddr in /usr/src/sys/netinet/ip_carp.c the MAC address
generation is hardcoded (the last octet being the vhid). Maybe it's
simply the case that because lladdr is new, and no developer found
a need to do this for CARP yet, that it hasn't been coded. Or maybe
there's another reason why this shouldn't be done (greater care
than usual would have to be taken to configure all CARP members
identically, of course).

Reply | Threaded
Open this post in threaded view
|

Re: ifconfig carp2 lladdr xx:xx:xx:xx:xx:xx not available?

Daniel Ouellet
Stuart Henderson wrote:

>>> Multicast MAC addresses use a special 24-bit prefix of 0x0100.5Enn.nnnn.
>>> which has the lowest bit of the first byte set to '1'.
>> afaict: CARP traffic itself goes to the group hence 1, whereas traffic to
>> the shared address is just for an individual member, hence the 0. But I am
>> no multicast guru.
>
> ...ah, but of course the virtual address is what you're concerned about
> (assuming you are preventing 01:00:5e CARP protocol packets from reaching
> the peering lan some other way e.g. by a switch that doesn't forward
> multicast out of the public port).

Exactly. But the issue would still be the same even if I stop it as the
virtual IP's would still have the MAC address of the 0x0000.5Enn.nnnn
here where it might be block by the provider. I am still curious to know
if that couldn't work with the MAC address of the equipment it is
replacing. One thing I don't know, I never set it up to check that
specifically, does Cisco with VRRP actually end up with a MAC address
different then the actual interface and does use the multicast range?
Knowing Cisco, I kind of guess it wouldn't, but that's speculation on my
part, I do not know that for sure! So, that makes me think it would be
possible, but what would be the implications of it, that I do not know
yet. One side however, no one on the public side would ever know then,
assuming you do block the multicast packets from reaching them on the
public side! (:>

I would be very much interested to know the pro/cons of doing so as well
as the implications of it.

> So, it looks like your original question stands then. Looking at
> carp_set_enaddr in /usr/src/sys/netinet/ip_carp.c the MAC address
> generation is hardcoded (the last octet being the vhid). Maybe it's
> simply the case that because lladdr is new, and no developer found
> a need to do this for CARP yet, that it hasn't been coded. Or maybe
> there's another reason why this shouldn't be done (greater care
> than usual would have to be taken to configure all CARP members
> identically, of course).

Or, may be following the mapping of multicast IP addresses to IEEE 802
multicast MAC addresses might well take care of the possibility in all
cases, ( well almost, still would be 32 possible overlaps for the range
of IPv4, but what are the chances of that ever happen, none in the same
peering point for sure. Not that it is bad as it is now by any mean
really! There might be some other reasons for sure as well. One that
comes to mind is keep it simple, is sure worth less trouble.