CentOS - Jan 2015 - VLAN issue

OK, thanks again for all your help.

I have resolved this, finally. The problem was that I configured VLAN 48 as
the native VLAN on the trunk port.That was a mistake as apparently the
native VLAN is the one where Cisco does not bother to tag packets.

For now I set the native VLAN to VLAN 1 and that works.

Cheers,

Boris.


On Sun, Jan 25, 2015 at 7:13 PM, Boris Epstein <borepstein at gmail.com>
wrote:
> And additionally here are the detailed port configs on the switch end:
>
> hq>show interface Gi1/0/3 switchport
> Name: Gi1/0/3
> Switchport: Enabled
> Administrative Mode: trunk
> Operational Mode: trunk
> Administrative Trunking Encapsulation: dot1q
> Operational Trunking Encapsulation: dot1q
> Negotiation of Trunking: On
> Access Mode VLAN: 48 (VLAN0048)
> Trunking Native Mode VLAN: 48 (VLAN0048)
> Administrative Native VLAN tagging: enabled
> Voice VLAN: none
> Administrative private-vlan host-association: none
> Administrative private-vlan mapping: none
> Administrative private-vlan trunk native VLAN: none
> Administrative private-vlan trunk Native VLAN tagging: enabled
> Administrative private-vlan trunk encapsulation: dot1q
> Administrative private-vlan trunk normal VLANs: none
> Administrative private-vlan trunk associations: none
> Administrative private-vlan trunk mappings: none
> Operational private-vlan: none
> Trunking VLANs Enabled: ALL
> Pruning VLANs Enabled: 2-1001
> Capture Mode Disabled
> Capture VLANs Allowed: ALL
>
> Protected: false
> Unknown unicast blocked: disabled
> Unknown multicast blocked: disabled
> Appliance trust: none
> hq>show interface Gi1/0/3 trunk
>
> Port        Mode             Encapsulation  Status        Native vlan
> Gi1/0/3     on               802.1q         trunking      48
>
> Port        Vlans allowed on trunk
> Gi1/0/3     1-4094
>
> Port        Vlans allowed and active in management domain
> Gi1/0/3     1-3,7,48-50
>
> Port        Vlans in spanning tree forwarding state and not pruned
> Gi1/0/3     1-3,7,48-50
> hq>
>
> Boris.
>
> On Sun, Jan 25, 2015 at 7:05 PM, Boris Epstein <borepstein at
gmail.com>
> wrote:
>
>> Thank you everyone.
>>
>> OK, the mystery deepens, I guess. The machine does need to support
>> several VLAN's, it is currently on a trunkport (8021q
encapsulated), it
>> made it into the ARP table - which I specifically tested for by
physically
>> unplugging the table, clearing the ARP table and plugging it back in.
>>
>> The ARP table currently looks like this:
>>
>> hq#show arp
>> Protocol  Address          Age (min)  Hardware Addr   Type   Interface
>> Internet  192.168.48.100          0   0025.6440.0301  ARPA   Vlan48
>> Internet  192.168.48.101          -   001b.906a.bcc4  ARPA   Vlan48
>> Internet  192.168.48.1            0   0025.6440.063f  ARPA   Vlan48
>> Internet  192.168.2.52            0   0025.6440.0547  ARPA   Vlan2
>> Internet  192.168.3.1             -   001b.906a.bcc2  ARPA   Vlan3
>> Internet  192.168.2.1             -   001b.906a.bcc1  ARPA   Vlan2
>> Internet  192.168.7.1             -   001b.906a.bcc3  ARPA   Vlan7
>> hq#
>>
>> The network config on the machine currently looks like this: it has
>> nothing assigned to eth0, eth0.48 = 192.168.48.100/24, eth0.49 >>
192.168.49.100/24, eth0.50 = 192.168.50.100/24.
>>
>> And - even though the ARP table seems to be OK - there is no
connectivity!
>>
>> Boris.
>>
>>
>>
>> On Sun, Jan 25, 2015 at 11:42 AM, Les Mikesell <lesmikesell at
gmail.com>
>> wrote:
>>
>>> On Sun, Jan 25, 2015 at 8:38 AM, Andrew Holway <andrew.holway at
gmail.com>
>>> wrote:
>>> > On 25 January 2015 at 15:12, Boris Epstein <borepstein at
gmail.com>
>>> wrote:
>>> >
>>> >> OK... but why does it need to be a trunk port?
>>> >>
>>> >
>>> > Because a trunk port will "trunk" the vlan.
>>> >
>>> > A VLAN is basically a 4 byte "tag" that gets
injected into the packet
>>> > header when the packet enters the VLAN network. When we trunk
a VLAN
>>> we say
>>> > to the switch "pass packets on VLAN x but do not strip
the tag out".
>>> >
>>> > You can either terminate the VLAN at the switch port
(untagged) which
>>> will
>>> > strip out the VLAN tag or you can pass the packet containing
the VLAN
>>> tag
>>> > to the computer or other device(tagged/trunk). This device can
then
>>> pull
>>> > out the tag. On linux this mechanism is done by an 8021q VLAN
>>> interface.
>>> >
>>> > Hope this is useful.
>>> >
>>>
>>> Just to add to that - normally if a host only needs to be on one
>>> subnet you would use an access port on the switch to select a
single
>>> vlan and deliver those packets untagged so the host does not need
to
>>> care about tags or vlan numbers.   And to that end, switches
default
>>> to treating everything as access ports on native/untagged vlan 0
>>> unless configured otherwise.   However, if the host needs
interfaces
>>> on multiple subnets, you can do it on a single network connection
by
>>> giving it a trunk connection from the switch and letting it split
out
>>> the vlan interfaces internally.
>>>
>>> --
>>>    Les Mikesell
>>>       lesmikesell at gmail.com
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS at centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>>
>>
>

On 01/25/2015 04:20 PM, Boris Epstein wrote:
> I have resolved this, finally. The problem was that I configured VLAN 48 as
> the native VLAN on the trunk port.That was a mistake as apparently the
> native VLAN is the one where Cisco does not bother to tag packets.
That's not a mistake, per se.  Having vlan 48 as the native vlan just 
means that you'd want 192.168.48.100 on eth0 instead of eth0.48.
> For now I set the native VLAN to VLAN 1 and that works.
As long as you aren't concerned about the security implications of that 
host having access to vlan 1, that seems pretty reasonable.  The system 
will get some extra broadcast traffic, but the ethernet card will 
probably filter those out so that they don't have to be processed.

Gordon, thanks!

What sort of security implications did you have in mind? Just curious.

Boris.


On Mon, Jan 26, 2015 at 3:50 PM, Gordon Messmer <gordon.messmer at
gmail.com>
wrote:
> On 01/25/2015 04:20 PM, Boris Epstein wrote:
>
>> I have resolved this, finally. The problem was that I configured VLAN
48
>> as
>> the native VLAN on the trunk port.That was a mistake as apparently the
>> native VLAN is the one where Cisco does not bother to tag packets.
>>
>
> That's not a mistake, per se.  Having vlan 48 as the native vlan just
> means that you'd want 192.168.48.100 on eth0 instead of eth0.48.
>
>  For now I set the native VLAN to VLAN 1 and that works.
>>
>
> As long as you aren't concerned about the security implications of that
> host having access to vlan 1, that seems pretty reasonable.  The system
> will get some extra broadcast traffic, but the ethernet card will probably
> filter those out so that they don't have to be processed.
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

On Mon, Jan 26, 2015 at 3:50 PM, Gordon Messmer <gordon.messmer at
gmail.com>
wrote:
> On 01/25/2015 04:20 PM, Boris Epstein wrote:
>
>> I have resolved this, finally. The problem was that I configured VLAN
48
>> as
>> the native VLAN on the trunk port.That was a mistake as apparently the
>> native VLAN is the one where Cisco does not bother to tag packets.
>>
>
> That's not a mistake, per se.  Having vlan 48 as the native vlan just
> means that you'd want 192.168.48.100 on eth0 instead of eth0.48.

+1

If it were me, I'd opt for setting the native vlan to 48 for that port.
It's simpler and avoids having vlan1 to deal with.

>
>
>  For now I set the native VLAN to VLAN 1 and that works.
>>
>
> As long as you aren't concerned about the security implications of that
> host having access to vlan 1, that seems pretty reasonable.  The system
> will get some extra broadcast traffic, but the ethernet card will probably
> filter those out so that they don't have to be processed.

Boris could just set what vlans are allowed on the trunk port to his server.
Just allow vlans 48, 49, and 50 and not others

! by default your switch trunks on vlan 1 to 4094
! now to allow it only on the three vlans you specifically specified
(48,49,50)
switchport trunk allowed vlan remove 1-47,51-4094
! if you chose to tell it not to trunk any vlans, you'd disconnect your
telnet/ssh
! session as well as cause a service outage ... so don't do that!
!
! also realize that Cisco smuggles some data via VLAN1 [0], so there still
will likely be traffic on VLAN1
!
! now that port should not be trunking on ALL vlans ... just 48,49,50
show int Gi1/0/3 switchport
show int Gi1/0/3 trunk


As far as security goes ...
Leaving vlan1 usable when it does not need to be is akin to locking most of
the doors at your home, but not all of them.

1) by default (most?) switches have all ports in vlan1 ... so somebody
plugs in a new switch and could potentially communicate with your server.
2) If someone compromises that server, now they have a trunk port to have
lots of fun with (create more vlan interfaces and sniff/spoof traffic).


[0]
https://supportforums.cisco.com/discussion/9118321/disabling-vlan1-across-trunks

-- 
---~~.~~---
Mike
//  SilverTip257  //