09-16-2008 01:03 PM
Have you tried it with the default VLAN for the IVS set to the VLAN you are assigning? I think the SA sends all management traffic, which might include the DHCP request, over the default VLAN. This would also mean, however, that the authentication, logging, archiving data, etc., from the IVS would also be put on that VLAN. Not sure if this configuration would work for you...
09-16-2008 01:18 PM
Are you running the recent firmware? The previous version I had, 5.5R2 don't have a VLAN tab, but when I upgraded to 6.1R2 it has the VLAN tab that enable us to create 2 or more VLANs etc, though I'm having a hard time to enable tagging on the Internal Port to support those VLANs. Anyone?
09-16-2008 01:24 PM
I'm on 6.0R5 with a hotfix. It must be that VLANs were added to the basic set in 6.1.
You don't have to do anything special to tell the SA to do 802.1q trunking. All you have to do is to define the VLANs. You do have to configure your switch to let it know this is a trunk port rather than an access port.
09-17-2008 11:56 AM
We have a SA 6500 with 6.2R2-1 in test. We dont have IVS license.
We have the default VLAN with two others VLAN configured on the internal interface. Effectively the DHCP request work fine if we assign the default VLAN with a role.
09-23-2008 10:57 PM
I have came across the same problem myself. I am in a position where I need to assign static IP to users connecting via NC and want to reserve addresses for them to 'ease' the management.
I have set the role in its own vlan but a capture on my DHCP server shows the source address as being the default internal IP address, not the VLAN the NC profile belongs to.
Did you have any luck or are you going to just use the default internal IP address rather than vlanning it off.
09-24-2008 05:21 PM
Yep I have selected that and like Yves, when I use the IVE to issue DHCP it is cool but when I point it to my DHCP server, the DHCP server receives packets with the source address of the default internal vlan.
After the post I actually tried adding a static route for my DHCP server in the NC VLAN route table but unfortunately did not work, DHCP server still received DHCP request from default internal vlan.
09-25-2008 08:04 AM
I recommend you open a JTAC case. It would seem to me that any DHCP request should be sent from the SA's address on the specified VLAN for the role, and that clearly is not occurring. In the admin manual, there is a section on using a shared DHCP server for multiple IVSs, with some way for the DHCP server to differentiate between the requests. So you might be able to do what you want to do if you implement IVSs. I'd see this as a workaround, not as a permanent correction to the problem.
I'm seeing the same behavior with an autoproxy PAC file I have which uses the source IP address of the client to make decisions about the correct proxy. When the SA is creating the instantproxy.pac file, it clearly fetches the PAC file from the source address of the default VLAN for the IVS instead of the source address of the VLAN assigned to the role. I've found a workaround for this - the PAC file allows the source IP to be hard-coded in the URL instead of getting it from the client address - but I don't think I should have to use this workaround.
09-26-2008 09:09 AM
I opened a case for this even I have the IVS feature enabled but I do not want to make a new IVS for every VLAN which we want to enable NC and have DHCP server enabled. =)
11-17-2008 12:09 AM
It is working as implemented - We use the default VLAN IP as the gateway IP address in the DHCP request.
I would recommend you to contact your sales manager to raise a ENHANSMENT REQUEST [ ER]. Since the product is working as designed, the feature thatyou want can be obtained only by a enhansment request.
11-17-2008 04:42 PM - edited 11-17-2008 04:54 PM
From what I have gathered from this incredibly long thread is that you are trying to use the physical interface (which cannot be tagged) and sub-interfaces (which can be tagged). I'm going to talk Foundry since that's the evil I know. On a Foundry, there is what is called dual-mode. On the physical interface of the switch, you configure it for dual-mode, and tell the interface for what default VLAN you want untagged traffic dropped into. All other traffic will be tagged (802.1q) and will be dropped into the proper VLAN.
int e 1
tag e 1
tag e 1
untag e 1
Someone in the world of Crisco, can you confirm what I'm saying:
If a dot1q trunk receives a tagged frame on the native vlan, it drops it.
When a cisco trunk port receives untagged frames it forwards them to the native vlan #1 by default
So, if you want the native VLAN to be something other than 1, you can change the default VLAN, but this does not move STP or other Crisco things from VLAN 1.
11-18-2008 06:35 AM - edited 11-18-2008 06:41 AM
That is correct. I use this configuration on Catalysts, and all untagged traffic leaving the SA is put on the default VLAN on the turnk port of the switch.
Don't know if this suggestion will be useful, but I had some success getting Juniper to move on a "working as designed" issue that I had. I told them - through the JTAC engineer and my local SE - that if it was "working as designed", then it was "designed as stupid". I think that applies here too. If a role has its traffic assigned to a VLAN, and uses DHCP, it makes no sense to send the DHCP request out as untagged traffic. Or - at the least - you should have the option for the DHCP traffic to be sent on the VLAN.
11-18-2008 07:42 AM
OK, so what I said was accurate then. It will send it to the default VLAN. The default VLAN on Crisco can be changed, but that doesn't move things like STP or Crisco proprietary stuff over, that still remains on VLAN 1.