Re: Protected switch ports

From: Le Dinh An (anld@ispco.com.vn)
Date: Fri Jan 17 2003 - 01:18:10 GMT-3


 Hi John,

This feature should be used for security reason. Customer A can only
communicate with customer B through a router (or firewall) just because
it is designed that there is no direct connections between the two
customers, this will prevent the subnet from being vulnerable to be
attacked from hackers.
Let have another example, in a DMZ segment, a mail server and a web
server are on the same subnet but different private vlans. Connections to
these servers should be originated from other subnets, or more obviously,
from the Internet. The web server running some M$ web server software and
is hacked, the hacker then takes control of the server and tries to
attack the mail server. If the mail server can be directly accessed from
the web server then it'll be very dangerous, the hacker can tries every
tools to hack the mail server without being awared by the
firewall/router. This is why we have to implemnet PVLAN here to avoid the
vulnerablity, the firewall/router can track and block unwanted
tool/application flows.

Hope this helps you.

An.

John Tafasi wrote:

  Well, it might be good idea to assign all the ISP customers to one IP subnet
  while seperating them at layer 2. But the question is: if customer A,
  connected to port 1, realy needs to communicate with another customer
  (customer B) that is connected to port 2, how would you make them able to
  communicate? The excerpt below implies that customer A can only communicate
  with customer B through a router, but why? they are on the same subnet!!!
  
  ----- Original Message -----
  From: "Alavalapati, Abhimanyu V." <aalavala@ubspw.com> To: "'John Tafasi'" <johntafasi@yahoo.com> ; "ccielab" <ccielab@groupstudy.com> Sent: Thursday, January 16, 2003 6:45 PM
  Subject: RE: Protected switch ports

    Was designed for ISP's where they did not want to burn up a subnet per
    customer, so they had all their customers on one logical subnet and
    seperated them at layer 2. We do this in our extranet environment,
    
    -----Original Message-----
    From: John Tafasi [ mailto:johntafasi@yahoo.com ]
    Sent: Thursday, January 16, 2003 4:45 PM
    To: ccielab
    Subject: Protected switch ports

    Hi, group,

    the following is an excerpt from the ipexpert catalyst 3550 tutorial.
    Although
    the configuration is very simple and understandable, I can not imagine a
    situation where you would want to deny two hosts in the same lan from

  seeing

    each other. Can some one give an example of a situation where you would

  want

    to configure protected ports.

    Thanks
    
    =============================

    Protected Ports (Similar to Private VLANs)
    
    Some applications require that no traffic be forwarded between ports on

  the

    same
    
    switch so that one neighbor does not see the traffic generated by another
    neighbor. In
    
    such an environment, the use of protected ports ensures that there is no
    exchange of
    
    unicast, broadcast, or multicast traffic between these ports on the

  switch.

    Protected ports have these features:
    
    A protected port does not forward any traffic (unicast, multicast, or
    broadcast) to any
    
    other port that is also a protected port. Traffic cannot be forwarded
    between
    protected
    
    ports at Layer 2; all traffic passing between protected ports must be
    forwarded through a
    
    Layer 3 device.
    
    Forwarding behavior between a protected port and a nonprotected port
    proceeds
    as
    
    usual.
    
    Switch# configure terminal
    
    Switch(config)# interface gigabitethernet0/1
    
    Switch(config-if)# switchport protected
    
    Switch(config-if)# end
    
    You can also disable unknown multicasts and unicasts from being flooded to

  a

    protected port with the "switchport block unicast," and "switchport block
    multicast"
    
    commands.
    .

  .

-- 
Le Dinh An
Network Consultant
Phone: 84 913 100 478
.


This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:52 GMT-3