From: chahal (bob.chahal@xxxxxxxxxxxx)
Date: Wed May 23 2001 - 05:48:58 GMT-3
I'll recheck my resources (CCO, design guide etc) but when I last did some
lab work on netbios filtering I found that netbios filters only impacted on
explorer name queries. I must admit if was not easy testing this with PCs
but that is what I found.
----- Original Message -----
From: Roman Rodichev <rodic000@hotmail.com>
To: <bob.chahal@ntlworld.com>; <fwells12@hotmail.com>;
<ccielab@groupstudy.com>
Sent: Wednesday, May 23, 2001 2:08 AM
Subject: Re: DLSW netbios name filtering (More on Netbios)
>
> just thinking further on this, this doesn't apply to the question asked
> (because dlsw icanreach was defined), but might help some people. let's
say
> netbious access-list denies name PC
>
> host-netbios-out will do FOUR things:
>
> 1. it will block explorers to remote PC
> ---> Destination name in Netbios command 0A (NAME_QUERY)
>
> 2. it will block local hosts talking to remote PC
> ---> Destination name in Netbios command 08 (DATAGRAM)
>
> 3. it will block local hosts from responding to name queries coming from
> remote PC
> ---> Destination name in Netbios command 0E (NAME_RECOGNIZED)
>
> 4. it will block local host that has the name PC from verifying if it's
> using a duplicate name on the network, so this frame will not be sent
across
> to the remote peer.
> ---> Source name in Netbios commands 00 and 01 (ADD_GROUP_NAME_QUERY and
> ADD_NAME_QUERY) (by the way, destination name is not used in these two
> frames)
>
> So, to summarize, you are simply blocking local hosts talking to remote
host
> PC. But if you have local host PC, remote hosts will be able to talk to
it.
>
> just my two cents
>
> Roman
>
>
>
> >From: "Bob Chahal" <bob.chahal@ntlworld.com>
> >Reply-To: "Bob Chahal" <bob.chahal@ntlworld.com>
> >To: "fwells12" <fwells12@hotmail.com>, "CCIE newsgroup \(E-mail\)"
> ><ccielab@groupstudy.com>
> >Subject: Re: DLSW netbios name filtering
> >Date: Tue, 22 May 2001 20:53:33 +0100
> >
> >I though that
> >
> >dlsw remote-peer 0 tcp 137.20.5.1 host-netbios-out famallowed
> >
> >would actually prevent local hosts from being able to locate netbios host
> >with the names in "famallowed". And if the icanreach statements are an
> >indications of hosts on the local segements attached to the router then
> >phil
> >greg and jay are local netbios hosts. Therefore the statement above will
> >have no effect at all as phil will never send a netbios find name for
> >itself
> >(apart from check for duplicate netbios names).
> >
> >----- Original Message -----
> >From: "fwells12" <fwells12@hotmail.com>
> >To: "CCIE newsgroup (E-mail)" <ccielab@groupstudy.com>
> >Sent: Tuesday, May 22, 2001 5:05 PM
> >Subject: Re: DLSW netbios name filtering
> >
> >
> > > I second Jims reasoning.
> > >
> > > ----- Original Message -----
> > > From: Jim Graves <jtg@lucent.com>
> > > To: Virnoche, Phil <phil.virnoche@attws.com>; <ccielab@groupstudy.com>
> > > Sent: Tuesday, May 22, 2001 7:53 AM
> > > Subject: Re: DLSW netbios name filtering
> > >
> > >
> > > > I believe the netbios names are showing up because you have them
> > > explicitly
> > > > listed in "icanreach" statements. An "icanreach" entry tells a
> >router's
> > > > DLSW peers that it can get to something, without having to bother
with
> > > > explorers first. So "icanreach" trumps a netbios access-list when
it
> > > comes
> > > > to something showing up in the reachability cache -- the remote DLSW
> >peer
> > > > don't even try to reach the "icanreach" hosts. The netbios
> >access-list
> > > > only comes into play when netbios traffic comes across the line.
> > > >
> > > > If you had actual workstations with these names, you would notice
that
> > > > phil, greg, and jay can do their netbios thing, while the others
> > > > wouldn't. The netbios access-list would take effect when the
> >workstations
> > > > tried to use file sharing or such.
> > > >
> > > > At 07:24 AM 5/22/2001 -0700, Virnoche, Phil wrote:
> > > > >Gang-
> > > > >
> > > > >I'm trying to practice netbios name filtering in DLSW..... to no
> >avail.
> > > Even
> > > > >after a clear dlsw reach at R5 (remote-peer) ALL netbios names
> > > appear......
> > > > >What am i missing?
> > > > >
> > > > >hostname r1
> > > > >!
> > > > >netbios access-list host famallowed permit phil
> > > > >netbios access-list host famallowed permit greg
> > > > >netbios access-list host famallowed permit jay
> > > > >netbios access-list host famallowed deny .*
> > > > >
> > > > >
> > > > >source-bridge ring-group 100
> > > > >dlsw local-peer peer-id 137.20.1.1
> > > > >dlsw remote-peer 0 tcp 137.20.5.1 host-netbios-out famallowed
> > > > >dlsw icanreach mac-address 0020.3539.0ef9 mask ffff.ffff.ffff
> > > > >dlsw icanreach netbios-name tracy
> > > > >dlsw icanreach netbios-name jay
> > > > >dlsw icanreach netbios-name dana
> > > > >dlsw icanreach netbios-name greg
> > > > >dlsw icanreach netbios-name todd
> > > > >dlsw icanreach netbios-name phil
> > > > >dlsw icanreach netbios-name tony
> > > > >dlsw icanreach netbios-name scot
> > > > >
> > > > >
> > > > >r5#sh dlsw rea
> > > > >DLSw Local MAC address reachability cache list
> > > > >Mac Addr status Loc. port rif
> > > > >000a.f0e4.34de FOUND LOCAL TBridge-001 --no rif--
> > > > >
> > > > >DLSw Remote MAC address reachability cache list
> > > > >Mac Addr status Loc. peer
> > > > >0020.3539.0ef9 UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >
> > > > >DLSw Local NetBIOS Name reachability cache list
> > > > >NetBIOS Name status Loc. port rif
> > > > >
> > > > >DLSw Remote NetBIOS Name reachability cache list
> > > > >NetBIOS Name status Loc. peer
> > > > >dana UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >greg UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >jay UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >phil UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >scot UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >todd UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >tony UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >tracy UNCONFIRM REMOTE 137.20.1.1(2065)
> > > > >
> > > > >Suggestions?
> > > > >
> > > > >Philip G. Virnoche
> > > > >Sr. Network Engineer - AT&T Wireless
> > > > >phone: 425.580.5239
> > > > >cell: 206.601.3134
> > > > >"HAM AND EGGS - A day's work for a chicken; A lifetime commitment
for
> >a
> > > > >pig."
> > > > >
> > > > >
> > > > >
> > > > >-----Original Message-----
> > > > >From: Wayne Gustavus [mailto:wgustavus@mentortech.com]
> > > > >Sent: Tuesday, May 22, 2001 6:51 AM
> > > > >To: 'Rick Stephens'; ccielab@groupstudy.com
> > > > >Subject: RE: OT: 4 weeks and counting
> > > > >
> > > > >
> > > > >I agree there isn't much time difference between "si" and "sh ip
int
> > > brief"
> > > > >if you are a good typist. The potential speed gain is avoiding
> >typing
> > > > >mistakes. If you are trying to type very fast and have a slight
case
> >of
> > > the
> > > > >nerves, you may type "sh ip int bri" and then "sh ipi nt brief",
> >neither
> > > of
> > > > >which will give you the intended result (the first depends on what
> >router
> > > > >you type it on). It is a whole lot harder to mess up "si".
> > > > >
> > > > >I used a list of about 10 alias commands that I found to be very
> >helpful,
> > >
> > > > >even though I am a good, quick typist. The trick is to create your
> >list
> > > > >early and don't get carried away. You need to have the list
> >memorized
> > > long
> > > > >before you get into the exam and be able to type in the list in
your
> > > > >scratchpad to paste into each router without even thinking.
> > > > >
> > > > >The alias cmds should be second nature by the time your lab date
> >comes
> > > up.
> > > > >For example, in them middle of my exam, the proctor asked me to do
a
> >sho
> > > ip
> > > > >route and I entered "sir" without even thinking. If you are only 4
> >weeks
> > > > >from your lab and haven't started using alias cmds, you may not
want
> >to
> > > > >start; depends on how much lab time you plan during this time.
> > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:50 GMT-3