[ale] VLANs and logging

Alex Carver agcarver+ale at acarver.net
Wed Apr 17 14:54:16 EDT 2019


Looks like I may have to just gather some hardware and experiment with
it to get a configuration that works.  The router will have to do some
heavy lifting to get this sorted.

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


More information about the Ale mailing list