It would be useful to be able to specify different MAC addreses for every VLAN.

Why?

IMHO there are no need for that... at least in all VLAN configuration that I can imagine

Why?

IMHO there are no need for that... at least in all VLAN configuration that I can imagine

This is a feature ofen used by companies who have very strict mac-address control on their VLAN switched networks that automatically assigns VLANID based on a clients MAC-Address. However i guess this is some dude comparing the feature list with some vendors L3 switch instead of focusing on what RouterOS really is..

Regards

Henrik

This is a feature ofen used by companies who have very strict mac-address control on their VLAN switched networks that automatically assigns VLANID based on a clients MAC-Address. However i guess this is some dude comparing the feature list with some vendors L3 switch instead of focusing on what RouterOS really is..

Regards

Henrik

"have very strict mac-address control" and "automatically assigns VLANID" somehow this 2 parts of sentence sounds opposite to each other - don't you think?

Still - i have hard time to imagine this setup.

This is a feature ofen used by companies who have very strict mac-address control on their VLAN switched networks that automatically assigns VLANID based on a clients MAC-Address. However i guess this is some dude comparing the feature list with some vendors L3 switch instead of focusing on what RouterOS really is..

Regards

Henrik

"have very strict mac-address control" and "automatically assigns VLANID" somehow this 2 parts of sentence sounds opposite to each other - don't you think?

Still - i have hard time to imagine this setup.

Ok, sorry if i didn't make myself clear,

If you have all your MAC addresses in i table and only allows these to connect, that is imho strict. If you in this table also have a VLANID next to it, your users will be able to plug in their equiptment everywhere in the office and still belong to the same VLAN, however this is not a feature i see use for in a Router OS.

This text i found somewhere on the internet:

MAC-Based VLANs

The MAC address is the hardwired address built into network interface cards. The network administrator essentially creates a table that defines which MAC addresses belong with what VLAN. Compared to port configuration methods, this method provides true VLAN capabilities because membership in a VLAN is not directly tied to a specific hardware port. Configuration is done in software and a computer can usually belong to two or more VLANs. In addition, if a computer is moved to another location, it still belongs to the same VLAN because its MAC address moves with it.


/Henrik

Sorry, but dynamically adjustable VLAN-ID depending on CLIENT mac address is science fiction.

The only thing I can think of is setup where you have 500 Vlans and pppoe server on each of it. Then you will need pppoe server that can work with the VLAN tags and instead of 500 pppoe server on VLANS create just one on Ethernet.

One way or another nether of proposed setups explain why he need different MAC-addresses for each VLAN - both setups will work fine if all MAC addresses on VLAN interfaces are the same.

It's useful if layer 2 switches are inserted between VLANS, in a ring topology.
With the same MAC adress such a ring will not work at all, since the address table in the switches could not reach a stable state.

Warning - Long post.

You can specify vlans based on 802.1x MAC Authentication to a radius server (See bold print)... Straight from Cisco docs (of course this would be on a "cisco" switch but in principle it can be done anywhere).

Using 802.1X Authentication with VLAN Assignment

After successful 802.1X authentication of a port, the RADIUS server sends the VLAN assignment to configure the port. The RADIUS server database maintains the username-to-VLAN mappings, assigning the VLAN based on the username of the client connected to the port. You can use this feature to limit network access for certain users.

When configured on the switch and the RADIUS server, 802.1X authentication with VLAN assignment has these characteristics:

•If no VLAN is supplied by the RADIUS server or if 802.1X authentication is disabled, the port is configured in its access VLAN after successful authentication. An access VLAN is a VLAN assigned to an access port. All packets sent from or received on this port belong to this VLAN.

•If 802.1X authentication is enabled but the VLAN information from the RADIUS server is not valid, the port returns to the unauthorized state and remains in the configured access VLAN. This prevents ports from appearing unexpectedly in an inappropriate VLAN because of a configuration error.

Configuration errors could include specifying a VLAN for a routed port, a malformed VLAN ID, a nonexistent or internal (routed port) VLAN ID, or an attempted assignment to a voice VLAN ID.

•If 802.1X authentication is enabled and all information from the RADIUS server is valid, the port is placed in the specified VLAN after authentication.

•If the multiple-hosts mode is enabled on an 802.1X port, all hosts are placed in the same VLAN (specified by the RADIUS server) as the first authenticated host.

•If 802.1X authentication and port security are enabled on a port, the port is placed in the RADIUS server-assigned VLAN.

•If 802.1X authentication is disabled on the port, it is returned to the configured access VLAN.

When the port is in the force-authorized, force-unauthorized, unauthorized, or shutdown state, it is put into the configured access VLAN.

If an 802.1X port is authenticated and put in the RADIUS server-assigned VLAN, any change to the port access VLAN configuration does not take effect.

The 802.1X authentication with VLAN assignment feature is not supported on trunk ports, dynamic ports, or with dynamic-access port assignment through a VLAN Membership Policy Server (VMPS).

To configure VLAN assignment you need to perform these tasks:

Step 1 Enable AAA authorization by using the network keyword to allow interface configuration from the RADIUS server.

Step 2 Enable 802.1X authentication. (The VLAN assignment feature is automatically enabled when you configure 802.1X authentication on an access port).

Step 3 Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the switch:

•[64] Tunnel-Type = VLAN

•[65] Tunnel-Medium-Type = 802

•[81] Tunnel-Private-Group-ID = VLAN name or VLAN ID

Attribute [64] must contain the value VLAN (type 13). Attribute [65] must contain the value 802 (type 6). Attribute [81] specifies the VLAN name or VLAN ID assigned to the 802.1X-authenticated user.
Using 802.1X Authentication with Guest VLAN

With Release 12.2(33)SXH and later releases, you can configure a guest VLAN for each 802.1X port on the switch to provide limited services to clients, such as downloading the 802.1X client. These clients might be upgrading their system for 802.1X authentication, and some hosts, such as Windows 98 systems, might not be 802.1X-capable.

When you enable a guest VLAN on an 802.1X port, the switch assigns clients to a guest VLAN when the switch does not receive a response to its EAP request/identity frame or when EAPOL packets are not sent by the client.

In addition, the switch maintains the EAPOL packet history. If an EAPOL packet is detected on the interface during the lifetime of the link, the switch determines that the device connected to that interface is an 802.1X-capable supplicant, and the interface will not change to the guest VLAN state. The EAPOL packet history is cleared if the interface link status goes down.

Use the dot1x guest-vlan supplicant global configuration command to allow an interface to change to the guest VLAN state regardless of the EAPOL packet history. That is, a host that is not 802.1X-capable will be assigned to the guest VLAN even if a previous host on that interface was 802.1X-capable.

Note If an EAPOL packet is detected after the interface has changed to the guest VLAN, the interface reverts to an unauthorized state, and 802.1X authentication restarts.

Any number of 802.1X-incapable clients are allowed access when the port is moved to the guest VLAN. If an 802.1X-capable client joins the same port on which the guest VLAN is configured, the port is put into the unauthorized state in the user-configured access VLAN, and authentication is restarted.

When operating as an 802.1X guest VLAN, a port functions in multiple-hosts mode regardless of the configured host mode of the port.

You can configure any active VLAN except an RSPAN VLAN, a private primary PVLAN, or a voice VLAN as an 802.1X guest VLAN. The guest VLAN feature is not supported on internal VLANs (routed ports) or trunk ports; it is supported only on access ports.

The switch supports MAC authentication bypass in Release 12.2(33)SXH and later releases. When MAC authentication bypass is enabled on an 802.1X port, the switch can authorize clients based on the client MAC address when 802.1X authentication times out while waiting for an EAPOL message exchange. After detecting a client on an 802.1X port, the switch waits for an Ethernet packet from the client. The switch sends the authentication server a RADIUS-access/request frame with a username and password based on the MAC address. If authorization succeeds, the switch grants the client access to the network. If authorization fails, the switch assigns the port to the guest VLAN if one is specified. For more information, see the"Using 802.1X Authentication with MAC Authentication Bypass" section.

For more information, see the "Configuring a Guest VLAN" section.
Using 802.1X Authentication with Restricted VLAN

You can configure a restricted VLAN (also referred to as an authentication failed VLAN) for each 802.1X port on a switch to provide limited services to clients that cannot access the guest VLAN. These clients are 802.1X-compliant and cannot access another VLAN because they fail the authentication process. A restricted VLAN allows users without valid credentials in an authentication server (typically, visitors to an enterprise) to access a limited set of services. The administrator can control the services available to the restricted VLAN.

Note You can configure a VLAN to be both the guest VLAN and the restricted VLAN if you want to provide the same services to both types of users.

Without this feature, the client attempts and fails authentication indefinitely, and the port remains in the spanning-tree blocking state. With this feature, you can configure the port to be in the restricted VLAN after a specified number of authentication attempts (the default value is 3 attempts).

The authenticator counts the failed authentication attempts for the client. When this count exceeds the configured maximum number of authentication attempts, the port moves to the restricted VLAN. The failed attempt count increments when the RADIUS server replies with either an EAP failure or an empty response without an EAP packet. When the port moves into the restricted VLAN, the failed attempt counter resets.

Users who fail authentication remain in the restricted VLAN until the next reauthentication attempt. A port in the restricted VLAN tries to reauthenticate at configured intervals (the default is 60 seconds). If reauthentication fails, the port remains in the restricted VLAN. If reauthentication is successful, the port moves either to the configured VLAN or to a VLAN sent by the RADIUS server. You can disable reauthentication. If you do this, the only way to restart the authentication process is for the port to receive a link down or EAP logoff event. We recommend that you keep reauthentication enabled if a client might connect through a hub. When a client disconnects from the hub, the port might not receive the link down or EAP logoff event.

When operating as an 802.1X restricted VLAN, a port functions in single-host mode regardless of the configured host mode of the port.

You can configure any active VLAN except an RSPAN VLAN or a voice VLAN as an 802.1X restricted VLAN. The restricted VLAN feature is not supported on trunk ports; it is supported only on access ports.

This feature works with port security. As soon as the port is authorized, a MAC address is provided to port security. If port security does not permit the MAC address or if the maximum secure address count is reached, the port becomes unauthorized and error disabled.

Other port security features such as dynamic ARP Inspection, DHCP snooping, and IP source guard can be configured independently on a restricted VLAN.

It's useful if layer 2 switches are inserted between VLANS, in a ring topology.
With the same MAC adress such a ring will not work at all, since the address table in the switches could not reach a stable state.

I don't understand why you are comparing switch-features with RouterOS ? This have no meaning whatsoever. I am certified with Extreme networks products and know everything about features on switched networks and have been teaching this for several years. You are talking Ring topology... why? The usage for RouterOS is as a ROUTER or gateway, NOT as a switch doing Mac-authentication or anything else a Switch normally handles. Routerboards and RouterOS is all based on CPU and not ASICs and configured properly it outclasses all midrange routers in the market. There's no other products in the market that reaches RouterOS to it's knees for the same price.

/Henrik

It's useful if layer 2 switches are inserted between VLANS, in a ring topology.
With the same MAC adress such a ring will not work at all, since the address table in the switches could not reach a stable state.

I don't understand why you are comparing switch-features with RouterOS ? This have no meaning whatsoever. I am certified with Extreme networks products and know everything about features on switched networks and have been teaching this for several years. You are talking Ring topology... why? The usage for RouterOS is as a ROUTER or gateway, NOT as a switch doing Mac-authentication or anything else a Switch normally handles. Routerboards and RouterOS is all based on CPU and not ASICs and configured properly it outclasses all midrange routers in the market. There's no other products in the market that reaches RouterOS to it's knees for the same price.

/Henrik

Well RouterOS does support some layer 2 protocols, such as, VLANs, 802.1d Bridging, PPPoE, etc.. So I don't think its an absurd request. It is possible to have dynamic vlan assignment via 802.1X with most layer2/3 managed switches. In todays networks with wireless and roaming devices dynamic VLAN assignment is a feature on some peoples "wish lists".

And for those WISP users out there, some, if not many use RouterOS for wireless Access Points and/or wireless bridging and offload the Layer 3 work to higher powered devices for better throughput and performance.

It's useful if layer 2 switches are inserted between VLANS, in a ring topology.
With the same MAC adress such a ring will not work at all, since the address table in the switches could not reach a stable state.

I don't understand why you are comparing switch-features with RouterOS ? This have no meaning whatsoever. I am certified with Extreme networks products and know everything about features on switched networks and have been teaching this for several years. You are talking Ring topology... why? The usage for RouterOS is as a ROUTER or gateway, NOT as a switch doing Mac-authentication or anything else a Switch normally handles. Routerboards and RouterOS is all based on CPU and not ASICs and configured properly it outclasses all midrange routers in the market. There's no other products in the market that reaches RouterOS to it's knees for the same price.

/Henrik

Well RouterOS does support some layer 2 protocols, such as, VLANs, 802.1d Bridging, PPPoE, etc.. So I don't think its an absurd request. It is possible to have dynamic vlan assignment via 802.1X with most layer2/3 managed switches. In todays networks with wireless and roaming devices dynamic VLAN assignment is a feature on some peoples "wish lists".

And for those WISP users out there, some, if not many use RouterOS for wireless Access Points and/or wireless bridging and offload the Layer 3 work to higher powered devices for better throughput and performance.

If you look at the Topic then i think this discussion is off topic now. He requested a specific switch feature that doesn't belong in a RouterOS or WISP environment. Per VLAN MAC allows for physical clients in a secure environment to connect specific MAC adresses to specific VLANs. This can be accomplished in RouterOS by using multiple SSID's on different VLAN's and of course use whatever security is appropriate. I would never allow authentication based on MAC alone in a wireless environment.'

/Henrik

My request was misunderstood, it wasn't about security at all.

Having different MAC per VLAN in the Mikrotik router will allow a networks with many VLANs to work even if some segments are inadvertently connected throught ethernet switches (or wireless links), since the same MAC ( of the router ) will apear to be conected to more than one switch port.

Hello,

I am finding a solution like this, 802.1x Authentication for wired scenary, not for wireless... In wireless is too easy and possible.

Is someone tried to do a wired secured access network? i don't like pppoe, need 802.1x ok?

Thanks a lot!

anything new regarding this topic? any feature for dynamic vlans like cisco's VMPS? or what is the solution?

workaround: http://wiki.mikrotik.com/wiki/Change_MA ... _interface

It would be useful to be able to specify different MAC addreses for every VLAN.

OR

Now even more wanted to have with CapsMan v2!

thanks.


>>>>>
Step 3 Assign vendor-specific tunnel attributes in the RADIUS server. The RADIUS server must return these attributes to the switch:

•[64] Tunnel-Type = VLAN

•[65] Tunnel-Medium-Type = 802

•[81] Tunnel-Private-Group-ID = VLAN name or VLAN ID


https://technet.microsoft.com/en-us/lib ... s.10).aspx

Why?

IMHO there are no need for that... at least in all VLAN configuration that I can imagine

I'm sorry to exhume this thread.

A reason is giving IPv4/IPv6 address via DHCP from a central server and every CPE does VLAN tagging with different VID. As different CPE has different VLAN, it is a setup like PPPoE, where every customer has a single interface, but removes the (small) overhead of the PPPoE header and also MTU issues.

To avoid a customer adds many routers, to have more IP than it should, a simple way is to limit the number of MAC address on the VLAN or on the ethernet interface of the CPE.