Transparent bridging over Frame Relay - Problem

Transparent bridging over Frame Relay - Problem

Post by Paul Fergus » Wed, 22 Feb 1995 04:30:15




> We have a large number of Ungermann Bass hubs whose supervisor cards can
> only receive thier configuration via a network download. This download is
> done using UB's ethernet frames (ethertype 7000 ->7002) .... it goes
> without saying that this is not routable. So in short we have 15 PVC's,
> all 32k CIR's on 56k circuits terminated in Cisco routers mapped back to
> a single hub Cisco with a 384k circuit. IP is mapped to each site as is
> bridging - but only for the UB ethertype (access-list protected).
> The UB download is initiated by a broacast from the supervisor card at
> the remote location, when this is seen by the management system at the
> hub site it is replied to. The reply is addressed to the HW address of
> the remote supervisor card. This data is NOT just sent on the PVC that
> the remote supervisor is on BUT is sent on all the PVC's mapped to that
> interface of the hub router. You can guess what that does to our
> bandwidth utilization.
> I don't know if this is a bug in 9.14(7) - which we are running - or if
> we have something wrong in our configuration. If it is a bug does anyone
> know in what release it is fixed. If someone can help copies of the
> configurations can be passed on.
> The remote supervisor HW addresses are in the bridging tables and are
> associated with a DLCI (the correct DLCI) so in theory the router should
> not be sending the data to other DLCI's ....... should it ?

Ah, the evils of bridging.  :-)

All broadcasts generated are _replicated_ on each PVC, to include
bridged traffic.

- paul

--
_______________________________________________________________________________
Paul Ferguson                        
US Sprint                                          tel: 703.689.6828

Reston, *ia  USA                             http://www.veryComputer.com/

 
 
 

Transparent bridging over Frame Relay - Problem

Post by Brett Frankenberg » Wed, 22 Feb 1995 05:56:59





>> We have a large number of Ungermann Bass hubs whose supervisor cards can
>> only receive thier configuration via a network download. This download is
>> done using UB's ethernet frames (ethertype 7000 ->7002) .... it goes
>> without saying that this is not routable. So in short we have 15 PVC's,
>> all 32k CIR's on 56k circuits terminated in Cisco routers mapped back to
>> a single hub Cisco with a 384k circuit. IP is mapped to each site as is
>> bridging - but only for the UB ethertype (access-list protected).
>> The UB download is initiated by a broacast from the supervisor card at
>> the remote location, when this is seen by the management system at the
>> hub site it is replied to. The reply is addressed to the HW address of
>> the remote supervisor card. This data is NOT just sent on the PVC that
>> the remote supervisor is on BUT is sent on all the PVC's mapped to that
>> interface of the hub router. You can guess what that does to our
>> bandwidth utilization.

>> The remote supervisor HW addresses are in the bridging tables and are
>> associated with a DLCI (the correct DLCI) so in theory the router should
>> not be sending the data to other DLCI's ....... should it ?

>Ah, the evils of bridging.  :-)

>All broadcasts generated are _replicated_ on each PVC, to include
>bridged traffic.

Yes, but the original question is not about broadcast traffic.  It is
about the non-broadcast traffic sent back to the hub (with a
destination MAC address of that hub).  The bridge tables show which
DLCI that address is on, but the frame (according to the original
poster) is being sent out *all* the PVCs anyway.

The only time that it would seem that should happen is if the
destination MAC is broadcast, or if the destination MAC is unknown.
--


------------------------------------------------------------------------------
                               ... Coming soon to a      | Brett Frankenberger


 
 
 

Transparent bridging over Frame Relay - Problem

Post by Tim Verra » Wed, 22 Feb 1995 10:48:30





: >
Lots of stuff deleted ....

..... This is the main part of my question with regards to this problem,
the return packets are addressed to the HW address of the remote
supervisor card and the .......

: >
: >> The remote supervisor HW addresses are in the bridging tables and are
: >> associated with a DLCI (the correct DLCI) so in theory the router should
: >> not be sending the data to other DLCI's ....... should it ?
: >
: >
: >Ah, the evils of bridging.  :-)

And don't I wish I could find another way to do this ... but alas I
digress from the problem at hand

: >All broadcasts generated are _replicated_ on each PVC, to include
: >bridged traffic.

If the frames were broadcast frames I would expect this ....

: Yes, but the original question is not about broadcast traffic.  It is
: about the non-broadcast traffic sent back to the hub (with a
: destination MAC address of that hub).  The bridge tables show which
: DLCI that address is on, but the frame (according to the original
: poster) is being sent out *all* the PVCs anyway.

: The only time that it would seem that should happen is if the
: destination MAC is broadcast, or if the destination MAC is unknown.
: --

Here I must agree with Brett, this is what I expect to see but I don't ....

--

=========================================================================
Tim Verrall                             Voice int(408)577-0707 ex1254 (w)
Axis Consulting International                 int(408)992-0838 (h)

San Francisco, California 94111        
USA                                
=========================================================================

 
 
 

1. Transparent bridging across Frame Relay

I have the following configuration:

                           +------+
                       +---| 3102 |
                       |   +------+
                       |
+------+    +------+   |   +------+
| host |-//-| AGS+ |---+---| 3102 |
+------+    +------+   |   +------+
                       |
                       |   +------+ |
       Frame relay --> +---| IGS  |-+
         network           +------+ |   +----+
                                    +---| PC |
                                        +----+

The PC is trying to talk to the host using Ethernet type 81D5 (IBM SNA
services over Ethernet).  To provide the connection, I enabled transparent
bridging over the Frame Relay network.  This doesn't work.  If I examine
the bridge forwarding tables, I see something like this:

On the IGS:

Address     Action    Interface    DLCI   Age   RX count    TX count
PC_MAC      Forward   Ethernet0      -     0       64           0

and on the AGS+:
Address     Action    Interface    DLCI   Age   RX count    TX count
PC_MAC      Forward   Serial1       16     0       64          64
HOST_MAC    Forward   Ethernet0      -     0       64          64

Some additional information: The Frame relay network is not fully meshed.
We have IP, AppleTalk and Novell running from the AGS+ to the other
routers.  Bridging is only enabled between the AGS+ and the IGS.
The AGS+ is running 9.1(4), the serial interface is an MCI at 56Kbps and
the IGS is running 9.1(4) as well.
--

Systems and Network Administrator  |  US Mail:  371F Durham Center
                                   |            Iowa State University
(515)294-7588                      |            Ames, Iowa  50011-2163

2. IPAQ successor?

3. Multicast Ethernet and Transparent Bridging over Frame Relay

4. Wallpaper on a Series 5

5. Source-bridging problem over frame-relay

6. Philips2610 and DAO

7. Source-bridged traffic over Frame Relay Problem

8. Looking for the student lab manual CCNPv3.0

9. Source-Bridge over Frame Relay Problem (SOLVED!!!)

10. frame-relay interface-dlci vs frame-relay local-dlci

11. One Way Frame Relay Traffic+Frame Relay Switching