cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1899
Views
35
Helpful
20
Replies

Way to forward DHCP requests w/o an 'ip helper-address'?

Hello,

About 18 months ago, we stopped using VTP and switched to assigning 'allowed VLAN' to individual interfaces.  Everything has been working well.  At that time, the contractor had me turn off VTP on the core switch (default gateway) and leave VTP in transparent mode on the access and distribution switches.  He said going forward, we could stop creating VLAN interfaces and simply just create named VLANs.  More recently, perhaps when a client lease expires, a DHCP client will not obtain an ip address in a timely manner, if at all.  I suspect this might be due to the lack of an 'ip helper-address' on a VLAN interface.  Is that likely?  Is the configuration okay as described?  And how can I help clients reach the DHCP server?  

Perhaps this clarifies my question:  We were trying to reduce traffic in an OT environment but appear to lose DHCP acknowledgements periodically.  Can create a VLAN interface and still isolate traffic using 'allowed vlan'?

P.S.  The DHCP server is connected to the core stack of switches.

1 Accepted Solution

Accepted Solutions


haggittmark@tm-america.com wrote:
I believe you have shed some light on my mis-thinking.  Here are my questions:

1. Will creating an SVI create an entry in the VLAN database, and is the VLAN database part of VTP?


No, it will not. In SOME versions of IOS, entering the command 'switchport access vlan XXX' on an interface WILL create an entry in vlan.dat. I don't know which versions, but it is probably most of the more modern versions. I never count on that,


haggittmark@tm-america.com wrote:

2. VTP in transparent mode will not necessarily negate the isolation created by using 'allowed vlan' on individual port interfaces? 


If you don't specify allowed vlan's on a  trunk port (I believe this command is only really relevant in the context of a trunk port), it will allow all KNOWN vlan's. I THINK VTP transparent mode will allow unknown vlan's to pass, but I am not positive of that. I prefer VTP, so I rarely use transparent mode.

<Just My Opinion>

I have heard and understand the reservations some people have regarding VTP. That said, I find the potential security ramifications of malicious actions using VTP to be less than the administrative hassle of having to touch multiple switches and the potential for missing some switches causing hard to troubleshoot issues. Somebody has to have physical access to your cable plant to try any of the VTP attacks or denials of service. If they have physical access to your cable plant, VTP is the least of your worries. My personal best practice is to pick one switch to use as a server, and make the VLAN changes there. You can have more than 1 server or promote a client to being a server if the server fails. I also prefer to use a password on VTP. That isn't so much security as to address misconfiguration issues. An out of the box switch is a VTP server. You could overwrite you network VLAN database if the configuration revision is higher when you bring in the new switch.

</Just My Opinion>

 

View solution in original post

20 Replies 20

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

In order for a client to pick up an IP address from DHCP, there needs to be a helper address configured on the SVI (layer-3 vlan interface). Also, can the clients reach the gateway IP?

HTH

 

The clients can reach the gateway.  So, the only way to forward DHCP requests is to use VTP?

ip helper has nothing to do with VTP. VTP or not has to do with how you distribute VLAN definitions. If you try to use an "interface Vlan XXX" and it isn't in the VLAN database, it won't work. If the VLAN reaches the switch's "interface Vlan XXX", you have to apply the appropriate "ip helper-address" and have IP reachability to the DHCP server for that to work.

I believe you have shed some light on my mis-thinking.  Here are my questions:

1. Will creating an SVI create an entry in the VLAN database, and is the VLAN database part of VTP?
2. VTP in transparent mode will not necessarily negate the isolation created by using 'allowed vlan' on individual port interfaces? 

I find the points made about VTP a bit puzzling, especially in the context of a question about DHCP. As Elliot has pointed out VTP is about how you distribute information about layer 2 vlans. It has no relationship to anything about DHCP. And I do not understand the comments about allowed vlan vs VTP. But since neither of them has any relationship to anything about DHCP I am not going to worry about them.

The title of the post asks about forwarding DHCP requests without a helper address. I agree with Reza that if the client is in a subnet/vlan that is remote from the DHCP server then the only way to forward those requests is to use helper-address.

The original post asks "when a client lease expires, a DHCP client will not obtain an ip address in a timely manner, if at all". It would be helpful to clarify whether in these cases the client is in the same subnet as the server or is in a remote subnet. But in either case if the client did receive an IP address from the server then the question becomes whether there was some condition in the network that interfered with communication between the client and the DHCP server.

HTH

Rick

Yes, clients are on various subnets.

I was thinking 'ip helper-address' is associated with VTP because it is applied to VLAN interfaces.  This may have been incorrect.  I want to use an 'ip helper-address' to pass DHCP traffic, yet at the same time, I do not want traffic from unnecessary VLANs to be visible to every device on a given switch.  I was given the impression from a consultant that using VTP in server mode would make all traffic visible on a switch in VTP client mode.  We had some OT devices that were not communicating because of excess IT (office) traffic. 


haggittmark@tm-america.com wrote:
I believe you have shed some light on my mis-thinking.  Here are my questions:

1. Will creating an SVI create an entry in the VLAN database, and is the VLAN database part of VTP?


No, it will not. In SOME versions of IOS, entering the command 'switchport access vlan XXX' on an interface WILL create an entry in vlan.dat. I don't know which versions, but it is probably most of the more modern versions. I never count on that,


haggittmark@tm-america.com wrote:

2. VTP in transparent mode will not necessarily negate the isolation created by using 'allowed vlan' on individual port interfaces? 


If you don't specify allowed vlan's on a  trunk port (I believe this command is only really relevant in the context of a trunk port), it will allow all KNOWN vlan's. I THINK VTP transparent mode will allow unknown vlan's to pass, but I am not positive of that. I prefer VTP, so I rarely use transparent mode.

<Just My Opinion>

I have heard and understand the reservations some people have regarding VTP. That said, I find the potential security ramifications of malicious actions using VTP to be less than the administrative hassle of having to touch multiple switches and the potential for missing some switches causing hard to troubleshoot issues. Somebody has to have physical access to your cable plant to try any of the VTP attacks or denials of service. If they have physical access to your cable plant, VTP is the least of your worries. My personal best practice is to pick one switch to use as a server, and make the VLAN changes there. You can have more than 1 server or promote a client to being a server if the server fails. I also prefer to use a password on VTP. That isn't so much security as to address misconfiguration issues. An out of the box switch is a VTP server. You could overwrite you network VLAN database if the configuration revision is higher when you bring in the new switch.

</Just My Opinion>

 

In yhe past, the concern was less about security and more about congestion.  

We do not want traffic from unnecessary VLANs to be visible to every device on a given switch.  I was given the impression from a consultant that using VTP in server mode would make all traffic visible on a switch in VTP client mode.  We had some OT devices that were not communicating because of excess IT (office) traffic. 

"We do not want traffic from unnecessary VLANs to be visible to every device on a given switch."

Not a bad goal, although I wondering whether you might be a bit confused about VLAN operations.

"I was given the impression from a consultant that using VTP in server mode would make all traffic visible on a switch in VTP client mode."

"All traffic", generally not!  With or without VTP, which BTW, in VTP versions 1 and 2, the only real difference between "server" mode and "client" mode, the former allows VLAN database configuration changes, the latter does not, but both work alike as to sharing their VLAN database.

Anyway, on the subject of "all", in a switched environment, for unicast traffic, and multicast traffic with IGMP snooping, only unknown destination traffic flows throughout the VLAN.  When you block a VLAN on a trunk, what you're normally blocking is broadcast traffic, and reducing the STP topology size of the VLAN (since Cisco supports per-VLAN STP).  The last two benefits of blocking VLANs on trunks, again, is worthwhile in their own rights, but on a "modern" switched networks, your topology must be "interesting" if by not blocking some VLANs on trunks causes performance problems.  Your inter-switch VLAN links, before your "improvements", were showing excessive interface drops due to congestion?

Also BTW, do you follow best practices concerning how you handle VLAN 1 and switch management IPs?

I did see your comments in this thread about your new thread, and saw the posts there too, but I believe we're trying to troubleshoot without sufficient information.

I would recommend either providing much more comprehensive information, like your current network topology and detailed information on all network devices in operation (e.g. specific model, IOS version, current configuration) or you might consider retaining another network consultant to review you network as your problems started (?) after making changes recommended by your current consultant and/or what you're telling us your consultant is telling you seems somewhat "lacking" in understanding (although that might just be your misunderstanding of what your being told and how your retell it).

Just as an aside, if you do shop for another/extra network engineer consultant, I will say, I don't recall ever having an issue working with a CCIE as all I've worked with are truly knowledgeable network engineers.  That's not to say, I have not found knowledgeable network engineers without having a CCIE, just finding such seems hit-or-miss.  So, possibly something to keep in mind.  (Oh, also, a network engineer recommended by a CCIE, is likely also "good".)

 

Before the 'improvements' we were informed by a contractor installing an OT network for engineering that our network was creating too much traffic and causing miscommunication on the OT network.  So, we hired a company to come in and troubleshoot our IT network.  This company said the network was 'reasonable and typical' with no major loops and offered several suggestions on how we could reduce overall traffic (assigning static addresses to reduce DHCP chatter, various snooping protocols, turning off CDP, and so on).  With minimal gain, we hired another company to help segregate traffic by pruning VLANS manually from each switch.  With added minimal gain, we are hoping to get the funds to segregate OT from IT using firewalls, policies, and remote access servers.  We have also learned of some minor issues on the OT side such as memory leaks, 10MB PLCs, broadcast storms, etc.  

As far as VLAN1 best practices, i try to disable VLAN1 and use a different name/number.  I feel like there might be more practices i am not yet away of.

I agree, I think there are some key misunderstandings on my behalf.

Unfortunately, I am not at liberty to share detailed information.  

Again, perhaps I'm being too critical of what you're describing your network consultants have recommended, as it's second hand, but, for example, "assigning static addresses to reduce DHCP chatter" sounds very, very odd.  Why?  Well unless you're using something like a 1 minute DHCP lease, often DHCP renewal might be set to happen only once or twice a day!  I.e. generally "DHCP chatter" doesn't contribute to overloading a network with traffic.

Also on the subject of DHCP, your OP starts with an issue of DHCP not working consistently well, yet now you describe replacing its usage with static addressing.  I.e. was this to try to avoid your DHCP issues, cut down on DHCP "chatter", or both?

Regarding  "turning off CDP"; CDP certainly might generate more "chatter" than DHCP, but it's per port, and not flooded throughout a VLAN or to instances to every VLAN.  I.e. even if your ports are running, say 10/half, CDP bandwidth usage is generally small/light.

BTW, for a shared IT and OT network, if IT traffic bursts are causing OT network issues, I would think, if you're not already doing so, QoS might be a better approach.

If you're unable to "share" detailed information, due to security concerns (?), you might want to the review the weakness of a security by obfuscation (which is not the same as holding secure things like your passwords - or as we might say, providing a sanitized version of your configs).

DHCP Server are connect to One dis SW?
are you running HSRP ?
check the HSRP status is it active or standby ?

The DHCP server is connected to the core stack of switches.  We don't have an HSRP that I know of.  I will confirm.

Joseph W. Doherty
Hall of Fame
Hall of Fame

Are you using VTP pruning?

BTW, sort of unclear why a contractor suggested keeping VTP active on your core switch, but going to transparent on (all?) distribution and access switches.  Reason that's unclear, if VTP only active on core, why use VTP at all, as it doesn't redistribute VLANs to any distribution or access switch, correct?  (Also unless there's a VTP using device on both sides of a transparent device, also unclear why not just configure VTP in off mode [assuming device supports "off" mode].)

Also BTW, yes, there are a couple of ways to get to DHCP server w/o using a the normal helper IP approach, but I wouldn't recommend them.  For example, if your DHCP server is setup as a host on all the VLAN/networks it supported, no need for an IP helper-address.

Lastly, from your description of the issue, I would suspect a possible misunderstanding how your network should be configured.  However, as you haven't mentioned actual devices and their IOS versions, it's also possible you might be bumping into a "software defect".  Yet, I think the former is more likely as IP helper-address for DHCP relay is such a commonly used function, you're a bit less likely to find a bug in it.

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: