From: Robert Laidlaw (laidlaw@consecro.com)
Date: Wed Jul 16 2003 - 17:26:09 GMT-3
no, your right, i did mess up the acl placement.
When I re-did the scenario the right way, R2 with a dmac filter for the
non-canonical address did stop WStest from getting to WStestbox on R1. When
I did a debug dlsw reachability, I saw what I wanted to which was
Received frame type NETBIOS NAME_QUERY from 000d.0b34.6dcb, DL0
04:32:10: CSM: Write to peer 133.1.21.1(2065) not ok - PEER_FILTERED
The netbios name showed up in the "show dlsw reach" but the queries are
filtered. I don't remember, but was the goal to filter the query or to
filter the whole advertisement for the neighbor? Either way, I was totally
wrong and with dlsw you should filter on the non-canonical format as the
router will bitswap automatically on ethernet interface. And the admin has
to manually bitswap for static icanreach.
----- Original Message -----
From: "Glenn Johnson" <gjcomcast@comcast.net>
To: "'Robert Laidlaw'" <laidlaw@consecro.com>; "'Jonathan V Hays'"
<jhays@jtan.com>; <ccielab@groupstudy.com>
Sent: Wednesday, July 16, 2003 2:24 PM
Subject: RE: Ethernet-to-Ethernet DLSW ICANREACH
> Robert,
>
> Quick question --- maybe I'm misinterpreting your scenario -- or maybe
just
> a typo?
>
> From your first example below:
> ------------------------------
> When I went to R1 used an standard mac acl to filter the dlsw
> reachability, the results were not what I expected.
>
> If I used the non-canonical address in the filter,
> access-list 700 deny 000d.0b28.6c94 <-[?? The non-c
> mac address of TESTBOX on R1]
> access-list 700 permit 0.0.0 ffff.ffff.ffff
>
> dlsw remote-peer 0 tcp 133.1.21.2 dmac-output-list 700
<-[Presumably
> configured on R1, pointing to R2]
>
> This did not filter the reachability or stop Test from reaching
> Testbox.
> ------------------------------
>
> This example looks like you are trying to control which MAC
> addresses that hosts on R1, e.g., TESTBOX, can access over a dlsw circuit
> (in this case, to R2). Why would we place a connected host's MAC address,
> canon or non-canon, in such a list? My understanding (perhaps flawed) of
> this is that if you wanted to run the test I think you want to run, you
> would specify the MAC address of TEST (the box on the other side of the
DLSW
> circuit) in your dmac-output-list on R1 in either canon or non-canon
format
> to test your scenario and see under what conditions TESTBOX can access
TEST
> (via its MAC address) across the DLSW circuit. Is this what you are
trying
> to test?
>
> Thanks
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Robert Laidlaw
> Sent: Wednesday, July 16, 2003 2:37 PM
> To: Jonathan V Hays; ccielab@groupstudy.com
> Subject: Re: Ethernet-to-Ethernet DLSW ICANREACH
>
>
> My lab setup is this:
>
> WS = Testbox --- e0 R1 s0 --s0 R2 e0 --- WS=Test
>
> Like Jonathan has below, the "show bridge" shows the canonical mac and the
> "show dlsw reach" shows the non-canonical mac.
>
> Mac of Testbox= 00b0.d014.3629
> Mac of Test= 00b0.d02c.b6d3
>
> r2#sh dlsw reach
> DLSw Local MAC address reachability cache list
> Mac Addr status Loc. port rif
> 000d.0b34.6dcb FOUND LOCAL TBridge-001 --no rif--
>
> DLSw Remote MAC address reachability cache list
> Mac Addr status Loc. peer
> 000d.0b28.6c94 FOUND REMOTE 133.1.21.1(2065) max-lf(1500)
>
> DLSw Local NetBIOS Name reachability cache list
> NetBIOS Name status Loc. port rif
> TEST FOUND LOCAL TBridge-001 --no rif--
>
> DLSw Remote NetBIOS Name reachability cache list
> NetBIOS Name status Loc. peer
> TESTBOX FOUND REMOTE 133.1.21.1(2065) max-lf(1500)
>
> For the output, it looks as though all mac's in the dlsw reachability,
even
> locals, are in non-canonical format.
>
> When I went to R1 used an standard mac acl to filter the dlsw
reachability,
> the results were not what I expected.
>
> If I used the non-canonical address in the filter,
> access-list 700 deny 000d.0b28.6c94
> access-list 700 permit 0.0.0 ffff.ffff.ffff
>
> dlsw remote-peer 0 tcp 133.1.21.2 dmac-output-list 700
>
> This did not filter the reachability or stop Test from reaching Testbox.
>
> If I used the canonical address in the filter
> access-list 700 deny 00b0.d014.3629 0000.0000.0000
> access-list 700 permit 0000.0000.0000 ffff.ffff.ffff
>
> this did stop the advertisement and Test could NOT reach testbox.
>
> So with these results, you should filter based on the actual mac address
of
> the machine. However, when entering static "icanreach" you should do the
> bitswapping first as the mac you enter in the icanreach is taken as a
> literal.
>
>
>
> > >
> > > Well, you are right that we are all just talking theory. And
> > > admittedly the Doc CD is full of errors so we can't believe that
> > > source either.
> > >
> > > We need to configure a real-world workstation-to-workstation
> > > scenario and post some actual results. Otherwise it's all talk.
> > >
> > > Anyone got a pair of NetBEUI workstations, one with TR and one with
> > > ethernet?
> >
> >
> > I was still puzzling about this so I decided to experiment a bit. I
> > generated a single NetBEUI ethernet workstation and connected it to a
> > router - not the full test bed.
> >
> > I found out one thing for sure: the IOS bridge function ("sh bridge")
> > sees the ethernet mac address as canonical and the DLSW function ("sh
> > dlsw reachability") sees the same mac address as non-canonical (see
> > below for output). IOS is clearly converting the ethernet address to
> > non-canonical format for use in DLSW.
> >
> > I personally am planning to stick with manual conversion of ethernet
> > mac addresses to non-canonical format before typing them into a DLSW
> > filter, until someone can prove otherwise.
> >
> > I am still not clear on a test procedure to prove which format
> > (canonical vs. noncanonical) will cause correct operation of DLSW
> > filtering. I think I would need two workstations, though. Can anyone
> > suggest a good procedure?
> > > See below for what I found (it's long and inconclusive).
> >
> > -Jonathan
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:42 GMT-3