Re: bitswap-layer3-addresses

From: Rick Burts (burts@xxxxxxxxxxxxxx)
Date: Sun Jul 01 2001 - 08:48:20 GMT-3


   
John

The original question had to do with the command bitswap-layer3-address.
The function of that command is to go into the layer 3 payload of certain
packets (where the MAC is part of the payload) and perform the canonical/
non canonical bitswap). If an Ethernet station sends a canonical MAC in
a reply to a Token Ring station as part of the payload (think IPX GNS for
example) and the non-canonical Token Ring station uses that MAC as the
destination address without bitswaping, the frame will not contain the
correct address after it goes through the bridge.

Rick

Rick Burts, CCSI CCIE 4615 burts@mentortech.com
Mentor Technologies 240-568-6500 ext 6652
133 National Business Parkway 240-568-6515 fax
Annapolis Junction, Md 20701

Chesapeake Network Solutions has now become Mentor Technologies.
Mentor Technologies is a certified Cisco Training Partner and also
a Cisco Professional Services partner.
We offer most of the Cisco training courses.
We also offer training in Checkpoint Firewall software and
Fore Systems (now Marconi) and MicroMuse.
We also provide network consulting services including
design, management, and problem solving.
We have 21 CCIEs on our staff.
We offer the breakthrough VLAB remote access technology for
access to practice configuration on real equipment.

On Sat, 30 Jun 2001, John Elias wrote:

> Rick,
> Everything you are saying is true, but I thought that the
> canonical/non-canonical bit ordering was only for the 2nd layer(MAC). How
> is it involved with the 3rd layer(IP/IPX/etc.)?
>
> John
>
>
> >From: Rick Burts <burts@mentortech.com>
> >Reply-To: Rick Burts <burts@mentortech.com>
> >To: Brian <signal@shreve.net>
> >CC: ccielab@groupstudy.com
> >Subject: Re: bitswap-layer3-addresses
> >Date: Sat, 30 Jun 2001 11:56:08 -0400 (EDT)
> >
> >There have been a couple answers to this but I would like to take a
> >slightly different approach to this. bitswap-layer3-address is
> >needed when transparent bridging is used between Ethernet and Token
> >Ring. (The reason it is needed is to process when a MAC address is
> >included in the payload of the frame as well as in the data link header
> >and this will compensate for the canonical/non-canonical bit ordering.)
> >It is obvious that SRT is doing transparent bridging and needs bitswap.
> >It may not be quite as obvious (but it is true) that SR/TLB is also
> >doing transparent bridging and may need bitswap.
> >
> >Rick
> >
> >Rick Burts, CCSI CCIE 4615 burts@mentortech.com
> >Mentor Technologies 240-568-6500 ext 6652
> >133 National Business Parkway 240-568-6515 fax
> >Annapolis Junction, Md 20701
> >
> >Chesapeake Network Solutions has now become Mentor Technologies.
> >Mentor Technologies is a certified Cisco Training Partner and also
> >a Cisco Professional Services partner.
> >We offer most of the Cisco training courses.
> >We also offer training in Checkpoint Firewall software and
> >Fore Systems (now Marconi) and MicroMuse.
> >We also provide network consulting services including
> >design, management, and problem solving.
> >We have 21 CCIEs on our staff.
> >We offer the breakthrough VLAB remote access technology for
> >access to practice configuration on real equipment.
> >
> >On Tue, 26 Jun 2001, Brian wrote:
> >
> > > A few questions about the "bitswap-layer3-addresses" directive.
> > >
> > > I am just trying to nail down when this command is really
> > > required. I know that if I have a token ring interface
> > > and a ethernet interface on a router, and I am doing SRT
> > > between them, then I need it like so:
> > >
> > >
> > > int token0
> > > bridge-group 1
> > >
> > > int ethernet0
> > > bridge group 1
> > >
> > > bridge 1 protocol ieee
> > > bridge 1 bitswap-layer3-addresses
> > >
> > >
> > > But the documentation at cisco.com mentions SR/TB as well.
> > >
> > > I am confused as to when you would use it with SR/TB, can
> > > someone show a quick example of where you would want to use
> > > it with something other than SRT?
> > >
> > > Brian
> > >
> > > -----------------------------------------------
> > > Brian Feeny e:signal@shreve.net
> > > CCNP+Voice/ATM/Security p:318.222.2638x109
> > > CCDP f:318.221.6612
> > > Network Administrator
> > > ShreveNet Inc. (ASN 11881)
> > > **Please read:http://www.groupstudy.com/list/posting.html
> >**Please read:http://www.groupstudy.com/list/posting.html



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:28 GMT-3