From: Scott Morris (swm@emanon.com)
Date: Sat Mar 05 2005 - 13:06:00 GMT-3
There ya go! :) Light bulbs are a'flickerin'!
Scott
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Saturday, March 05, 2005 10:54 AM
To: Scott Morris
Cc: Group Study
Subject: FW: dlsw icanreach
Scott,
You're the best. I was still writing the note below when you're response
came. You beat me to it, but finally, I think I've got it.
What makes this topic so confusing for me and others is that the distinction
between explorer traffic and other traffic isn't highlighted (or, in my
case, pounded into my head).
To really understand this, we have to realize that the icanreach and
icannotreach commands directly affect explorer traffic because this info is
exchanged during the cap exchange process when the peers are coming up. But,
these commands don't necessarily block user traffic because static routes
can be used to direct user traffic without explorers having been sent.
ACL's, on the other hand, will directly affect both explorer and user
traffic. So, if you have to block a certain type of traffic, you have to
use acl's. Using just icanreach or icannotreach commands might or might NOT
block the traffic in question depending on how the sending router is
configured.
From a practical point of view, if the sending dlsw peer doesn't have any
dlsw static paths configure, the affect of the icanreach commands is the
same as with acl's, but from the point of view of the lab, using acl's to
block the unwanted traffic is more correct.
--------------------
I was writing the note below when your response came in.
OK, after thinking about and re-reading your last post, maybe I can answer
my own question regarding the differences between the 2 Solutions from my
previous post.
Both solutions prevent explorers for netbios traffic from rtr-2 going to
rtr-1. However, solution 1 doesn't explicitly prevent netbios traffic from
rtr-2 to rtr-1 because it's possible that rtr-2 could be configured with a
static dlsw route that directs netbios traffic to rtr-1 in which case
there's no need rtr-2 to send out any explorers to find netbios
destinations.
Solution 2, on the other hand, prevents explorers for netbios traffic AND
the netbios traffic itself.
Regarding the netbios acl, do we have a choice on where it's applied?
Assume rtr-2 using int s0 to connect to rtr-1.
rtr-2
access-list 200 permit 0x0000 0x0d0d
Case 1:
dlsw remote-peer 0 tcp <rtr-1> lsap-output-list 200
or
Case 2:
int s0
ip access-group 200 out
My assumption is that case 1 is more specific than case 2. If rtr-2 only
has 1 dlsw peer, case 1 and 2 amounts to the same thing. However, if rtr-2
has multiple dlsw peers, but netbios traffic should only be filtered to
router-1, then case 1 and 2 are very different because case 2 will filter
netbios traffic to all peers, not just rtr-1. Correct?
Thanks again, Tim
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Saturday, March 05, 2005 9:19 AM
To: 'swm@emanon.com'; 'Steve Connolly'
Cc: 'Group Study'
Subject: RE: dlsw icanreach
Scott,
Thank you and darnit - apparently I'm not quite there.
OK, same scenario as before: 2 dlsw peers - rtr-1 and rtr-2
Requirement: No netbios traffic from rtr-2 to rtr-1
Solution 1:
rtr-1 config:
dlsw icanreach sap 04 05 <- is 05 needed here?
dlsw icannotreach sap F0
Solution 2:
rtr-2
access-list 200 permit 0x0000 0x0d0d
dlsw remote-peer 0 tcp <rtr-1> lsap-output-list 200
Question: What's the difference between these 2 solutions and will they both
fulfill the stated requirement?
Thanks for all your patience with me. I really appreciate it.
(BTW, my lab is in 10 days and if it doesn't have dlsw on it, I'll be really
po'd).
Tim
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Saturday, March 05, 2005 8:48 AM
To: 'ccie2be'; 'Steve Connolly'
Cc: 'Group Study'
Subject: RE: dlsw icanreach
You are correct about the netbios hosts and exclusive stuff...
You're almost there on the SAPs. The fact that you specify an "icanreach
saps" just pre-populates a peers list of things you can do to prevent any
asking. It does not automatically preclude anything else. We can, however,
do a "icannotreach saps" which will tell the peer to not forward any
explorers of a particular traffic type. So don't ask, 'cause I can't get
there.
Saying you cannot reach netbios doesn't imply anything about SNA, so you
will still get asked about sna. You may just need to remember 04 is SNA
(the 04/05 pair anyway). :)
For filtering ONLY sna traffic, that would end up being an lsap-output-list
permitting only SNA traffic to go and blocking everything else. An
icannotreach doesn't explicitly block any traffic, it just prevents anything
being asked about. In other words if you had a static "dlsw route" you
would still send traffic out that link without asking about reachability.
It's a bit esoteric, but IMHO if they tell you a particular type of traffic
is not allowed over a connection, then that implies more than just saying
"don't ask me", it implies filtering.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Saturday, March 05, 2005 7:51 AM
To: swm@emanon.com; 'Steve Connolly'
Cc: 'Group Study'
Subject: RE: dlsw icanreach
Hi Scott,
Thanks for chiming in on this thread. I think I understand this now but let
me make sure.
Assume for these examples rtr-1 is peering with rtr-2 and all config's are
done on rtr-1.
If only the command, icanreach netbios-name <name>, is used, then rtr-2 will
forward explorers for all other resources except the name(s) specified. In
this case, rtr-2 will know about the netbios host(s) specified on rtr-1 but
this doesn't mean or imply that the specified host(s) are the ONLY hosts
reachable via rtr-1.
If the command icanreach netbios-exclusive is added, then rtr-2 will NOT
forward explorers for any resources to rtr-1 because rtr-2 knows exactly
what can and can NOT be reached via rtr-1.
The same logic applies if icanreach mac-addr is used instead.
If the command, icanreach sap F0 is used, the logic is a bit different.
When sap is used, this is referring to a type of traffic (or hosts
supporting this type of traffic). Therefore, when sap F0 is specified, it
means that ONLY netbios hosts can be reached - peers shouldn't bother to
send explorers for sna hosts because no sna hosts are reachable via rtr-1.
So far, so good?
I still have one remaining question. Let's say I don't know the sap to use
for sna traffic (which I don't).
Are the following commands equivalent?
icannotreach sap F0 =? icanreach sap (sna traffic)
The above should be true if in the world of dlsw there are only 2 types of
traffic: netbios or sna. But, I don't know if that's true.
Also, suppose the lab requirement were something like this:
Configure your network such that only sna traffic transits the network
between rtr-1 and rtr-2. And, there's an IBM mainframe attached to rtr-1.
If I used, icannotreach sap F0, would that lose me points?
Thanks, Tim
-----Original Message-----
From: swm@emanon.com [mailto:swm@emanon.com]
Sent: Friday, March 04, 2005 9:35 PM
To: ccie2be; 'Steve Connolly'
Cc: Group Study
Subject: RE: dlsw icanreach
Actually, it's a little backwards....
The "dlsw icanreach" command is used to populate the tables sent during peer
capabilities or "canureach" requests. It is what you tell people who want
to ask you questions.
If you use the netbios-exclusive, that has to do with a host entry. And
that says to the peer, I can reach this host and only this/these hosts, so
don't ask me about any other.
The SAP will be the one that says I only know about netbios. The icanreach
netbios-exclusive is about hosts and it doesn't rule out mac reachability.
HTH,
Scott
---- Message from "ccie2be" <ccie2be@nyc.rr.com> at 2005-03-04 17:11:37
------
>Hey Steve,
>
>
>
>Thanks for your response and that link. It's a good link. I've studied
>it quite a bit.
>
>
>
>But, the CR and that link don't really address my question.
>
>
>
>The way I understand it, when dlsw icanreach sap F0 is configured on a
>dlsw peer, it only prevents explorers from other peers for that
>particular
sap.
>If other peers need to reach an SNA, they'll send out explorers looking
>for the SNA host.
>
>
>
>My question was whether I could use the dlsw icanreach
>netbios-exclusive command in this scenario so that peers of this router
>will NOT send explorers for SNA traffic because they know that this
>peer can only reach netbios hosts.
>
>
>
>TIA, Tim
>
>
>
>
>
>
>
> _____
>
>From: Steve Connolly [mailto:sconnolly@aisnets.com]
>Sent: Friday, March 04, 2005 4:59 PM
>To: ccie2be
>Subject: RE: dlsw icanreach
>
>
>
>When using the icanreach saps command, the sap that you list is the
>only
sap
>type that will be reachable through the peer.
>
>
>
>This is from the cisco web site:
>
>
>
>Configuring the dlsw icanreach saps command is useful when you know
>exactly what type of traffic is allowed and you want to make sure that
>all other traffic is denied. For example, when you configure dlsw
>icanreach saps 4, you are explicitly denying all saps except 0x04 (and
0x05, the response).
>
>Check out this link. It is a good reference for filtering dlsw traffic.
>
>http://www.cisco.com/warp/public/697/dlswfilter.shtml#sapfilter3
>
>Steve Connolly
>
>-----Original Message-----
>From: nobody@groupstudy.com on behalf of ccie2be
>Sent: Fri 3/4/2005 3:45 PM
>To: Group Study
>Cc:
>Subject: dlsw icanreach
>
>Hi guys,
>
>
>
>Does this config make sense?
>
>
>
>I want to advertise that this peer can only reach netbios hosts.
>
>
>
>dlsw icanreach sap F0
>
>dlsw icanreach netbios-exclusive
>
>
>
>I'm not sure if the netbios-exclusive command can be used in this way
>or if this command is only good when one host is specified.
>
>
>
>Can someone let me know?
>
>
>
>TIA, Tim
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:41 GMT-3