cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4053
Views
20
Helpful
10
Replies

Subnets, VLANs & DHCP

TimOnCisco
Level 1
Level 1

Whilst preparing for the CCNA qualification I decided to create a small network project to exercise myself in ICND1 & ICND2 knowledge.

The scenario is this:

A small company consists of several departments.  The network infrastructure consists of several switches, a single router and some wireless access points.  The IT equipment consists of servers, printers, hosts and VoIP phones.

Each function and department is to be allocated a VLAN, each of which is allocated to a VLSM subnet.  The switches are to be connected with a trunk ring using Gigabit Ethernet ports with some redundancy provided by EtherChannels, which will also provide some bridging across the ring, again for redundancy.

The infrastructure will be allocated its own VLAN (let’s call it SysAdmin), which will also be designated as the native VLAN (more on this point below).  The SysAdmin VLAN will be used for administration of the infrastructure.  Printers, servers and the network infrastructure will be allocated fixed IP addresses, all other devices are to use DHCP from their own range.  Each switch is to have one port allocated to the SysAdmin VLAN.  Access control lists won’t be used, just yet.

I’ve worked out the VLSM subnetting, and created various VLANs.  What I’m not sure about is the use of the SysAdmin VLAN.  I know that I will need to assign an access port to each switch for the SysAdmin VLAN, but can I also use the same VLAN for the trunking?  For example, is the following acceptable?

interface range gigabitEthernet 1/1-2

switchport trunk native vlan SysAdminVLANID

interface fastEthernet 0/24

switchport mode access

switchport access vlan SysAdminVLANID

Also, when considering the EtherChannels being used as trunks, is it sufficient to just configure the ports as above and then create the EtherChannel, or will the following configuration be required:

interface po1

switchport trunk native vlan SysAdminVLANID

?

Regarding the DHCP, I believe that I will need to use a router-on-a-stick configuration, creating one sub-interface for each VLAN?

The router will then need a separate pool of IP addresses to be configured for each VLAN?

Routes will need to be created between the various sub-interfaces, for example, so that the servers, and printers can be accessed by anyone, whilst keeping other VLANs separate.

So, my questions:

Is this a viable scenario?

Am I heading in the right direction to solve the problem that I’ve set myself?

Have I missed something or, perhaps more appropriately, what have I missed?

When I got to the point where I was asking myself the above questions I thought that perhaps I’ve got a step too far.  However, I think that if I can work this out I will have gone through many of the aspects required and will have learnt a lot.

Thanks in advance.

1 Accepted Solution

Accepted Solutions

Kyle McKay
Level 1
Level 1

A few comments for you, beginning at the top:

1. It is bad security practice to use a user-facing VLAN as the native VLAN on any trunk. I would suggest you use the default or select a different VLAN to be used for the native VLAN. This prevents an attack known as VLAN-hopping.

2. As for the etherchannel configuration - all of the etherchannel configuration is applied to the portchannel interface and not to the physical interfaces.

Example:

interface po1

switchport mode trunk

switchport trunk encapsulation dot1q

switchport trunk native vlan X

interface Gig0/1

channel-group 1 mode active

3. You will not need to create any routes - as they will all be created automatically (all of these networks are directly connected)

You will need to create a separate DHCP pool for each VLAN, that is correct.

My question for you would be in regards to the topology. You mention a "trunk ring", what exactly do you mean by this?

HTH

Kyle

View solution in original post

10 Replies 10

Kyle McKay
Level 1
Level 1

A few comments for you, beginning at the top:

1. It is bad security practice to use a user-facing VLAN as the native VLAN on any trunk. I would suggest you use the default or select a different VLAN to be used for the native VLAN. This prevents an attack known as VLAN-hopping.

2. As for the etherchannel configuration - all of the etherchannel configuration is applied to the portchannel interface and not to the physical interfaces.

Example:

interface po1

switchport mode trunk

switchport trunk encapsulation dot1q

switchport trunk native vlan X

interface Gig0/1

channel-group 1 mode active

3. You will not need to create any routes - as they will all be created automatically (all of these networks are directly connected)

You will need to create a separate DHCP pool for each VLAN, that is correct.

My question for you would be in regards to the topology. You mention a "trunk ring", what exactly do you mean by this?

HTH

Kyle

Kyle,

Thank you very much for the quick reply.

To respond:

  1. I was aware that VLAN-hopping could be an issue but hadn’t considered it an attack (thanks for pointing that out) so I thought that as long as I made sure that all of the switches were correctly configured it wouldn’t be an issue.  I’m sure that I read somewhere that it is a good security practice to move the native traffic away from VLAN 1, which was why I chose to use another VLAN.

    I chose to use the same VLAN as the system administrators on the basis that there wouldn’t actually be much Sys Admin traffic and it would give them direct access to the native VLAN for monitoring purposes.

    I’ll create another VLAN for the native traffic, but apart from the security issues you raised, I gather that there’s no technical reason why the trunks can’t use the same VLAN as the Sys Admin users?  (I.e. someone who either isn't aware of the reasons, or ignored them, may have created a working configuration using this technique; so it's something that I should be aware can exist, even if it shouldn't be used).

  2. Re EtherChannel configuration: Thanks for that.  I gather from the order of the commands in your example that it is possible to configure the po interface before it's been created using the channel-group command?

  3. Re Routing: For some reason I thought that I would still need to tell the router that the routes exist.  [Edit] Also, if the router will automatically connect all of the VLANs/routes, how will the VLAN separation be acheived, or is that where the ACLs come in?

  4. By trunk ring, I meant that the switches, each of which only has two gigabit Ethernet ports, will be connected in a physical ring configuration (rather than a logical ring) which will be configured for the trunk data.  Additional connections across the physical ring would then be created using EtherChannel links to provide some additional redundancy.  I’ve  provided a concept diagram below.  The thick lines represent gigabit ethernet links whilst the thin parallel lines represent EtherChannel links (used to practice setting up EtherChannels as well as theoretical redundancy). 

Thanks again for your response.  If there's anything else I may not be able to respond until Monday as I have a busy weekend ahead of me.

Tim

Hi Tim,

I am glad my post was able to help you.

Yes, you can create the port-channel interface prior to assigning interfaces to it - this is very common.

VLAN's will provide separation at the layer 2 level by default. If you want to provide for layer 3 separation as well, you can utilize ACL's.

A followup on your post regarding the trunk ring. The topology you described/drew is a very inefficient and is a complex spanning-tree protocol environment. While it is certainly redundant, it is not one that I would recommend.

You would generally want to aggregate switch connections to a central point (ideally the router, however this would be difficult to do unless there are many available ports).

I would suggest the following topology to eliminate single points of failure and to provide a more efficient and less-complex STP environment.

SwitchA --> Switch X --> Router
SwitchA --> Switch Y --> Router

SwitchB --> Switch X --> Router

SwitchB --> Switch Y --> Router

SwitchC --> Switch X --> Router

SwitchC --> Switch Y --> Router

etc.

I hope this provides you with enough information.

Kyle

Kyle,

thank you for your continued feedback.

The exercise originally started off focussing exclusively on STP, which probably explains why it is so STP heavy.

I've come up with an alternative configuration, based on your advice:

I realise that this would, of course, require a router with at least six Fast Ethernet (preferably better) ports.

Regarding the original configuration.  I would not have thought that the switch processors would be particularly taxed?  Also, if RPVST were in use the convergence time wouldn't be too much of a issue?  Coupling this with the additional redundancy provided by the Ether Channels, and my instinct says that the original configuration would still be better from the point of view of providing internal connectivity to the company network - placing that higher up the requirements chain than external connectivity; 'the management' are not bothered about providing everyone with excellent access to online auctions and social networking sites, for example?

In the revised configuration, the router would be handling pretty much all traffic.  I envisaged that, for some obscure reasons, the physical locations of the users wasn't necessarily compatible with the network infrastructure (I'm probably not far from reality in my thoughts here, in that a business may put placement of the humans above the requirements of the poor network operator, i.e. "this person who requires access to that network facility will be placed in this office, whilst all of the other people who require access to the same resources, will be somewhere else..."); I expected each switch to require access to multiple VLANs, and for there to be overlap.  Example, taking the above diagram with three legs, it could be the case that VLANs 1 through 4 plus 7 are needed on all three legs, 2 through 5 on leg 2, 3 through 6 on legs 2 and 3.  In such as situation, the router would now be the focal point for all VLAN traffic and a single point of failure for the majority of the network traffic.

Putting in some additional Ether Channel links between legs 1, 2 and 3 would provide the internal redundancy, but would also reintroduce the increased complexity for the STP environment.  Would it not?

So, if there was a hardware constraint, such as the router only having two Fast Ethernet ports, a slightly altered version of my original layout would be a practical, if not ideal solution?  But the network manager should be pressing the company for the budget to purchase a more suitable router...?

I look forward to reading your comments.

Tim

Message was edited by: Tim on 31 May 2012 Reason: replace image which, for some reason went missing.

New design looks great, Tim.

It is not that the switch processor's would be taxed in any way from the original design. The primary issue is the complexity and randomness of the STP topology. Your original design was what I would call over-redundant. This is a waste of money, resources and makes the topology more difficult to troubleshoot and predict.

Even if your primary goal was to provide for supreme internal connectivity, your initial design would not provide much of a benefit over the new one. This is because, STP dictates which ports can actually be in a forwarding state - and not all of them will be, resulting in even more round-about paths in some instances. Lastly, the router will certainly be the choke point for internal connectivity in the new design, however if the correct router (or Layer 3 switch, ideally) were to be used, this would not be a problem. You are indeed correct about the single point of failure, if the router were to fail, you would lose routing and the interconnections between switches. This is why we would generally employ a high-availability solution such as an additional router running HSRP/VRRP/GLBP or a pair of stacked Layer 3 switches to combat this issue. In both designs, the router was always the focal point - without some routing mechanism, your traffic is going to go nowhere. In today's network, 99% of traffic is destined off of the local subnet, so I would not be so concerned with providing intra-VLAN bandwidth.

Any time you introduce additional redundant connections, you are adding to the STP complexity. Your best bet is a simple design utilizing port-channels (1 logical link) with no additional connections. In a perfect world you may would have 2 connections from each switch (port-channeled) to an aggregate device(s).

It is unrealistic to find a router with this many interfaces - your best bet would be a Layer 3 switch such as a 3750 or 3560. In this way, you can leverage the port density of a switch, with the routing capabilities of a router. This of course depends on other business and technical requirements you may have, as a Layer 3 switch is not always a suitable option.

Kyle

Kyle,

once again, my thanks for taking the time to provide a well-written reply.

I dabbled with the three-legged design in PT (using a 2811 router) but came up with some issues that I haven't quite figured out.  The 16 Fast Ethernet ports which can be fitted to the 2811 (using the NM-ESW-161 module) are switching and don't allow sub-interfaces to be created. The only ports which can have sub-interfaces are the two native Fast Ethernet ports.  So, that left me considering breaking the network down to two legs (and therefore going back to a more complex STP environment), or wondering how to get the router to operate in VTP Client mode (or to manually configure the VLANs on the router).

I've not done any layer three stuff with the 3560, or should I able to acheive what is needed with my current level of knowledge (or, perhaps more precisely, the level of knowledge that I should have for the CCNA)?

I've just figured out that the generic Router-PT with either the PT-Router-NM-1CFE or -1CGE expansion cards would provide at the ability to have at least six Fast Ethernet ports that can have sub-interfaces, so I think that I'll be doing some experimentation with that.

[EDIT]  Okay, so I've got the Router-PT loaded with sufficient 1CGE cards to enable me to create sub-interfaces for all of the legs.  The question now, is what IP addresses should I be assigning to them?  When I tried spare IP addresses in the native vlan range (which I reservered specifically for the network infrastructure), I'm told that "% 172.24.2.64 overlaps with GigabitEthernet0/0.99".  Where, Gi 0/0.99 was the first port I assigned an IP address to.  (I'm now trying to assign IP addresses to 1/0.99, 2/0.99, 3/0.99 etc...)

I think that the question that I should be asking at this point is, "how do I assign suitable IP addresses to the different sub-interfaces for each of the VLANs, considering that each VLAN needs to be represented on multiple ports at the router end? (whilst keeping the IP addresses within the range assigned to that VLAN.)"

As I said at the start of this, I'm working towards the CCNA and I think that we may now be drifting away from the knowledge required (and that which I am able to practise)?  That said, it would be nice to understand how this all works, and to get it working in PT, if that is possible.

Thanks againg for your help.

Tim

Message was edited by: Tim on 2012-05-30 @ 17:45 BST Added detail about testing with the Router-PT

Hi Tim,

The answer to the question regarding the subinterfaces on the NM-ESW-161 module is beyond what the CCNA cover. The answer is layer 3 interfaces (SVI). You can create a logical interface that is associated with the layer 2 VLAN that is reachable on any of the 16 fast ethernet ports. You can read up on them more if you are interested, but as I said - they are beyond what a CCNA candidate would know.

For example on your router you would create a logical VLAN interface to be associated with each VLAN.. Such as:

interface VLAN 10

ip address 10.10.10.1 255.255.255.0

no shut

interface VLAN 20

ip address 10.10.20.1 255.255.255.0

no shut

These two logical interfaces are not bound to any specific physical interface, they can be reached via any of the 16 fast ethernet ports as long as those ports are configured to utilize that VLAN. (Trunk or access)

I know this will probably stir up more questions than answers, but it is the answer.

Kyle

Kyle,

Thank you for your patience.

I tried creating VLANs on the 2811 with the 16 switching ports, and it told me in no uncertain terms that wasn't going to happen.  Is this a PT or some other restriction?

So, returning to the generic Router-PT with sufficent Fast/Gigabit Ethernet expansion cards to enable multiple sub-interfaces to be created.  As I noted in my edit above, the router won't permit an interface to have IP address which is in a range/subnet that another interface already has an IP address in.

I've tried reasoning through why the router should or shouldn't allow itself to have multiple interfaces in the same network/subnet, but just keep confusing myself.  For the "shouldn't" argument, is that the IP configuration of the hosts will only have one default-router IP per subnet.  In the three-legged scenario this would mean that two of the three legs won't have a direct connection to a router port which has been assigned the default-router IP address, only a routed one.  But should this matter? The switches which are only operating at layer 2 don't care about the IP address, which is layer 3, so the packets should end up at the router anyway, which, if correctly configured and routing is operating, should send the packet to the correct destination.  I note at this point, that the switches on each of the three legs will have different default-gateway IP addresses, i.e. one of the two IP addresses available in that leg, rather than having the same default-gateway IP across all three of the legs.

So that leaves me wondering how (or even if) a router can have two (or more) interfaces which connect to the same subnet.  Given that your intial sugestion for a solution was to place a router in the middle like this, I have to believe that it is possible to achieve the desired outcome, but I just can't see it right now.

What am I missing?  (Apologies for the massively open-ended question.  It may be an indication that I'm either tiring or getting too far out of my depth. )

Tim

Hi Tim,

The answer to your first question is due to the fundamental concepts of the router. If a router has multiple interfaces in a single submet/network, where does it route packets destined for that network, to ? All of them? 1 of them? A router interface acts as a broadcast domain, and does not forward broadcasts by default.

If user "A", connects to interface Fa0/0.10 on subnet 10.10.10.5/24 and tries to PING user "B" who is connected on Fa0/1.10 on subnet 10.10.10.6/24. What happens?

At first glance, everything looks like it should work without any issue.. But if you were to look down at the lower layers of the OSI model (2) you will see that the communication will break at the ARP stage. User "A" will ARP to find the MAC address of User "B" (ARP is a broadcast, as we know) and this will fail. The broadcast will make it to the router interface and that would be the end of it - there would be no possibility for communication at any level.

Your solution to this problem is either:

1. Use a L3 switch instead

2. Use different VLAN/Subnet on each leg (this is what I would do)

3. It looks as though PT isn't allowing you to really utilize the switching module of the 2811, however if you could it would allow you to configure it as we discussed earlier in the post.

Kyle,

Thank you for what I think will be the final part of this thread.  I can see that requiring multiple additional subnets/VLANs could present some additional work/nightmares. To start with, more IP addresses will be required for the infrastructure, and if there is a limited supply of IP addresses this could become an issue.  I realise that a potential solution for this could to use NAT.  As well as that, I think that there would be additional work required with regards to ACLs.

To finish off, a final thank you for your help and patience .

I'm going to mark your first answer as the 'correct' one; although we didn't really get to a conclusion until now I think none of the later responses provide such complete coverage of the original question.

Tim

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco