Hi All,

My ISP, Telus in BC, assigns static IP addresses by doing static DHCP assignments. I need to call them up, give them a MAC address, and they assign a static IP address.

I have 5 static IP Addresses. I have ONE port on the Telus CPE fiber modem (a Nokia device as it happens).

I have one IP address already assigned to the MAC address on ether1, it gets picked up by dhcp client that is running on ether1.

I want to assign the remaining 4 ip addresses, and use them for different internal networks. How should I do this? I thought using vlans, or bridges would be sufficient, but it doesn't look to be so straight forward.

What options do I have?

Thank you,

The only way of getting more than one DHCP client on one interface is using VRRP interfaces.
Add a VRRP interface to your WAN-port and add a dhcp client to this.

You'll need some unused address space on the interfaces to make VRRP work.
Like
192.168.171.2/30 on ethernet, .1/32 for vrrp1, vrid 2
192.168.171.5/30 on ethernet, -6/32 for vrrp2, vrid 5
...and so on.
This enables basic VRRP funcitionality and makes sure the interfaces become master.
Then you can add dhcp-clients to the vrrp-interfaces.

I'm not sure if your ISP will allocate those reserved (and not changeable) MAC addresses of the VRRP interfaces, but it should be worth a try.

Good luck,
-Chris

I'm not sure if your ISP will allocate those reserved (and not changeable) MAC addresses of the VRRP interfaces, but it should be worth a try.

If they don't, the next step towards madness is to use a bridge between the VRRP and the physical uplink interface and to set /interface bridge nat and /interface bridge filter rules to translate the VRRP MAC addresses to some other ones and vice versa (the bridge nat has no connection tracking so you need both src-nat and dst-nat rules as each frame is treated independently). The price to pay is the associated CPU load.

EDIT: it doesn't work this way, see further posts.

I'm not sure if your ISP will allocate those reserved (and not changeable) MAC addresses of the VRRP interfaces, but it should be worth a try.

If they don't, the next step towards madness is to use a bridge between the VRRP and the physical uplink interface and to set /interface bridge nat and /interface bridge filter rules to translate the VRRP MAC addresses to some other ones and vice versa (the bridge nat has no connection tracking so you need both src-nat and dst-nat rules as each frame is treated independently). The price to pay is the associated CPU load.

Now it's getting funky, nice idea.
Or getting a managed and an unmanaged switch between the router and CPE. Feed vlans (with ascending MAC addresses) from router to managed switch, create access ports for each vlan, connect all those to the unmanaged switch and hook up the CPE to the unmanaged too... What an effort...

If I was the ISP, I'd assign a /30 transport net by static DHCP lease and route the 6 addresses of the assigned /29 subnet over this transport...
-Chris

If I was the ISP, I'd assign a /30 transport net by static DHCP lease and route the 6 addresses of the assigned /29 subnet over this transport...

If you were an ISP, you'd at first place want to have a common solution reusable for all your clients, not tailor-made for each of them, as tailor-made solutions are a maintenance nightmare. So if they've chosen to provide public IPs using DHCP (and probably restrict their total number per physical link), it is unlikely they would change that approach. I've seen various ways the ISPs address this thanks to this forum - including assigning private IP to a customer on a PPPoE link and requesting the customer to use RIP to advertise the public subnet to the ISP via that PPPoE link. Unglaublich Leaving aside other large ISPs who require that the traffic (starting from DHCPDISCOVER) was coming to them with a specific 802.1Q priority, otherwise they assign a different bandwidth shaping policy.

Hmm, bridging VRRP interfaces with their parent interface (I hope I got it right) sounds somehow dangerous. Did you test it? I'd be affraid that it would mess up the whole thing.

But speaking about crazy ideas, I had one, inspired by loop trick. Create local EoIP tunnel, put one end in bridge with uplink and dhcp client on the other one. And I think it would work, except you can't have two EoIP tunnels with same id, so local-only link is not possible. Other possible source for extra mac address could be OpenVPN in ethernet mode (same principle as with EoIP, local clients connected to local server), but that would be beyond ridiculous, so I didn't even attempt to try that.

Only proper solution for this would be if MikroTik added virtual interfaces with own addresses. There's such thing in Linux...

Btw, old VRRP hack doesn't need so many extra addresses. In fact, it shouldn't need any, if you use VRRP in IPv6 mode, link-local addresses will do the trick.

Hmm, bridging VRRP interfaces with their parent interface (I hope I got it right) sounds somehow dangerous. Did you test it? I'd be affraid that it would mess up the whole thing.

No, you got it wrong, but my wording wasn't a prototype of clarity either "To use a bridge between the VRRP and the physical uplink interface" is actually as simple as creating a bridge, making it a carrier (parent) interface for all the vrrp ones instead of the physical uplink interface (which presumably was their carrier interface before), and then make the physical uplink interface a single slave port of that bridge.

This way it works as such but it is useless for the intended purpose because I haven't realized one thing, DHCPDISCOVER and DHCPREQUEST contain the client MAC address as a mandatory L7 field, i.e. not an Option like the client-id is, and you cannot change the contents of this field using /interface bridge nat rules nor using any other means.

So the only advantage of using the bridge is that you can prevent the VRRP multicast packets from leaking out from the 'Tik, but you stay left with just 255 MAC addresses for all clients of this type for the whole area served by the same client database at ISP side.

Regarding use of IPv6, the only advantage is that, as you wrote, you don't have to use a bunch of IPv4 addresses to be statically assigned to the individual VRRP interfaces to allow them to get up, and that you get another pool of 255 MAC addresses to use - 00:00:5E:00:02:xx is used for IPv6 VRRP.