From: fingham@cox.net
Date: Thu Dec 05 2002 - 17:22:21 GMT-3
Solomon: the dlsw icanreach command requires non-canonical addressing so if 4000.4000.4000 is on a TR segment it is already in non-canonical format. (an aside - this is a valid TR admin-assigned address, not a valid EN admin-assigned address)
As a previous post said DLSW uses only non-canonical addresses. When a station on EN has a session with another EN station, DlSW converts the address on the source end to non-canonical and then back to canonical at the destination end.
HTH, Fred
>
> From: Solomon Ghebremariam <sghebrem@cisco.com>
> Date: 2002/12/05 Thu PM 02:09:00 EST
> To: "Scott" <scpage@cisco.com>
> CC: "Teisberg, Evan" <eteisbe@qwest.com>,
> "'MOLINA, MARTIN J \(PBI\)'"
> <mm1343@sbc.com>,
> <ccielab@groupstudy.com>
> Subject: RE: DLSW ICANREACH/ICANTREACH in a pure Ethernet Environment
>
> Scott
> What if the segment on R2 is Ether and the segment on R4 is TR and
> only 4000.4000.4000 is available on the R4 segment? You would do byte swap
> when putting icanreach on R4?
>
> Thanks
> Solomon
>
> At 11:53 PM 12/4/2002 -0500, Scott wrote:
> >Hmm,
> >
> >Well riddle me this ;-)....
> >
> >The only reason the MAC is sent non canonical is because of token ring
> >adaptors. If you dont have any token ring, then all bits should be
> >outpulsed and read the same. I dont see the need to bit swap in pure
> >ethernet environment.
> >
> >If you are token ring sending me (ethernet) a MAC, then obviously I need to
> >read it backwards per byte.
> >
> >Guess I will go read the source code.
> >
> >
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >Teisberg, Evan
> >Sent: Tuesday, December 03, 2002 5:03 PM
> >To: 'MOLINA, MARTIN J (PBI)'; 'ccielab@groupstudy.com'
> >Subject: RE: DLSW ICANREACH/ICANTREACH in a pure Ethernet Environment
> >
> >
> >The way I understand it is:
> >
> >In the "dlsw world", mac-addresses are always in NON-CANONICAL format.
> >The explorers sent from devices on Ethernet segments are sent in CANONICAL
> >format.
> >
> >So, if the requirement is to never send explorers for mac-address
> >4000.4000.4000, I would say that the following is correct:
> >
> >dlsw icanreach mac-exclusive
> >dlsw icanreach mac-address 0200.0200.0200 mask ffff.ffff.ffff
> >
> >If explorer is sent from an Ethernet device on LAN A, the router
> >automatically flips the mac to NON-CANONICAL in the "dlsw world", thus
> >changing it to 0200.0200.0200. It then forwards it across dlsw and it is
> >flipped back to 4000.4000.4000 on the other router (LAN B) Ethernet segment.
> >
> >While the explorer is in the "dlsw world" it is address 0200.0200.0200.
> >
> >The address (0200.0200.0200) needs to be specified in the "dlsw icanreach"
> >command since you are in the "dlsw world" at this point
> >
> >Someone please correct me if I'm wrong about this.
> >
> >Thanks!
> >
> >-Evan.
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: MOLINA, MARTIN J (PBI) [mailto:mm1343@sbc.com]
> >Sent: Tuesday, December 03, 2002 12:20 PM
> >To: 'ccielab@groupstudy.com'
> >Subject: DLSW ICANREACH/ICANTREACH in a pure Ethernet Environment
> >
> >
> >Hello,
> >I'm not sure this post will make it to the group since I have had trouble in
> >the past but here it goes:
> >
> >If one were presented with the following requirement:
> >"Config R4 to peer to R2. Ensure that R2 never sends explorers for
> >4000.4000.4000 which is the only resource available through R4"
> >R2 and R4 are Ethernet only. My question is this- If I choose to configure a
> >DLSW ICANREACH statement on R4 to satisfy this requirement, should the
> >command be :
> >dlsw icanreach mac-exclusive
> >dlsw icanreach mac-address 0200.0200.0200 mask ffff.ffff.ffff
> >or
> >dlsw icanreach mac-exclusive
> >dlsw icanreach mac-address 4000.4000.4000 mask ffff.ffff.ffff
> >In other words, do I need to bit-swap in an Ethernet only environment?
> >Thanks in advance
> >
> >
> >
> >Martin Molina
> >Senior Network Engineer
> >SBC (Pacific Bell) Internet Services
> >CCNP CCDP
> >desk: (925) 973-7774
> >cell: (925) 216-5299
> .
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:39 GMT-3