From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Mar 07 2005 - 17:46:54 GMT-3
Simon,
First, let me give credit where credit is due.
What I'm about to tell you is compiled from conversations with Scott Morris
and Brian McGahan.
Background knowledge needed for this to make sense:
You must make a distinction between explorer traffic and user traffic.
The commands icanreach and icannotreach directly affect explorer traffic but
only indirectly affect user traffic. Acl's affect both explorer and user
traffic.
When you use the icanreach command, that negates the need for the peer to
send explorers to find the specified resource. This will usually also
prevent user traffic for the specified resource but not necessarily.
The reason for the "not necessarily" is because it's possible for the peer
to have a static path configured which would also prevent explorers from
being sent. For example,
Host Simon - peer-A <---> peer B
There are 2 ways to prevent peer B from sending explorers for Host Simon:
1) config on peer A: icanreach netbios-name Simon
2) config on peer B: dlsw netbios-name Simon ip address x.x.x.x
Now, let's say you want to prevent all netbios to peer A.
If you configure on peer A, icannotreach sap F0, it's still possible for
peer B to have a static path configured on it so that netbios traffic will
go to peer A. Normally, in the real world, this doesn't happen because there
wouldn't be a static path configured on peer B which would send netbios
traffic to peer A, but in the very contrived scenarios in the lab, you
"technically" haven't fulfilled the requirement of preventing netbios
traffic from going to peer A.
So, if you have to prevent all traffic of a certain type, you MUST use
acl's, not icannotreach.
-----------
There are 3 ways to specify traffic with dlsw:
1) by mac addr
2) by netbios name
3) by sap
With method 1 and 2, you can use the icanreach ---exclusive command.
With method 3, there is no equivalent for the exclusive command. Actually,
Scott and Brian are in 100% disagreement about what this command actually
does.
Per Brian, if you config on peer A, icanreach sap F0, that means that peer A
can ONLY reach netbios hosts and peer A's peer won't send explorers for any
other type of traffic.
Per Scott, that same command doesn't imply ONLY and peer A's peer will send
explorers for other types of traffic.
Brian also says that this can be verified by configuring the command and
then using the show dlsw cap command and then looking at the unsupported
saps. Maybe, maybe not. I can't say at the moment without a rack to test
this. (Does this remind you of the TV show, Battle of the Titans?)
-----------
Scope of (netbios | mac) exclusive command:
Just the type of traffic specified.
For example, if this is your config:
icanreach netbios-name Simon
icanreach netbios-exclusive
That won't prevent explorers for any mac addresses or sna hosts or anything
else. It will only prevent explorers for netbios hosts.
HTH, Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Monday, March 07, 2005 2:59 PM
To: ccie2be
Subject: RE: dlsw promiscuous and encap type
Sleeping :)
Seriously - back over ATM and IPv6
Lab is due in two months, really trying to get the config hours in
Interested to know when one would use icanreach as compared to acl's
Simon
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: 07 March 2005 19:55
To: 'simon hart'; Group Study
Subject: RE: dlsw promiscuous and encap type
Simon,
It's so good to be in sync with someone else.
This past weekend, I spent some time with Scott Morris - what a great guy -
going over in detail some of the finer points of the icanreach and
icannotreach commands and when these commands should be used versus using
acl's.
Trust me, this stuff is NOT intuitive and it's very poorly and incompletely
documented.
So, if you have any questions at all about this, please don't hesitate to
ask.
After dlsw, what will you be doing next?
Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Monday, March 07, 2005 2:46 PM
To: ccie2be
Subject: RE: dlsw promiscuous and encap type
Tim,
I can't seem to get direct encapsulation to work on an HDLC with the remote
end being promiscuous - have labbed it with no joy.
With fst, DLSW and tcp you identify the remote peer by their local peer id
(below i used 150.1.2.2). If that local peer is promiscous it will respond
to a request to establish a peer.
With direct encapsulation you do not identify the remote peers local id
e.g. direct encapsulation
dlsw remote-peer 0 interface s1
For this reason I do not believe it will work. I have not tried it by using
serial interface addresses for peer id's, maybe worth a shot (will let you
know the outcome)
Simon
PS - No trouble helping out, tonight is my DLSW night :) so this helps with
my studies
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: 07 March 2005 19:38
To: 'simon hart'
Subject: RE: dlsw promiscuous and encap type
Simon,
Thanks for checking this out.
But, the question was if promiscuous would work if direct encap is used.
You from previous post: "I think it may prove troublesome for direct
encapsulation."
BTW, I really appreciate you're taking the time to do this.
Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Monday, March 07, 2005 2:05 PM
To: ccie2be
Subject: RE: dlsw promiscuous and encap type
Hi Tim,
Tested on a serial (HDLC) circuit
Router 3
dlsw local-peer peer-id 150.1.3.3
dlsw remote-peer 0 fst 150.1.2.2
dlsw bridge-group 1
Router 2
dlsw local-peer peer-id 150.1.2.2 promiscuous
dlsw bridge-group 1
Rack1R2#sh dlsw peer
Peers: state pkts_rx pkts_tx type drops ckts TCP
uptime
FST 150.1.3.3 CONNECT 5 5 prom 0 - -
00:01:51
Expected: 0 Next Send: 0 Seq errors: 0
Total number of connected peers: 1
Total number of connections: 1
That seems to prove that fst will work in promiscuous mode
And good luck for 8 days time (hope the dsl starts to work again)
Simon
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: 07 March 2005 18:54
To: 'simon hart'
Subject: RE: dlsw promiscuous and encap type
Thanks, Simon.
Is there any chance you can test this?
I don't access to a rack today. I'm hoping tomorrow I will but I'm
dependent on SBC fixing a dsl problem and who knows how long that will take.
MY gut feeling is that all encaps type can form a peering session with a
promiscuous peer, but gut feeling isn't something I like to hang my hat on
with my lab date 8 days away.
Thanks again, Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Monday, March 07, 2005 1:44 PM
To: ccie2be; Group Study
Subject: RE: dlsw promiscuous and encap type
Hi,
I believe promiscuous will support tcp, fst and dlswlite. I think it may
prove troublesome for direct encapsulation
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ccie2be
Sent: 07 March 2005 17:24
To: Group Study
Subject: dlsw promiscuous and encap type
Hi guys,
If one peer is configured like this:
dlsw local-peer peer-id 1.1.1.1 promiscuous
can the other peer use any type of encap, tcp, fst, direct, dlsw lite as
appropriate?
Or, does using promiscuous on one side restrict the type of encap that can
be used on the remote side?
TIA, Tim
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:42 GMT-3