Conference irocz::common_brouters

    1) What is the RJ45 port on the top of each VNswitch?  I heard it was
    an Ethernet port that could only be used for SNMP and Telnet (?)  How
    do you get it to work?  I have tried straight-through and crossover
    cables, and setting in-band and OBM IP addresses, with no success.

It is an Ethernet port, but it cannot be used for bridging/switching
like the other Ethernet ports. It can only be used for primitive loading
of software images (you only need to do a primitive load when you
can't do an operational load over the network for some reason), and
for dumping of the system's memory after a crash. It cannot be used
for management access to the system (e.g. SNMP, Telnet, etc.) 
    
    2) Is it true that in order to manage any VNswitches, the NMS must be
    in the default VLAN?  If the NMS is in the default VLAN, can you manage
    other VNswitches across the VNbus independent of what VLANs they have
    configured on their ports?

No, the NMS can be in any VLAN (actually VSD). The IP end system
protocol stack on the VNswitch (TCP/IP Host Services) can be attached
to one and only one VLAN (VSD), but that can be any of the VSDs
configured on that VNswitch. The NMS must be able to communicate
with the IP end system stack in that VSD. If the NMS is in the same
subnet as the VNswitch's TCP/IP Host Services then the NMS has to be
attached to the same VSD. Otherwise (different subnet) you must have
an IP routing path between the NMS and the TCP/IP Host Services VSD.
    
    3) With the DECswitches, the address filtering was not very useful, in
    that it checked source address for incoming frames and destination
    address for outgoing, whereas most customers wanted it to be able to
    filter incoming frames based on the DA and filter outgoing frames based
    on the SA.  Can you confirm whether this filtering is supported on the
    VNswitches?
  
The VNswitch only supports the same address filtering as DECswitches,
i.e. SA filtered against input port and DA filtered against output
port - with the addition of VLAN filtering. I'd like to hear more
about what problems customers are trying to solve with the altenative
filtering you mentioned and whether they can be solved using VLANs
(perhaps when we have MAC address based VLANs for example).

Chris

    Most people have a perceptual thing when dealing with bridge filtering
    models. If you look at a multiport bridge, it must be viewed as a bunch
    of instantaneous bridges within a box, with each incoming packet being
    switched/bridged to an outbound destination, based on some simple
    filtering rules.
    So for each inbound port to outbound port packet movement it appears to
    have its own bridging engine at its disposal.
    In real physical terms, the bridging engine is shared by multiple ports.
    In simple terms, the bridge/switch uses source filtering to control the
    source port for the source address and destination filtering to control
    the destination port for the destination address.
    However, you can't use the source address to control the destination of
    a packet (as a lot of customer scenarios seems to want/perceive).
    IE: You can tell the bridge that an address is "allowed" on an arbitrary
    port or set of ports.  This works both as a source address filter (in
    that a packet with this address as source will only be forwarded if it
    came in on one of the allowed set of ports); and as a destination address
    filter (in that a packet with this address as destination will only be
    forwarded to the allowed set of ports, and in particular, only to the
    port on which the address was learned if this information is available).
    
    
    Bob

    Thank you Chris and Bob.
    
    Couple more questions:
    
    - are hub managed upgrades dependent on the CSNMP function - i.e. is it
    correct that the VNswitches do not support hub managed upgrades
    
    - is the VNswitch supported as an IP services module?
    
    Thanks
    Jeannie
                   
                   

>>  However, you can't use the source address to control the destination of
>>  a packet (as a lot of customer scenarios seems to want/perceive).

I presume you are speaking in terms of our existing bridge products, and/or
the Bridge MIB (RFC 1493).

Is there any theoretical reason why a new bridge could not be engineered to
do the type of filtering the customers seem to want?  Something to think
about whenever we go to design the next generation of bridges.

Or maybe, if we talk to enough customers in enough detail to find out their
real needs, we'll find that "source address -> allowed destination ports"
filtering is not the only way to solve our customers' problems.

    Hi,
    
    i have the following questions :-
    
    1. STP on VNswitch
       - If a switch port does not receive STP, will it stop forwarding
          traffic from that port ?
       - Any recommendation on setting STP in VNswitch in the following:-
         - Noloop.
         - Some parallel loop.
         - Tree sturture.
    
    2. What condition will caused a VNswitch port or module to crash ?
    
    Thanks
    Parry

    Re: .3  
    
    Jeannie
    
    - You are correct in that VNswitches do not support hub managed
      upgrades.
    
    - VNswitches IS supported as an IP services module.
    
    Rich

This is a reply to .5:-

    1. STP on VNswitch
       - If a switch port does not receive STP, will it stop forwarding
          traffic from that port ?

No, the default setting is to run STP on every port. If no STP
messages are received on a port then the port will go into
Forwarding state - this is the standard spanning tree algorithm

       - Any recommendation on setting STP in VNswitch in the following:-
         - Noloop.
         - Some parallel loop.
         - Tree sturture.

I recommend that you run STP on all ports regardless of your physical
topology. the amount of traffic it generates is insignificant. Running
it provides protection against creating bridge forwarding loops which
can create network overload (all ports can become saturated with a single
looping packet for example and that loop will persist until you take
corrective action like unplugging a port in the loop or doing something
via management to disable a port in the loop). The whole purpose of spanning
tree is to provide loop protection - use it unless doing so prevents something
from working. By the way it is *really* easy with soft configured VSDs and
hub lan hopping to inadvertently create a bridge loop - I have done it
many times when testing ! With STP turned on doing so does not create
a network overload - instead STP makes sure you never end up with an
active forwarding loop.
    
    2. What condition will caused a VNswitch port or module to crash ?

I'm not sure what you are asking - as with any product, we have our
bugs, both known and unknown. The known ones we are working on
fixing - the unknown ones, well, we can't fix them yet ! Have you
had a module crash ? If so you should enter an IPMT case so that we 
can determine the cause and fix it. Ports do not "crash" - they may
become inactive as the result of bugs or correct STP operation.

Chris