Conference 7.286::fddi

    ... all I can suggest is contacting FDDI Marketing, Karl (DELNI::)
    Pieper.

    Cisco now has a box which has 6 brouter ports and 1 fddi.  They
    are pushing it, not as a concentrator, but as a method of buying
    increase bandwidth by eliminating contention.  It doesn't truly
    bridge (as far as I understand) since it buffers transactions on
    all its ports to eliminate any contention (It supposedly has a 380
    Mbps internal bandwidth).  My customer seems to see it as a panacea
    for all of their network woes (but of course they are still looking
    for an application to try it on).
    
    mjs
    

    From all the information I have seen on Cisco their boxes are routers
    onto FDDI rather than bridges. This has a large impact in terms of
    the delay through the device. A bridge will be in the order for 1ms but a
    router may be an order or two of magnitude more (may be someone who
    knows about routers could supply some details). Most people are
    implementing FDDI to go faster, but if you use a router instead of a
    bridge onto FDDI you will not see any performance gains, in fact it
    will probably be slower than your standard Ethernet bridge! Novell
    networks are particularly sensitive to this since the protocol does no
    real pipelining therefore the client stands still until the message it
    sent to the server comes back. If you consider a server and client on
    two different Ethernets connected by FDDi then the round trip goes
    through 4 Ethernet/FDDI devices. Obviously in these situations (and
    others) the delay through the bridge or router is multiplied by 4 and
    can become highly significant.
    
    							Gary
        

    Gary,
    
    Do you mean the cisco box routes Ethernet (IP, DECnet) packets from
    Ethernet 1 to Ethernet 2 over a FDDI ring ?
    
    Or do you mean the cisco box connects 2 FDDI rings and routes packets
    from one to the other ?
    
    I have trouble understanding what the box does. Thanks in advance for
    the clarification.
    
    Patrick

Re .3: I can't tell from your note whether you are talking about the
observed performance of cisco routers, or making general statements
about routers vs. bridges.

If the latter, then I have to throw in a note of caution.  There is
NO inherent reason for routers to be any slower than bridges.  Depending
on the protocol being routed, it may be a bit harder.  But if a router
has "an order or two of magnitude more" delay than a bridge,  that simply
says something about the implementation of that particular router, not
about the potential of routers in general.

In other words, don't assume that a box, just because it's a router, is
slow.  You might find yourself outsold...

	paul

    Paul,
    
    I'd like to share your enthusiasm. Do you have any good news for us ?
    Some sort of "happy new year, networkers" ?
    
    It is true that the DECrouters I have seen so far could not compete
    with the DECbridges. And surely not with the cisco BRouters. Our
    customers found out ...
    
    Happy new year anyway !

I know we're working on faster routers.  When you'll see those I do not know.
That wasn't actually my point.  With current Digital products, bridges
are certainly the top performers; routers cover a different set of problems
at reduced performance.

My main point was that you should avoid statements that routers are always
slower than bridges: while that is true for many products, it isn't
always valid.  You'd look silly if a customer were to show you data from 
a competitor that performs equally well in both modes.  That's all...

	paul

    I have a network configured as in .3 - the problem is it does not work!
    
    Here is the situation:
    
    An Ethernet LAN connected to an FDDI Ring (DECconcentrator 500) through 
    a DECBridge 500.  Also connected to the DECconcentrator 500 is a Cisco
    AGS+ (as a DAS station).  The AGS+ also has a T1 interface, and is
    connected to another network that is exactly the same.  On paper, this
    should work fine (I know this isn't the best way to connect two FDDI
    rings, but that is another story altogether).  We are trying to boot a
    Novell client on one Ethernet from a server on the other, as well as
    route DECnet and TCP/IP from one Ethernet to the other.  As I said, it
    does not work.
    
    Is there something about IGRP (cisco's proprietary routing protocol)
    that makes this configuration invalid in real life?  Is there something
    about a translated (by the DECBridge) FDDI packet that makes the cisco
    router not understand what it is being sent?  Does anyone have any clue
    as to what the problem is?  Peter Trusevich and George Nielson have
    been enlisted for help...If anyone has done this or something simliar,
    your input is highly appreciated.  We are also looking at Proteon
    P4200's instead of Cisco AGS+'s...I really, really wish our products
    fit this customers needs...
    
    regards,
    
    Patrick 

    You got it. Our bridges are fully translating from Ethernet to FDDI. 
    
    If a bridge is "encapsulating" it is simply packing the packet and then
    forwarding it. You need to change your approach. 
    
    Yes, you are right about the speed. Does the customer intend to upgrade
    to T3 links in the future?

    I thought that tranlating might be the problem - but I need to change
    my approach to what?
    
    Patrick

    re:.9 I'm confused, what does encapsulation have to do with anything
    unless the Novell packets are being bridged rather than routed by the
    Cisco? If the Cisco box is routing the packets, then our translating
    bridge is doing the right thing (unless Novell does something weird
    with their packets like Apple does). It seems to me that I remember
    something about the NetWare protocol using slightly different packet
    formats on Ethernet than everyone else.
    
    DECnet and TCP/IP routing should be working ok at the very least. But
    if you're bridging the Novell, then the problem lies with Cisco's
    proprietary encapsulating bridge, not with our translating one.
    
    Debbie
     

    re. .11  I re-read the problem. It was stated that the configuration
    was the same on both sides. The question is whether the cisco router
    can actually route FDDI packets?
    
    Are you able to put any kind of device onto the Ethernet on the remote
    end to see if you seeing packets from the other side such as LAT or
    multi-cast messages?
    
    Can you turn on the NI configuration process under DECnet to see what
    that sees?

    We have not been able to see any type of packet through the cisco
    router at all.  This was confirmed using cisco's monitoring commands,
    and the packet count never went up.  
    
    There is an MSU at one site, and Ethernim couldn't see the Novell nodes
    at the remote site.  
    
    We have not tried DECnet yet - there is no real reason as there is only
    one DECnet node on the network at this time.
    
    regards,
    
    Patrick

    	Patrick,
    
    No problem/conflict w/IGRP. If IP is failing, run ping from the MSU
    station to the closest CISCO. If this fails, check the MSU's arp table,
    see if the arp completed; if not, the cisco may be using the OLD arp
    hardware type for FDDI = 6, which doesn't work across transparent
    bridges like the DECbridge 500. The newer RFC (1103) calls for FDDI
    nodes to use h/w type =1, same as ethernet, so arps succeed across
    transparent bridges.
    
           If the ping succeeds, try pinging the "remote" Cisco. If this 
    fails, it's a Cisco routing/datalink problem, pure & simple. If you 
    can ping the remote Cisco, try pinging a node on the remote Ethernet. 
    If this fails, use MSU to examine the arp tables on the remote Cisco 
    ("Fault/Query object" pulldown), see if the arp succeeded.
    
    	Re: remote booting- what protocol type is the client using to boot?
    If bootp, the broadcast boot request will *not* be passed through the
    Cisco, if it's routing IP. If it's bridging IP, it should pass.
    Likewise DECNET, is it being bridged or routed? The Cisco's can either
    bridge or route these protocols, but not both. If MOP is used, the MOP
    request can be bridged, but not routed. 
    
        In any case, your topology should work just fine for passing IP
    traffic; use the MSU & see how far your pings get. If the Cisco's debug
    mode shows NO traffic, maybe it's because there's a datalink problem,
    or the Cisco's are mis-genned for routing.
    
    						chuck