From: Jim Graves (jtg@xxxxxxxxxx)
Date: Tue May 22 2001 - 11:53:24 GMT-3
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:48 GMT-3