Hi all firstly I know this question is a little odd however this is the situation I can't change.

We have a multi Vlan portable network for entertainment events (festivals and shows).
We have a series of devices and guest devices that arrive on a daily basis and are given a dedicated Vlan for the day. We then have floating equipment that we move to their Vlan for the day.

I'd like to be able to add the fixed devices to the Dude and then monitor their status. The catch is they move between Vlans.
For this job I've hot a router board hexs with dude running.
It's running a dedicated DHCP for each Vlan. So we can prove connection to correct vlan as necessary.
Hose equipment lands on 10.168.1.x/24 or 10.168.2.x/24
However most guest devices set manual Ip's on their Vlan.
We set manual Ip's for the shared device pool.
Devices tilicaly set ip's to 192.168.x.x or 10.x.x.x or sometimes 2.x.x.x
Is there a way to configure the router to monitor any device ip on any Vlan?
Please go easy on responses in new to routerOs
M

You could run a discovery for the given subnets.
But that is a one-time run, either you repeat it every now and then or look for some other solution (NetXMS could deliver what you're looking for as it constantly scans the newtorks).
-Chris

Thanks Chris.

Discovery of items I don't think is my issue. Most ips are known. The problem is my ip attached to each vlan.

Lighting desk ip 10.0.0.1

Vlan 1 interface/gateway ip 10.0 0.254/24
Vlan 2 interface/gateway ip 10.0.1.254/24

If the desk is attached to Vlan 1 I can see it on the dude if it's moved to vlan 2 for a guest to use in their network I can not see it in the dude and loose ping ets.

My dude server is running on my routeros hexs. I can only give one vlan a /8 bit address on 10.0.0.0


Also I can't probe the SNMP on the routeros from the dude running on that router. But I think that's another issue.

M

Typically, if you move the equipment to a specific vlan it needs to be addressed appropriately as a vlan usually represents a specific subnet. Why do you have to move the equipment to the daily visitor vlan? Can't you leave as-is and route to it? If you have DHCP for each vlan, proper default GW and static route entries could ease in the routing to the 'permanent/shared' equipment. You could limit access to other equipment via firewall on non-visitor vlans. It almost sounds like you have three separate zones:

1. Visitor vlan for the day
2. DMZ with shared equipment
3. Other vlans / infrastructure / devices

>>However most guest devices set manual Ip's on their Vlan. We set manual Ip's for the shared device pool

I assume that you have some control over the subnet addressing involved - I think you would have to or your shared equipment would not communicate to the visitor devices.

If you don't want to route, another option would be to have the shared devices as part of multiple networks at the same time. Modern PCs can have multiple NICs each with a different address (prefer a DMZ concept, but this is still common to be multi-homed). Even with a single NIC, many OSs allow multiple addresses. Most can handle some form of vlan support as well, so I guess the point is the shared equipment may not have to leave the managed vlan but instead would be part of two vlans at the same time. For devices that can't support this advanced networking natively (say an embedded device or one which you don't have control over like a purchased product) I wonder if a small Tik router with some NAT/port forward behavior could handle the job.

>> this is the situation I can't change.

I think something has to change... at the very least configuration if not a new architecture or additional hardware. Another option is just don't use vlans that provide for segmentation but only you can decide if the benefits of segmentation outweigh the need to manage the equipment via snmp.

Thanks for the help.
Sadly my issue is the lack of knolage from the incoming guest network and device kit.
And its my job to make it work what ever they have done without touching their kit unless its 100% necessary.

Hopefully I'll continue my fight and get the level of education raised and this will then disappear.

Our designed networks now follow a correct architecture. However the need to merge with incoming systems presents this issue.

I'll keep playing there will be a suitable solution. Maybe I can just monitor switch ports via SNMP for now and not do device level monitoring apart from my network.

Thanks anyway

I get your points and understand your problems - i am in the events industry as well and know the woes with guest productions sharing consoles :-)
A possible solution could be HotSpot with IP-binding aka one-to-one-NAT aka "Universal client" - you can translate literally any IP address to a valid address, making it reachable for you no matter which network it is connected to...
Have a look at the HotSpot IP Binding Manual.

That might be shooting sparrows with cannons but could probably help.

-Chris

Just putting this out there without any real knowledge of RouterOS, just a bit of experimentation a while ago. I assume that the devices that move between VLANs will still have the same MAC and will be contactable by your router, so the router will have an arp entry for these devices. Can you put a script on the router that will run periodically and extract the current IP for those mobile MACs and update Dude's database to the current IP? Updating Dude database might be a bit of a challenge, so alternatively use the NAT suggested by @cdiedrich and update the router NAT rules based on the newly discovered addresses???

After thinking about this topic for a while, this might be a (part of a) solution:
You say that you want to monitor your resident devices that might be shuffled around vlans, but do get an address in the vlan they've been moved to.
And I read that the dude is running on the same machine as the dhcp server is. So the mac addresses are already known on your router.
And you surely know the mac addresses of your resident devices.

Try setting the mac-lookup of your devices from ip-to-mac to mac-to-ip. Now it should query your router's arp table to find the correct IP address assigned to this mac address and in an ideal world, it'll dynamically change the IP address of the device to be monitored to the current IP it has.

I have never tried that but reading the Dude's documentation makes me think this is the way it is supposed to work.

-Chris