NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
PETERGATS
Mar 02, 2014Aspirant
Printing segregated to VLAN by itself
For the life of me, can't get the printer to be alive on its own VLAN..
The SRX5308 is the fw-router (no VPNs just VLANs)
Identified 12 VLANs and treating these as port based VLANs and there's a M4100 behind the SRX5308 doing port based VLANs.
Internet and all inbound/outbound services work great on all VLANs, EXCEPT the printer.
A single departmental printer by itself on VLAN 4
I can ping it from the default VLAN but any print jobs sent to it, never print.
From any other VLANs it doesnt even ping back.
The setup
On the SRX5308 VLAN 40 is set to interVLAN routing, just as the default VLAN is also.
On the M4100, as far as VLAN membership and tags
VLAN 1 (default) all VLANS untagged
VLAN 4 port 1 (VLAN1) Tagged, and all other ports untagged
On all the other ports VLAN membership config page, VLAN 4 is a menber of all the others as untagged..
wat am i doing wrong? It's guta be a simple thing i am missing..
Thx 2 all who respond.. -p
The SRX5308 is the fw-router (no VPNs just VLANs)
Identified 12 VLANs and treating these as port based VLANs and there's a M4100 behind the SRX5308 doing port based VLANs.
Internet and all inbound/outbound services work great on all VLANs, EXCEPT the printer.
A single departmental printer by itself on VLAN 4
I can ping it from the default VLAN but any print jobs sent to it, never print.
From any other VLANs it doesnt even ping back.
The setup
On the SRX5308 VLAN 40 is set to interVLAN routing, just as the default VLAN is also.
On the M4100, as far as VLAN membership and tags
VLAN 1 (default) all VLANS untagged
VLAN 4 port 1 (VLAN1) Tagged, and all other ports untagged
On all the other ports VLAN membership config page, VLAN 4 is a menber of all the others as untagged..
wat am i doing wrong? It's guta be a simple thing i am missing..
Thx 2 all who respond.. -p
15 Replies
- fordemMentorA number of years back, the organization I was working with undertook a Caribbean wide Cisco WAN project, with a spoke & hub VPN design linking a single location in several territories back to "head office". A junior colleague of mine was tasked with setting up the spoke in our territory and this should have required nothing more than unboxing a preconfigured Cisco SOHO firewall connecting it to a DSL modem provided by the local Telco and adding two PCs and a printer - all configuration being done by the folks in the "head office" location. Now - I have no idea how the roll out went in any territory but ours - but - ours did not go well. I believe it was the third day after the job was "completed", it came to my attention that my colleague was having trouble with the installation and had made several trips to site and could not get the VPN to stay connected for more than approximately thirty minutes - he had, as his "support resources" the "head office" team who had performed the configuration, and Cisco support. The following day I was asked to get involved as the downtime was now starting to be an issue and revenue loss was a concern - discussions with my colleague revealed that Cisco support would walk him through disabling the firewall inspection list, at which point the connection would come up, he would then be instructed to re-enable the list, the connection would stay up, he would leave the site, and roughly thirty minutes later he would get a call saying the connection had dropped. I asked him to let me have the configuration which "head office" were reluctant to make available so another day went by - and on the evening of the fifth day the requested information was emailed to me. It took me less than 10 minutes to go through it and determine that they were blocking inbound DHCP in the firewall - so what was happening was this - at power on the Cisco could not get an ip address from the Telco using DHCP, they would disable the inspection list, it would get an address and the connection would come up, they would re-enable the list and the firewall would be unable to renew the DHCP lease and when the lease timed out, the connection would go down. I called my colleague, told him which line in the config to "remark out" - he passed the suggestion to Cisco support (who he had on the phone at the time) and from what I'm told the reply went along the lines of "ahhhhh - yes - that would do it". I can give you a dozen or so similar stories - mostly Cisco related, but only because many of the projects I've worked on have used Cisco equipment - but what I'll say is this -I've been in the business for almost four decades - I'm certified by the "top three PC manufacturers" to support their products, I work on midrange computer systems, UPS power & network infrastructure, I've done WAN support on some of the largest "globe spanning" WANs and built out a few smaller "country spanning" WANs and there isn't a tech support team that I have worked with that hasn't pissed me off at some point along the way. I use Netgear equipment personally, and recommend it in most of my SMB installations, it's decent gear at an affordable price - and for what it's worth - I've just watched another of my colleagues who can be considered a Cisco fanboi (Juniper is his "second best") just spec Netgear - says he can't justify the cost of Cisco. Cost of Cisco was the reason I walked away from it - I will admit to having had more than one "head scratching" moment when Netgear equipment doesn't do what I want, the way I think it should be done, I have been "BSed" all the way up to L3 support, but the equipment generally delivers as promised, at least to a level comparable to any other similarly priced product.
- PETERGATSAspirantTY for the encouragement sir, much needed and appreciated at this point in time to stay the course and not take "drastic" measures in order to "justify" measures to the top brass so to speak. I can appreciate all you say. It just looks like a commitment has to be made by me and my team to learn to speak the "Netgear Language" and be much more self sufficient and also learn to script ACL's at command line and enable SSH (Netgear support enables Telnet over the LAN and scripts that way, I'd feel a lot more comfy with SSH).
- PETERGATSAspirantrequest that a moderator mark this thread as [solved] in the subj line without changing thread contents for the benefit of future seekers seeking this soln.
(NOTE; having to post this as separate thread entries as ths forum's BB system only allow 10K characters per posting)
This support case was solved on 3/6th, the day after last posting, by a Netgear "Middle Enterprise Experts L2" support group engr. So in all fairness, this particular sub group inside of Netgear support proved responsive and ESPECIALLY so as to the particular engr that i dealt with.
The following solution is based on ACLs and was generated by Netgear "Middle Enterprise Experts L2" support group.
( i wil not mention the name of the person that solved this for us and that i personally found to be a very resourcefull and a very skilled support engr, as i do not want to endanger their job if the wrong "spin" is put on by the employer. -stranger things i have witnessed..- I would just like to thank them and tell all that the following is their work at solving this. SO this is not my work, and it works very well, as it solved this problem for us )
The following will also solve the problem of anyone setting up a bunch of VLANs tht they want to have as separate or segregated (i will not use the word "isolated VLAN" as the term "isolated" refers to something else inside Netgear documentation as far as configuraitons where VLANS are concerned),
In this setup let's say we/you want to only share the internet connection
-(this also could be multiple WAN providers on a SRX5308 or similar multi-wan router, regardless, the internet feed(s)conection(s)- is intended to be shared),
and also required is inbound svcs (like RDP remote control for users' desktop access and such) and of course, outbound services from all VLAN LANs.
-(By this i mean that the VLAN ports on the M4100 are set up as port based VLANs and in turn are connected to flat LAN unmanaged switches at diffrent depts).
Also a shared resource pool is needed so as to be able to have all the VLANs share a common printer/copier and perhaps sharepoint servers, email servers and such ..
-So the approach found to work is take one of the VLAN ports (NOT the default LAN, which is known as the VLAN 1 port), but say using port 4, as it is used in this case, and make it into the common VLAN, seen by all VLAN members and then the printer(s) are connected to an unmanaged switch that ends up being connected to port 4 on the M4100 VLAN switch.
The setup:
You have a router (a Netgear SRX5308 in this case, but i can see for soho use even an older DD-WRT flashed Linky blu-box that's broadcom based and can define VLANs just doing the job) feeding a M4100 port based VLAN switch. (i can also see any managed switch being used that has VLAN support, same principles apply)
You are using 12 ports with VLANs assigned to ports as follows and you have the router also configured so it knows about the VLANs and also is doing the dhcp for all the VLANs.
IMPORTANT HERE --> On the router you turn on "enable interVLAN routing" ON ALL THE VLANS AND PORTS (EXCEPT PORT 2 WHICH YOU WILL USE FOR VOIP TRAFFIC AND IS A SEPARATE ENTITY) as you will use the M4100 VLAN switch ACL scripts to stop the packets from getting to the VLANs (ON THE SWITCH ITSELF, BEFORE EVEN GETTING TO THE ROUTER) as the goal is you dont want to snoop each others' VLANs or discover each others' resources.
(oops forgot to mention that, Updated the fw to latest rev upon unboxing of both router and switch).
On both the router and switch you define the following VLANs and ip ranges
The router and switch are interconnected with a patch cord on each other's respective port 1's.
VLAN 1 is default LAN, PVID 1 on switch, and carries all internet traffic
On switch you have it UNtagged in its own default LAN (marked VLAN 1) configuration for ALL the ports on the switch, (BUT AS A TAGGED port, as you see below, when you define all the other VLANs). You define on the router the default LAN config (VLAN 1) as dhcp range 10.100.1.100 - 200 range and its deflt gw as 10.100.1.1 (it's \24 on this deflt LAN & all these VLANs, 255.255.255.0, --(found out from the router that i couldnt use the old supernet trik of stipulating a 255.255.248.0 or 255.255.240.0 netmask to have more hosts. it wouldnt take it, telling me i'm outa range..)
On the router, no deffn as to Port 2 and also on the switch port 2 remains factory default as PVID 1 (just another port like port 1 at this point) because port 2 is being reserved for future allocation to Voip traffic and on this particular Netgear M4100 port based VLAN switch port 2 is designated as the AutoVoip port and comes preconfigured for Voip expected usage. YOU LEAVE THIS PORT WELL ENOUGH ALONE on switch for now
Port 3 on switch is marked (you mark it) as PVID 30, on router it's created as VLAN 30 and on the router you set its dhcp range as 10.100.3.100 - 200 with a default gw of 10.100.3.1, On switch under port membership, you mark its config as port 1 tagged, port 3 & 4 as untagged.
Port 4 on switch is marked (you mark it) as PVID 40,THIS PORT IS ALLOCATED AS A SHARED VLAN RESOURCE COMMON AND AVAILABLE TO ALL VLAN MEMBERS. On router it's created as VLAN 40 and on the router you set its dhcp range as 10.100.4.100 - 200 with a default gw of 10.100.4.1, On switch under port membership, you mark its config as port 1 TAGGED, ports 3 - 12 get marked as UNtagged.
Port 5 on switch is marked (you mark it) as PVID 50, on router it's created as VLAN 50 and on the router you set its dhcp range as 10.100.5.100 - 200 with a default gw of 10.100.5.1, On switch under port membership, you mark its config as port 1 tagged, port 5 & 4 as untagged.
Port 6 on switch is marked (you mark it) as PVID 60, on router it's created as VLAN 60 and on the router you set its dhcp range as 10.100.6.100 - 200 with a default gw of 10.100.6.1, On switch under port membership, you mark its config as port 1 tagged, port 6 & 4 as untagged.
Port 7 on switch is marked (you mark it) as PVID 70, on router it's created as VLAN 70 and on the router you set its dhcp range as 10.100.7.100 - 200 with a default gw of 10.100.7.1, On switch under port membership, you mark its config as port 1 tagged, port 7 & 4 as untagged.
Port 8 on switch is marked (you mark it) as PVID 80, on router it's created as VLAN 80 and on the router you set its dhcp range as 10.100.8.100 - 200 with a default gw of 10.100.8.1, On switch under port membership, you mark its config as port 1 tagged, port 8 & 4 as untagged.
Port 9 on switch is marked (you mark it) as PVID 90, on router it's created as VLAN 90 and on the router you set its dhcp range as 10.100.9.100 - 200 with a default gw of 10.100.9.1, On switch under port membership, you mark its config as port 1 tagged, port 9 & 4 as untagged.
Port 10 on switch is marked (you mark it) as PVID 100, on router it's created as VLAN 100 and on the router you set its dhcp range as 10.100.10.100 - 200 with a default gw of 10.100.10.1, On switch under port membership, you mark its config as port 1 tagged, port 10 & 4 as untagged.
Port 11 on switch is marked (you mark it) as PVID 110, on router it's created as VLAN 110 and on the router you set its dhcp range as 10.100.11.100 - 200 with a default gw of 10.100.11.1, On switch under port membership, you mark its config as port 1 tagged, port 11 & 4 as untagged.
Port 12 on switch is marked (you mark it) as PVID 120, on router it's created as VLAN 120 and on the router you set its dhcp range as 10.100.12.100 - 200 with a default gw of 10.100.12.1, On switch under port membership, you mark its config as port 1 tagged, port 12 & 4 as untagged. - PETERGATSAspirantLAST response continued, (This forum's BB system does not allow more than 10K characters per posting)
Ok good, take a breath,
Now the "majik" happens in the ACL scripting and applying to make all this work.
--(Again with BIG thanks to the Middle Enterprise Experts L2 support group resourcefull engr who solved this for us!! This is NOT my work but his.)
(Again can't mention his name in open forum in good conscience, for his own job safety, just in case taken the worng way by mgmt types)--
Within the LAN, Netgear support enables telnet and uses PUTTY as a term to get to the command line interface to the managed VLAN switch, the M4100 in this case.
Also they use Notepad app as a handy scripting and cut-paste device so as to be able to copy-paste enmasse from Notepad into Putty cmd line term.
([HANDY SWITCH access NOTE:
Say you changed the switch admin settings so the switch responds to a non std https port, say you changed it to 7008, so now in PUTTY you would designate to connect to ipaddr_of_switch:7008 and then leave it as port 22 in standard Putty telnet settings.. it workx this way..])
Ok NOW, What didnt work at first, BUT mentioned here bcs some folks mite wana enable the VLAN separation/segregation BUT WANT to leave ALL the VLANs visible AND accessible from the deflt LAN or VLAN 1.
The following lines scripted and applied as ACL 100 work and do what is mentioned in last sentence.
At first the following 3 lines were scripted and applied to all ports except port 4:
access-list 100 permit ip any 10.100.4.0 0.0.0.255
access-list 100 deny ip 10.100.0.0 0.0.15.255 10.100.0.0 0.0.15.255
access-list 100 permit ip any any
HOWEVER ONLY these 3 above lines will let you still see ALL the VLANs from the default LAN BCS "enable InterVLAN routing" is checked on the SRX5308 router in this case.
SO say you want to segregate completely and NOT even let the deflt LAN "see" (access NOR snoop) ANY of the VLANs.
Well these 3 above lines shoulda done it because these 3 above lines implicitly include the default LAN (stipulated as VLAN 1) .. BUT they don't.. why is unknown.
The soln was to explicitly stipulate this condition and address it ONLY for the default VLAN as below after this first part
the below was then scripted
(BTW, i learned from same support engr that the below "netmask-ish" references are not netmask designation but wildcard mask designation as shown in wiki)
http://en.wikipedia.org/wiki/Wildcard_mask
access-list 100 permit ip any 10.100.4.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.2.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.3.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.4.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.5.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.6.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.7.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.8.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.9.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.10.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.11.0 0.0.0.255
access-list 100 deny ip 10.100.1.0 0.0.0.255 10.100.12.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip any 10.100.4.0 0.0.0.255
access-list 101 deny ip 10.100.0.0 0.0.15.255 10.100.0.0 0.0.15.255
access-list 101 permit ip any any
access list 101 is applied to port 3 and 5-12
acess list 100 is applied to only port 1
so we are denying sub networks from 10.100.0.0 to 10.100.15.0, even tho we are using only subs 10.100.1.0 to 10.100.12.0, gives you some expansion or future playing space.
Several tutorial links tht i googled and found usefull as to ACLs in general, not just Netgear eqpt, altho it is inclusive of Netgear eqpt as well ..
ACL quick tutorial over at Brocade :
http://www.brocade.com/support/Product_Manuals/ServerIron_SecuirtyGuide/acls.3.8.html
then i googled this and found the Cisco tutorials referenced below of good edu value.
https://www.google.com/#q=writing+acl+numbering+convention+1-99+100-199
For an even better and indepth 6 part ACLs tutorial over @ Cisco:
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-part-1/
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-part-2/
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-acls-%E2%80%93-part-3/
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-part-4/
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-part-5/
http://blog.globalknowledge.com/technology/cisco/routing-switching/access-control-lists-part-6/
Will also try to follow up post as to HOW the ACLs were manipulated and applied to ports in the CLI , Command Line Interface of the switch.
all for now - PETERGATSAspirantModerator pls mark this thread as solved without changing the thread contents, TY
So this shld be my last post in this thread directed to future seekers of same "VLAN separation/segregation but with shared resources" solution and this particular post is how i watched the same resourcefull and "proficient with his Netgear Eqpt" engr mentioned above, script and then manipulate the application of the ACLs (apply or unapply the ACLs to certain ports is what i mean by manipulate)
So the following is instruction received by same individual:
-------------------------------------------------------------------------------------------------------------
Syntax when scripting ACL in CLI is:
access-list
So after scripting the ACLs how to manipulate the ACLs
commands for implementing access-list, we designated as 100 selectively on say only port #7 and then unapplying the same ACL off of same port, and BTW only picked port 7 as a tutorial for any port.
command sequence as follows:
(M4100-D12G) #configure
(M4100-D12G) (Config)#interface 0/7
(M4100-D12G) (Interface 0/7)#ip access-group 100 in
(M4100-D12G) (Interface 0/7)#exit
(M4100-D12G) (Config)#interface 0/7
(M4100-D12G) (Interface 0/7)#no ip access-group 100 in -- to take it off
end of selective application onto only a specific interface !!
OH and BE ONSITE next to your eqpt in case you LOCK it up and havfta reboot it to get back to old saved running config. DO NOT save any config till U got it working.
ALSO another sav your butt technique, enable external access from the internet and port fwd teh management interface out.. U may loose internal access becs U have disallowed any packets getting routed BUT U may still be able to access device from its port fwd'ed "external2yourLAN" i/fc...
AND here's a command sequence as to scripting an ACL, altho most of the time, scripting was done in Notepad app and then cut-pasted into Putty CLI windo enmasse, (try it and see it work)
Log in via Telnet (hopefully SSH even better, after enabling the SSH interface of the device, device being switch or router)
User:whoUB2day (say you be admin)
Password:*******************
(M4100-D12G) >enable
(M4100-D12G) #configure
(M4100-D12G) (Config)#access-list 100 permit ip any 10.100.4.0 0.0.0.255
(M4100-D12G) (Config)#access-list 100 deny ip 10.100.0.0 0.0.15.255 10.100.0.0 0 .0.15.255
(M4100-D12G) (Config)#access-list 100 permit ip any any
(M4100-D12G) (Config)#interface 0/3
(M4100-D12G) (Interface 0/3)#ip access-group 100 in
(M4100-D12G) (Interface 0/3)#exit
(M4100-D12G) (Config)#interface 0/5-12
^
An invalid interface range has been used for this function. An interface range must be 1000 characters or less.
(M4100-D12G) (Config)#interface 0/5-0/12
(M4100-D12G) (Interface 0/5-0/12)#ip access-group 100 in
(M4100-D12G) (Interface 0/5-0/12)#exit
(M4100-D12G) (Config)#
So there you have it, them interface designations mean 0/5 is unit 0 in the stack and on port 5, if U got a stack with a bunch of same switch devices in it, next device is 1/5 being second device and its port 5 on device 1, If just a solitary device it is designated as first device being managed, device zero, thus device zero and the port number you are manipulating.
Oh and another good ACL tutorial as well:
http://www.danscourses.com/CCNA-4/standard-access-lists-acl.html
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!