<html><head></head><body>I just have 25 devices that all have the same IO and 25 vlans to segregate with. Routing is confusing but the ip list is easy<br><br><div class="gmail_quote">On April 17, 2019 11:47:43 AM EDT, Phil Turmel via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">A trunk port w/ tagged VLANs for your router and DHCP server is all you <br>need. These devices are then virtually multihomed (in addition to your <br>router's uplink).<br><br>You router will bounce traffic among your local VLANs to the extent you <br>wish to allow it.<br><br>On 4/17/19 10:56 AM, Alex Carver via Ale wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">The plan was always to use managed switches to isolate the VLANs (I<br>already have them) but I was mainly trying to sort out the missing<br>links. I only have one DHCP server but it's not at the router, it's a<br>separate machine that also handles DNS. Similarly the logging server<br>with the big drive is also independent of the router. Currently the<br>router is a small computer with a pair of USB NICs though I could be<br>convinced to replace it with something like a Ubiquiti EdgeRouter if<br>that was part of the solution.<br><br>The things that complicated the layout were the fact that sometimes some<br>devices need to talk to others. For example, the phones and other VoIP<br>devices have web management interfaces so I have to be able to reach<br>them from one of my desktop machines. The desktop machines live on one<br>VLAN and the phones another. The same thing happens to the cameras<br>where I need to access their video feeds or their web interfaces<br> from a desktop computer. At the same time I wouldn't want the cameras<br>being able to initiate a connection to a device outside of the VLAN.<br><br>One thing I wasn't sure about is whether some of these devices were<br>going to need to be multihomed with multiple IPs hanging off trunk ports<br>on the switches or if I could do something smarter than that.<br>Multihoming some of the devices would be hard to do. One example are<br>the cell phones which I do use to view the cameras, visit internal<br>server pages, and also a VoIP softphone when I'm on WiFi to link with<br>the rest of the VoIP system. When I'm out and about the VPN server has<br>to handle that and making that multihomed is probably an exercise in<br>drinking.<br><br>The guest network and IoT network were actually the only straightforward<br>parst of this mess. Each was going to be isolated from the other and<br>neither was going to be able to communicate with the other VLANs (the<br>IoT network is specifically for devices like the TV that would need a<br>connection out to video services but I don't need to talk to the TV<br>myself). It's all my other stuff that's harder simply because I have<br>these cross-over cases.<br><br><br>On 2019-04-17 06:19, Derek Atkins wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> I don't see why you can't do both? Assign each VLAN its own /24.<br><br> You will need to *route* between the different VLANs.<br><br> Some hosts may be able to be on multiple VLANs simultaneously by putting<br> it on a physical trunk link (don't assign a VLAN at the switch) and then<br> assigning the VLANs in software on the port in question (e.g. ifconfig<br> eth0.69). This would allow your syslog, DHCP, etc servers to talk to<br> all hosts on all VLANs.<br><br> I'll note that if you use multiple /24s but share a physical LAN you<br> STILL have some potential for cross-talk. For example, a host can put<br> itself onto any VLAN it sees, whereas if you do port-based VLAN then the<br> switch will prevent cross-talk! This might be important for certain<br> applications, like IoT, phone, etc.<br><br> Of course, things get more complicated if you have a VM solution where<br> different VM guests need to be on different VLANs. ;)<br><br> For the record, I was planning to use VLANs in my new home build-out.<br> Specifically I was planning to have an IP Camera VLAN, a Guest VLAN, an<br> IoT VLAN, and an in-house VLAN. I was debating also a Server VLAN (I do<br> run an oVirt cluster and have a routable Class-C Network), and maybe a<br> Phone VLAN (although I only have 2 phones, so not a big deal).<br><br> I'm still a good 6 months out from this deployment, so I have some time<br> to plan it all out.<br><br> -derek<br><br> Jim Kinney via Ale <ale@ale.org> writes:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> So you have a manageable switch that does vlans. Ports are assigned to<br> specific vlans ids. To bridge vlans requires either vlan combination at a port<br> or an external device like a multi homed server.<br><br> For small locations like homes with under 20k devices, it's easier to use<br> literal private networks. Guest network is one class C, phones get another,<br> iot another, etc. Use the dhcp server as the bridge/firewall/router between<br> all. Assign fixed IPs by mac in the dhcp for servers, printers, and such, and<br> dynamic for everything else based on which nic port the request arrives on at<br> the dhcp server.<br><br> On April 16, 2019 11:47:28 PM EDT, Alex Carver via Ale <ale@ale.org> wrote:<br><br> I'm playing around with the idea of splitting a few things at home into<br> VLANs. This would include one VLAN for phones, another for the general<br> computers, a third for IoT devices, a guest network, and one for the<br> video cameras.<br> <br> The problem I'm trying to figure out is how to set things up so that the<br> devices with configurable syslogs (in this case phones, computers,<br> cameras) send their logs to my central logging server, allow the devices<br> to pick up their DHCP leases from the central DHCP server, and still<br> have the ability to reach the admin consoles for things like the phones<br> and cameras.<hr> Ale mailing list<br> Ale@ale.org<br> <a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br> See JOBS, ANNOUNCE and SCHOOLS lists at<br> <a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br><br> --<br> Sent from my Android device with K-9 Mail. All tyopes are thumb related and<br> reflect authenticity.<hr> Ale mailing list<br> Ale@ale.org<br> <a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br> See JOBS, ANNOUNCE and SCHOOLS lists at<br> <a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br><br></blockquote><br></blockquote><hr>Ale mailing list<br>Ale@ale.org<br><a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS lists at<br><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br><br></blockquote><hr>Ale mailing list<br>Ale@ale.org<br><a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS lists at<br><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br></pre></blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.</body></html>