I made some complex LAB with components which lack basic features like DHCP relay.
The only possible way to relay dhcp requests was by using an GRE tunnel towards the destination DHCP server.
The tunnel was between the DHCP server and MLS (L3 Switch).
The relay agent worked great via the VTI but after adding the DHCP SNOOPING feature on the MLS, each of the remote dhcp request that came through the same DHCP vlan that I created, they have arrived to the MLS that connected to the outside network and had the VTI tunnel for relaying the dhcp request to the dhcp server via the VTI, but therefore configuring it with the DHCP SNOOPING security mechanism , suddenly the dhcp request packets stopped being relayed to the dhcp server through the VTI, only through the trusted Physical Interface that I configured, which then unfortunatly couldn’t get relayied by the next hop router because it wasn’t supporting that dhcp relaying feature.
direclty connected hosts that connected to the same MLS switch did got relayed through the tunnel, only hosts that was sitting behind another switch couldn’t cross the network via the VTI toward the DHCP server.
Is that behavior right that made the MLS stop forwarding dhcp requests through the VTI from remote hosts?
or maybe it is a bug caused by IOSv L2 Switch in GNS3?
Why couldn’t I configure the VTI itself as a trusted dhcp snooping interface as it might solve the problem?
when disabling the physical interface from being trusted toward the dhcp server, packet from direcly connected hosts still got relayed through the tunnel VTI but then the dhcp offer got blocked caused by the physical interface being an untrusted port even though the offer messages also traversed to the MLS via the tunnel.
I hope someone could help me here and search for an answer or already knows the answer.
Thanks you very much!