keithu

Little Snitch https://www.obdev.at/products/littlesnitch/index.html is good for finding out what your Macs are up to. The demo mode should be sufficient for what you want to do.

You really need to use an absolute path when referencing your script as there is no guarantee that .folder/script.sh will be on the PATH. Like this: 0 */1 * * * /path/to/my/folder/script.sh However, as CentOS already has cron.hourly already set up you might as well use that. What I generally do is keep all my scripts in a directory called /etc/scripts and then symlink them into the appropriate cron directory. ln -s /etc/scripts/script.sh /etc/cron/cron.hourly/script.sh

I'm not familiar with Ruckus but as long as you are getting authenticated and the SSID is associated with VLAN 50 I would have thought it should work. Maybe try clearing and reloading the configuration on the AP in case it has got messed up?

Your laptop needs to be plugged into an untagged vlan 50 port for testing. If you get a DHCP address from your new range you'll know the problem is on the WiFi side.

I have not assumed that there is a router other than the LA (gateway) router. If there was already a second router under the control of the OP with all traffic forwarded to it, obviously there would be no issue. @MM1 - there is a definitive answer to your question (several in fact) but we need to know whether you already have a router of your own on the network. If you describe what you've got and how it's configured we will be able to help.

I'm sorry you feel that way. I'm not interested in a demo because I want to understand how things work. I've tried to express precisely why I think there is a problem and I don't think you've addressed that.

It won't receive the packet because it won't be sent in the first place. The LA Router will see that the destination host (PC) is supposed to be on the directly connected segment so will arp for the mac address of the host. This will fail. You seem to assume that the LA router will forward the packet to the IP address of the L3 Switch's interface for onward routing, but why would it? It's not in the routing table.

The Core switch will pick what up? And how will it reach the core switch? BTW I haven't merged anything. I don't even mention the core switch because it's not relevant. Thank you for sticking with this; I do appreciate it.

Many thanks for this If all traffic is forwarded to the customer's own L3 switch/router I agree that they can subnet and route however they like. I'm not sure that's the setup here though, which is why I introduced a model network to talk about. In the model network there is no route to a customer router but people are still arguing that they can introduce one and traffic will be 'magically' routed to it.

I'm not trying to be rude either, but you haven't explained anything. You've simply made statements. Saying things like The router will literally move traffic to the next layer 3 device is just hand waving. Please look back at my message #20. I have tried to be very thorough and explain exactly what I think will happen, packet by packet. Please tell me exactly where my logic is wrong and what would really happen - in detail.

If it doesn't know it exists how can it forward traffic to it? Exactly. But it doesn't know we've changed anything on the network so why is it suddenly going to start routing packets via a router it doesn't know about to a host it thinks is on the same subnet and thus doesn't need routing?

I don't need a demo thanks, just an explanation. Just answer this: In the first part of my scenario there is just the ISP's router on the LAN. In the second part of the scenario we introduce another router by enabling L3 routing on the switch. How do you suppose the ISP's router knows there is now a second router on the LAN?

Since I seem to have killed the thread, I'll answer my own question The router will consult its routing table and discover that 192.168.1.42 is part of the 192.168.0.0/22 subnet which is directly connected to its LAN interface. That means it can send a packet directly to the PC once it has found its MAC address. It will broadcast an ARP request for 192.168.1.42 on the directly attached LAN segment in order to discover PC's MAC address. The PC will not receive the broadcast because it's no longer on that LAN segment so it will not reply. The router will wait for the ARP reply but won't receive it. The router will give up and discard the packet. That's what I think will happen. As I seem to be in a minority of one I'd be interested to hear where you think I've gone wrong.

ok, let's look at a concrete example then: ISP is routing 192.168.0.0/22 ISP router is at 192.168.0.1 Our L3 switch is at 192.168.0.2 PC is at 192.168.1.42 Router send a packet to PC - no problem. Now we define a VLAN on a spare switch port and update the switches routing table to route 192.168.1.0/24 via that interface. We plug PC into the newly configured port. Router sends a packet to PC (192.168.1.42). What do you think will happen?

I may be misunderstanding what you get with Schools Broadband. In your example then, don't they provide you with an on-premises router sitting at 192.168.0.1 (for sake of argument)? If so, what address would the switch interface be on (hypothetically)?

My question is HOW does it know? (And just to clarify, I'm talking about the /24 subnets in the original question.)

I don't know anything about Schools Broadband but this sounds over complicated. They don't just provide you with an interface on the 10.x.x.x/20 subnet then?

So how will the router know that hosts in the new subnets are on the other side of the routing switch?

I don't understand why you think IIS is required. Presumably your existing installation of moodle works, so you must have a web server running on your windows box even if it isn't IIS. I would guess that Bitnami installs the WAMP stack so the web server is Apache. Changing to a different web server won't make your Moodle any more accessible to the outside world; you need to configure your firewall/router so that requests from outside are directed to your Moodle server.

What is stopping you from sharing your current installation externally?

You can reset the password by pressing the 'Clear' button on the front panel.

Some Netgear switches have a feature called DHCP Snooping that blocks 'rogue' DHCP servers. I'm sure it's configurable, but I couldn't tell you exactly how.

I use the previous version of the Fujitsu ScanSnap (the s500?) at home. It's fantastic! Having the sheet feeder is way more convenient and far faster that a flat-bed. The only downside is that you can only scan separate sheets, not books, pamphlets etc (unless you cut them up) so that might be a consideration. Let me know if you have any specific questions about it. ETA: Didn't realise the Epson had a sheet feeder. The Fujitsu's paper handling is really good and has an ultrasonic sensor to detect double-feeds etc. I don't know how the Epson would compare.

Could your Science teachers be running the script with elevated permissions? If the script detects that it's elevated it schedules a second copy of itself with non-elevated permissions but doesn't hide the console window by default. You can hide the console with the following setting: $showElevatedConsole = $False

Hi As long as each VLAN is configured with its correct IP address and routing is enabled on the switch it should work fine. There is potentially a subtle problem with the way you have connected the switch and the router though. Switches learn where other network devices are by keeping a record of their mac addresses in an internal table (the Forwarding Databse). The HP switch is pretty clever and keeps a database for each VLAN but it's quite possible that the router only has a single database. In this case the router would get very confused as it would appear that the HP switch is continually moving from one port to the other as it sees packets with the same mac address arrive from both ports. This is bad news as packets arriving on what it thinks is the 'wrong' port will be dropped, which leads to intermittent connections and a lot of head scratching. You can get around this problem by using a single connection between your router and switch. You will have to ask your service provider to route both subnets to the same port (with VLAN tags if you like).