I have the following configuration:
I would like to provide every host from VLAN_101 with DHCP-provided IP addresses. There are two DHCP servers running – one grants adresses for every host below switch LAN_1 and the other one – below LAN_2.
What can I do, except from turning one DHCP server off, to make hosts in VLAN_101 be in a single subnet?
Is this manner correct? If not, what should I change to make it genuine? Any advices are welcome.
Switch – GNS3 – configure two DHCP servers within one VLAN
dhcpgns3switchvlanvpc
Related Solutions
Basics
When you tag a VLAN on a port, it will send out the traffic on that port with the VLAN tag, when the port receives traffic it looks for the tag and places the traffic into that VLAN. You can have multiple tagged VLANs on one port (sometimes called trunk).
When you send out a VLAN untagged on a port it will not add the VLAN tag to the packet and when receiving packets without a VLAN tag it will be placed into that VLAN (on Netgear and others you have to set PVID (Primary VLAN ID))
To your problem
I think you are not far away... - Router port connected to Switch1 should have IP within VLAN 2220. - DHCP Server should have different IP from different Subnet! - Router port Connected to Switch2 should have IP in Subnet of DHCP Server - You should define a DHCP Helper on Router port connected to Switch1 so DHCP Request get forwarded to DHCP Server. Hot to do that is described here: http://kb.netgear.com/app/answers/detail/a_id/21990/~/how-do-i-configure-a-dhcp-l3-relay-using-the-web-interface-on-my-managed-switch%3F
Hope this helps you a little bit further. If not, please post a more detailed network diagram with VLAN IDs and IPs.
I'm going to post this as a possible solution for people to shoot holes in, and/or suggest how to clean it up. it works in the GNS3 simulation with IOSv images.
Let me first explain what happens to me a bit more clearly, and the rationale for all the complexity.
First for clarity -- I am trying to track against a distant IP, not the next hop, because (a) on DHCP don't know the next hop, and (b) sometimes connectivity problems are after the next hop.
There are simple techniques to achieve this if you do not have DHCP -- TRACK the distant item on separate statements with each next-hop IP explicit, and everything works, and you set precedence with distance.
There is no syntax I have found to use IP ROUTE...TRACK with DHCP and distinguish next-hop's from different interfaces. All the variations I have found end up in a chicken and egg problem - the track can't operate as the SLA has no route to let it reach a distant IP. You can specify ROUTE TRACK with the interface DHCP CLIENT statement, but I cannot figure out any way to make the SLA use that particular interface's next hop. Same with the verify-reachability, at least with all syntax I have found.
If the two DHCP interfaces have unequal metrics, to give one a preference, what I find happens is this (in a straightforward setup): both TRACK statements come up, but despite the SOURCE INTERFACE on them (which is just setting an address), both are going out the preferred default route. Thus when the preferred route is broken (i.e. I stop traffic on it), the route stays as preferred, and BOTH tracks go down. Source interface is not specifying the egress interface
This can partially be fixed by giving them equal preference; then both routes to 0.0.0.0 are installed in the rib, and sometimes (but not always) the two TRACK's will use their interface instead of the opposite and operate independently. Unfortunately not always; not sure why, but by observation sometimes both tracks as written above go out the same interface even with equal preference on the then default gateway.
So this proposed solution uses a route-map to force the traffic for each SLA (using different target IP's) onto a specific egress interface. If this is done with unequal preference default gateways it also fails -- the route map itself fails on the packet for the non-preferred interface; I am unclear why, it just rejects it and says "normal forwarding". I assume it's validating against the rib? But with equal preference sla6 is forced to gi0/6, and sla7 is forced to gi0/7, and work independently.
What I do not know is whether this use of a SET INTERFACE will work generally in this specific cast, i.e. is the packet using the proper next hop, or a proxy arp. I tried looking at it with wireshark but had some issues getting it to run on the simulation. I'll confirm later. I'm hoping it uses the rib for the next hop with the selection of which path made by the route map.
But it's complicated, a bit contrived, and I really would expect there to be an easier solution. The other problem is that it only works, as written, to provide preference for the tunnel, not general internet traffic from inside (that's OK in this case as that was not the intent, but I want to experiment further with additional route map clauses, perhaps based on tracking there, to prefer general traffic also).
I would sure like someone to provide a better way. And/or shoot holes in this one if it won't work.
As above, only the route preference related items shown.
PS. All the non-private addresses are simulated, not used in reality.
track 6 ip sla 6 reachability
track 7 ip sla 7 reachability
crypto ikev2 client flexvpn FLEXVPN_IKEV2_CLIENT
peer 1 9.9.9.2
source 1 GigabitEthernet0/7 track 7 <<< precedence established here, only for tunnels
source 2 GigabitEthernet0/6 track 6
client connect Tunnel31
interface Tunnel31
ip unnumbered Loopback192
ip nat inside
tunnel source dynamic
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile IKEV2_IPSEC_PROFILE
!
interface GigabitEthernet0/6
ip dhcp client default-router distance 100 << must be the same as below or omitted
ip address dhcp
ip nat outside
!
interface GigabitEthernet0/7
ip dhcp client default-router distance 100 << must be the same as above or omitted
ip address dhcp
ip nat outside
!
ip local policy route-map CHOOSE-ISP
ip sla 6
icmp-echo 74.74.74.74 source-interface GigabitEthernet0/6
tag Cellular connection up test
frequency 10
ip sla schedule 6 life forever start-time now
ip sla 7
icmp-echo 75.75.75.75 source-interface GigabitEthernet0/7
tag Local ISP connection up test
frequency 10
ip sla schedule 7 life forever start-time now
!
route-map CHOOSE-ISP permit 10
match ip address 106
set interface GigabitEthernet0/6 <<< give warning
!
route-map CHOOSE-ISP permit 20
match ip address 107
set interface GigabitEthernet0/7 <<< give warning
!
access-list 6 permit 74.74.74.74
access-list 7 permit 75.75.75.75
Best Answer
In your topology the host in VLAN 101 connected to switch LAN_2 are in a separate network that those connected to switch LAN_1. This is because you have a router between them.
So you have 2 distinct VLAN 101, which could be very confusing.
I strongly suggest you change the VLAN name for one of them.
Apart this, you have nothing special to do to provide different DHCP on those networks, since they are totally independent.