Yes, this should work fine.  I'd configure a tight ACL on that thing so you
don't walk in and find a ream of paper wasted.  You can configure the ACL to
limit who can print to it, say the main office and all the other remote
sites, etc., but just not that internet at large.  Not to mention you don't
want some script kiddie going into your JetDirect (if it's HP) and setting a
password and tweaking with settings.

--
Jason Roysdon, CCNP/CCDP, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
Cisco resources: http://r2cisco.artoo.net/


"Ole Drews Jensen" <[EMAIL PROTECTED]> wrote in message
2019FB428FD3D311893700508B71EBFB4D3FF9@RWR_MAIL_SVR">news:2019FB428FD3D311893700508B71EBFB4D3FF9@RWR_MAIL_SVR...
> This kind of brings up a question from my side.
>
> Picture a branch office connected to the Internet with a router setup for
> PAT. Let's say that the scope of IP addresses assigned to the office by
> their ISP is 214.100.200.64 / 29, which gives them 214.100.200.65 thru
> 214.100.200.71 to play around with.
>
> Workstations on the LAN has addresses on a private 192.168.20.0 network.
>
> Let's say that 214.100.200.68 is the IP address that they every
workstation
> on the LAN will be translated to when going out through the router.
>
> However, that office has a printer that must be available to external
> workstations/servers, so I would like to take assign it 214.100.200.70.
>
> Now, with all devices at that office connecting to a cheap hub, wouldn't
> this work okay, or would the best thing be to statically NAT
214.100.200.70
> to a dedicated address on the 192.168.20.0 network which then is assigned
> the printer?
>
> This is probably an easy question for some of you guys, but I just haven't
> played around with it before.
>
> Thanks,
>
> Ole
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Ole Drews Jensen
>  Systems Network Manager
>  CCNA, MCSE, MCP+I
>  RWR Enterprises, Inc.
>  [EMAIL PROTECTED]
>  http://www.oledrews.com/ccnp
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  NEED A JOB ???
>  http://www.oledrews.com/job
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> -----Original Message-----
> From: Bob Vance [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 11:58 AM
> To: CISCO_GroupStudy List (E-mail)
> Subject: RE: why is routing needed with VLANs
>
>
> Thanks.
>
> >A VLAN is, by definition, a separate subnet.
>
> Well, not by any definition that I've yet read :)
>
> But, I was essentially asking *why* it has to be a different subnet.
> That is not discussed anywhere that I've read.
> But, anyway, as I posted, I think that the answer is ARP.
> If ARP broadcast is not forwarded then we'll not be able to find the MAC
> address of a destination IP outside our own VLAN (at least not without
> Proxy ARP -- and we've just introduced a router, again !!!
>
>
> -------------------------------------------------
> Tks | <mailto:[EMAIL PROTECTED]>
> BV | <mailto:[EMAIL PROTECTED]>
> Sr. Technical Consultant, SBM, A Gates/Arrow Co.
> Vox 770-623-3430 11455 Lakefield Dr.
> Fax 770-623-3429 Duluth, GA 30097-1511
> =================================================
>
>
>
>
>
> -----Original Message-----
> From: John Neiberger [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 12:48 PM
> To: Bob Vance; [EMAIL PROTECTED]
> Subject: Re: why is routing needed with VLANs
>
>
> A VLAN is, by definition, a separate subnet.  If you decided to separate
> a
> single LAN into two VLANs, you'll have to change your addressing scheme.
> Once you've done that, you have to route to get from one subnet to the
> other.  I don't even like the term "VLAN".  The very term seems to cause
> a
> lot of conceptual problems.
>
> For example, let's say you have one LAN and you decide to create a new
> VLAN
> for a total of two VLANs.  This is absolutely no different than having
> two
> normal LANs on different ports on a router: you have two separate IP
> subnets
> and you must route to get from one to the other.  The only difference is
> that you can use trunking to pass data for both subnets down the same
> wire,
> and you can then let a switch split that traffic up and send it to the
> correct ports.
>
> Imagine the router with two separate ethernet interfaces, each in its
> own
> subnet, and these are connected to two separate switches.  There is no
> topological difference between that scenario and a router doing ISL or
> 802.1q trunking to a switch that is configured for two VLANs.  The
> requirements for connectivity are the same:  you must have a router to
> get
> from one subnet to the other.  Even though they are physically on the
> same
> switch, topologically speaking they are on different networks.
>
> I hope this makes sense.  I had three people stop by my cube to talk and
> I
> had three phone calls while trying to write this.  :-)
>
> Regards,
> John
>
> >  OK.
> >  I must be brain dead, today.
> >     (and, yes, Chuck, I *have* had my morning dose of Diet Coke :)
> >      and, yes, I know, "What's so special about 'today' "?
> >     )
> >  As far I can understand it so far, about the only benefit that I see
> >  from VLANs is reducing the size of broadcast domains.
> >
> >  Suppose that I have a switch in the closet with one big flat address
> >  space (well, it couldn't be that big with only one switch, now, could
> >  it ?>).  Then someone says,
> >    "You know, we're getting a lot of blah-blah broadcast traffic.
> >     Let's VLAN.
> >    "
> >  OK, fine.  We VLAN and put whatever services in each VLAN that are
> >  required to handle the broadcasts (e.g., DHCP service).  So, now the
> >  switch doesn't send broadcasts outside a particular VLAN.
> >
> >  But, what's so magic about a VLAN that the switch also decides not to
> >  send unicasts outside a VLAN.   Before the VLANs, the switch
> maintained
> >  a MAC table and knew which port to go out to get to any unicast
> address
> >  in the entire space.  So, why can't it continue to do that after we
> >  arbitrarily implement some constraint on broadcast addresses?
> >  It seems to me that the same, exact MAC table, with an additional
> VLAN
> >  field would not require that restriction.  If it's a broadcast, send
> the
> >  packet only out ports with a VLAN-id that matches the source port's
> >  VLAN-id.  If it's a unicast, handle it just like we used to.
> >
> >
> >  Similarly, even if we have 5 switches, I just don't see the
> requirement
> >  that we (as switch-code designers) must block unicasts and resort to
> a
> >  routing requirement.
> >
> >  Even with 500 switches ... well, let's not get ridiculous :)
> >
> >
> >  I feel that there is a simple point that I've overlooked, so I will
> >  continue to RTFM while I await your responses.>)
> >
> >
> >  -------------------------------------------------
> >  Tks??? ??? | <mailto:[EMAIL PROTECTED]>
> >  BV??? ???? | <mailto:[EMAIL PROTECTED]>
> >  Sr. Technical?Consultant,? SBM, A Gates/Arrow Co.
> >  Vox 770-623-3430???????????11455 Lakefield Dr.
> >  Fax 770-623-3429?????????? Duluth, GA 30097-1511
> >  =================================================
> >
> >
> >
> >
> >  _________________________________
> >  FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> >  Report misconduct and Nondisclosure violations to
> [EMAIL PROTECTED]
>
>
>
>
>
> _______________________________________________________
> Send a cool gift with your E-Card
> http://www.bluemountain.com/giftcenter/
>
>
>
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>


_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to