From: Bauer, Rick (BAUERR@xxxxxxxxxxx)
Date: Fri Jan 11 2002 - 12:08:34 GMT-3
Check this out, destination UDP port 2067 when a DLSW has multiple
peers.....
Jan 11 16:07:49.804 UTC: IP: s=200.0.0.4 (Ethernet0), d=200.0.0.1, len 212,
rcvd 4
Jan 11 16:07:49.808 UTC: UDP src=0, dst=2067
Jan 11 16:07:49.812 UTC: IP: s=200.0.0.4 (Ethernet0), d=200.0.0.1, len 174,
rcvd 4
Jan 11 16:07:49.816 UTC: UDP src=0, dst=2067
Jan 11 16:07:52.024 UTC: IP: s=200.0.0.1 (local), d=200.0.0.5 (Ethernet0),
len 52, sending
Jan 11 16:07:52.028 UTC: TCP src=2065, dst=11332, seq=584797283,
ack=3231088991, win=20348 ACK PSH
Jan 11 16:07:52.036 UTC: IP: s=200.0.0.5 (Ethernet0), d=200.0.0.1, len 40,
rcvd 4
Jan 11 16:07:52.044 UTC: TCP src=11332, dst=2065, seq=3231088991,
ack=584797295, win=20264 ACK
UDP Unicast
DLSw Version 2 uses UDP unicast in response to a IP multicast. When address
resolution packets (CANUREACH_EX, NETBIOS_NQ_ex, NETBIOS_ANQ, and DATAFRAME)
are sent to multiple destinations (IP multicast service) DLSw Version 2
sends the response frames (ICANREACH_ex and NAME_RECOGNIZED_ex) via UDP
unicast.
UDP unicast uses UDP source port 0. However, some firewall products treat
packets that use UDP source port 0 as security violations, discarding the
packets and preventing DLSw connections. To avoid this situation, use one of
the following procedures:
Configure the firewall to allow UDP packets to use UDP source port 0.
Use the dlsw udp-disable command to disable UDP unicast and send address
resolution packets in the existing TCP session.
Watch the wrap.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ibm_
c/bcprt2/bcddlsw.htm#21884
-----Original Message-----
From: Waters, Kivas (UK72) [mailto:Kivas.Waters@Honeywell.com]
Sent: Friday, January 11, 2002 5:49 AM
To: KK FoK; smilic@EUnet.yu; ccielab@groupstudy.com
Subject: RE: Custom queue-list for DLSW
I believe that TCP port 2067 is used by other vendors implimentations of
DLSw. Cisco do not use this TCP port number and if you have a purely Cisco
environment you will not need to consider it, as far as I know. When
interfacing with IBM routers for example you will need to consider TCP port
2067 as being required. I understand that Cisco routers will open TCP port
2067 and listen on this port whenever DLSw is set up. Any remote Cisco
router peer will never try to connect to 2067 so it's never actually used in
a Cisco envorinment. However, an IBM remote router will try to talk to both
2065 and 2067 so Cisco accomodate this need.
I hope I have it right, someone please correct me if I'm wrong.
regards
Ki
6 days to go ...
-----Original Message-----
From: KK FoK [mailto:rgb98a@hotmail.com]
Sent: 11 January 2002 04:21
To: smilic@EUnet.yu; ccielab@groupstudy.com
Subject: Re: Custom queue-list for DLSW
I'm trying to summaize the discussion and see if we can reach a conclusion.
queue-list 1 protocol ip tcp 2065
queue-list 1 protocol ip tcp 2067
queue-list 1 protocol ip tcp 1981
queue-list 1 protocol ip tcp 1982
queue-list 1 protocol ip tcp 1983
My understanding is that by specifying a port number this will include both
source and destination ports. Pls correct me if I'm wrong.
What I'm uncertain is that if we need 2067 ????
>From: Sasa Milic <smilic@EUnet.yu>
>Reply-To: Sasa Milic <smilic@EUnet.yu>
>To: ccielab@groupstudy.com
>Subject: Re: Custom queue-list for DLSW
>Date: Mon, 07 Jan 2002 14:50:54 -0800
>
>"Stephen C. Feldberg" wrote:
> >
> > Please correct me if I am mistaken about the peer connection that is
> > dropped, and let's discuss what exactly "listening" on TCP port 2067 is
> > about.
>
>You are mistaken ;)
>
>Connection that R1 initiated and which terminates on R2(2065) will be
>torn down. It's probably easier to remember this way:
>
> "The connection initiated from higher peer-id will be used."(tm)
>
>Sasa
>
>
>
>"Stephen C. Feldberg" wrote:
> >
> > I don't know where the UDP reference is from, but the new CCIE Practical
> > Studies book says this about DLSw TCP encapsulation:
> >
> > p898
> > " (DLSw) TCP encapsulation listens on TCP port 2067 and transmits on TCP
> > port 2065 by default."
> >
> > Eh? What kind of "listening" is the author talking about here? He goes
>on
> > to say:
> >
> > p902
> > Cisco's implementation of the TCP connections control vector states that
> > only one TCP connection will be used to transport data. When a DLSw+
> > circuit is first established, two TCP connections are active.
> > +++
> > Which AFAIK would look like:
> > R1(2065)-----------------(>1023)R2
> > R1(>1023)-----------------(2065)R2
> > local-peer 1.1.1.1 local-peer 2.2.2.2
> > +++
> > DLSw+ states that the TCP connection with the highest IP address (I am
> > assuming he means highest local-peer id) will be torn down, (I am
>assuming
> > he means the connection that was initiated by the highest local-peer id)
> > leaving only one TCP connection to transport data."
> > +++
> > Which should leave:
> > R1(>1023)-----------------(2065)R2
> >
> > Please correct me if I am mistaken about the peer connection that is
> > dropped, and let's discuss what exactly "listening" on TCP port 2067 is
> > about.
> >
> > Steve
> > ----- Original Message -----
> > From: "Sasa Milic" <smilic@EUnet.yu>
> > To: <ccielab@groupstudy.com>
> > Sent: Monday, January 07, 2002 2:59 PM
> > Subject: Re: Custom queue-list for DLSW
> >
> > > We are not trying to configure queuing for setup, but for the
> > > TCP connection that will be using for data exchange. Why would
> > > UDP port 2067 be needed for that ?
> > >
> > > " Expedited TCP Connection
> > > > DLSw Version 2 efficiently establishes TCP connections. Previously,
>DLSw
> > > > created two unidirectional TCP connections and then disconnected one
> > after
> > > > the capabilities exchange took place. With DLSw Version 2, a single
> > > > bidirectional TCP connection establishes if the peer is brought up
>as a
> > > > result of an IP multicast/UDP unicast information exchange."
> > >
> > > It is still one TCP connection, no matter how it is established, right
>?
> > > And it uses tcp port 2065 on one side, and ephemeral port on the
>other.
> > >
> > > Sasa
> > >
> > >
> > > "Bauer, Rick" wrote:
> > > >
> > > > You will use the destination of 2065 after the initial setup, after
>all
> > we
> > > > are talking about 7 ip packets most of which are 40k. It seems
>overly
> > anal
> > > > to attempt to queue the initial set up. It would make more sense to
>add
> > a
> > > > line to your access-list for the write port destination udp port
>2067.
> > > >
> > > > -----------------clip from cco-------------------------
> > > >
> > > > Establish Peer Connections
> > > > Before two routers can switch SNA or NetBIOS traffic, they must
> > establish
> > > > two TCP connections between them. The standard allows one of these
>TCP
> > > > connections to be dropped if it is not required. (Cisco routers will
> > drop
> > > > the extra TCP connection unless they are communicating with another
> > vendor's
> > > > router that requires two TCP connections.) The standard also allows
> > > > additional TCP connections to be made to allow for different levels
>of
> > > > priority.
> > > >
> > > > New in version 2 of DLSW
> > > >
> > > > Expedited TCP Connection
> > > > DLSw Version 2 efficiently establishes TCP connections. Previously,
>DLSw
> > > > created two unidirectional TCP connections and then disconnected one
> > after
> > > > the capabilities exchange took place. With DLSw Version 2, a single
> > > > bidirectional TCP connection establishes if the peer is brought up
>as a
> > > > result of an IP multicast/UDP unicast information exchange.
> > > >
> > > > -----Original Message-----
> > > > From: Sasa Milic [mailto:smilic@EUnet.yu]
> > > > Sent: Monday, January 07, 2002 12:22 PM
> > > > To: ccielab@groupstudy.com
> > > > Subject: Re: Custom queue-list for DLSW
> > > >
> > > > In outgoing, of course. So ? What you want to say ?
> > > >
> > > > Sasa
> > > >
> > > > "Bauer, Rick" wrote:
> > > > >
> > > > > Think about it, in what direction is traffic effected by queuing?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Sasa Milic [mailto:smilic@EUnet.yu]
> > > > > Sent: Saturday, January 05, 2002 11:25 PM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: Re: Custom queue-list for DLSW
> > > > >
> > > > > Yes, using the same access list with two lines on both sides will
> > > > > work. But then, your access-list will have more than what is
> > > > > needed. One side will always use first entry, other side will
> > > > > always use second entry, which may introduce lower performanse
> > > > > (well, I guess that it won't be noticable).
> > > > >
> > > > > We all know that lab is something else - using more than what is
> > > > > necessary might be considered wrong - proctors might think
> > > > > that you don't know which connection will be used (we know that
> > > > > you know, but they don't).
> > > > >
> > > > > Sasa
> > > > >
> > > > > Albert Lu wrote:
> > > > > >
> > > > > > Why would you need to have different access list on both sides?
> > > > > >
> > > > > > Wouldn't using this two lines on both sides be ok? This will
>cover
> > off
> > > > all
> > > > > > your cases
> > > > > >
> > > > > > permit tcp any any eq 2065
> > > > > > permit tcp any eq 2065 any
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
>Behalf
> > Of
> > > > > > Sasa Milic
> > > > > > Sent: Monday, December 17, 2001 3:14 PM
> > > > > > To: ccielab@groupstudy.com
> > > > > > Subject: Re: Custom queue-list for DLSW
> > > > > >
> > > > > > Yes, we need custom queueing on both sides, and access-lists
> > > > > > will have swapped source/destination addresses/ports on
> > > > > > them. So, on one side you will have source port 2065, and
> > > > > > on the other side that will be destination port.
> > > > > >
> > > > > > Sasa
> > > > > >
> > > > > > Albert Lu wrote:
> > > > > > >
> > > > > > > So are custom queues needed on both sides of the link if I
>wanted
> > DLSW
> > > > > to
> > > > > > > use certain amount of bandwidth for the link? Does anyone
>agree
> > with
> > > > me
> > > > > > that
> > > > > > > custom queueing only applies to outbound traffic, and you need
> > custom
> > > > > > > queueing done on both sides?
> > > > > > >
> > > > > > > Albert
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > Behalf Of
> > > > > > > Stephen C. Feldberg
> > > > > > > Sent: Monday, December 17, 2001 4:42 AM
> > > > > > > To: Albert Lu
> > > > > > > Cc: ccielab@groupstudy.com
> > > > > > > Subject: Re: Custom queue-list for DLSW
> > > > > > >
> > > > > > > My understanding is that one line is defined to identify
>outbound
> > DLSW
> > > > > > > traffic if the local peer has the higher peer-id and the other
> > line
> > > > > > > identifies the outbound traffic if the remote peer has the
>higher
> > > > > peer-id.
> > > > > > >
> > > > > > > If you wanted to eliminate one of the lines I suppose that you
> > could
> > > > > > > manipulate your peer-ids so that the hub router has the
>highest id
> > and
> > > > > > > eliminate the "permit tcp any any eq 2065" statement.
> > > > > > >
> > > > > > > Steve
> > > > > > > ----- Original Message -----
> > > > > > > From: "Albert Lu" <albert_ccie@yahoo.com>
> > > > > > > To: <ccielab@groupstudy.com>
> > > > > > > Cc: "'Sasa Milic'" <smilic@EUnet.yu>
> > > > > > > Sent: Sunday, December 16, 2001 6:14 AM
> > > > > > > Subject: RE: Custom queue-list for DLSW
> > > > > > >
> > > > > > > > I just thought about something in regards to this problem. I
> > don't
> > > > > think
> > > > > > > > it's needed for the two lines, as custom queueing is only
> > applied to
> > > > > > > > outbound traffic of the interface. Incoming traffic cannot
>be
> > custom
> > > > > > > queued,
> > > > > > > > as the traffic has already arrived to the interface and may
>be
> > using
> > > > > > > > whatever amount of bandwidth it started off with.
> > > > > > > >
> > > > > > > > So my thoughts are that the source would need to be defined
>as
> > tcp
> > > > > port
> > > > > > > > 2065. But if you wanted to make sure the bandwidth is
>allocated
> > for
> > > > > the
> > > > > > > > link, you might need to put the custom queueing on both
>sides of
> > the
> > > > > > link.
> > > > > > > >
> > > > > > > > Let me hear your thoughts
> > > > > > > >
> > > > > > > > Albert
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > Behalf
> > > > Of
> > > > > > > > Sasa Milic
> > > > > > > > Sent: Friday, December 14, 2001 6:08 AM
> > > > > > > > To: ccielab@groupstudy.com
> > > > > > > > Subject: Re: Custom queue-list for DLSW
> > > > > > > >
> > > > > > > >
> > > > > > > > Also, do we need to define both lines:
> > > > > > > >
> > > > > > > > permit tcp any any eq 2065
> > > > > > > > permit tcp any eq 2065 any
> > > > > > > >
> > > > > > > > There will be two connections at the start of peering, but
>one
> > > > > > > > will be dropped during negotiation (at least in cisco case),
> > > > > > > > so we will end up with only one connection, and since we
>know
> > > > > > > > peer-ids we also know which connection will be dropped (the
>one
> > > > > > > > from peer with lower peer-id and port >1023 to peer with
>higher
> > > > > > > > peer id and port 2065). The end result is that only one line
>in
> > > > > > > > the access-list is required, right ?
> > > > > > > >
> > > > > > > > Sasa
> > > > > > > >
> > > > > > > >
> > > > > > > > KK FoK wrote:
> > > > > > > > >
> > > > > > > > > During my test I didn't spot any port "2067". The
>access-list
> > 100
> > > > is
> > > > > > set
> > > > > > > > for
> > > > > > > > > incoming access.
> > > > > > > > >
> > > > > > > > > Do we need to define 2067 as well for custom queue-list ?
> > > > > > > > >
> > > > > > > > > TCB Local Address Foreign Address
> > (state)
> > > > > > > > > 0051987C 10.0.0.100.11018 10.0.0.36.2065
>ESTAB
> > > > > > > > > 00526F20 10.0.0.100.11021 10.0.0.36.1983
>ESTAB
> > > > > > > > > 00519CC4 10.0.0.100.11019 10.0.0.36.1981
>ESTAB
> > > > > > > > > 0053C5F0 10.0.0.100.11020 10.0.0.36.1982
>ESTAB
> > > > > > > > > 25#sh access-list
> > > > > > > > > 25#sh access-lists
> > > > > > > > > Extended IP access list 100
> > > > > > > > > permit tcp any any eq 2065 (12 matches)
> > > > > > > > > permit tcp any eq 2065 any (79 matches)
> > > > > > > > > permit tcp any eq 1981 any (3 matches)
> > > > > > > > > permit tcp any eq 1982 any (3 matches)
> > > > > > > > > permit tcp any eq 1983 any (3 matches)
> > > > > > > > > deny ip any any log
> > > > > > > > >
> > > > > > > > > >From: Liu Jianxin-qch1927 <Jianxin.Liu@invisix.com>
> > > > > > > > > >Reply-To: Liu Jianxin-qch1927 <Jianxin.Liu@invisix.com>
> > > > > > > > > >To: "'Denise Donohue'" <fradendon@home.com>,
>"'Albert
> > Lu'"
> > > > > > > > > ><albert_ccie@yahoo.com>, ccielab@groupstudy.com
> > > > > > > > > >Subject: RE: Custom queue-list for DLSW
> > > > > > > > > >Date: Thu, 13 Dec 2001 14:21:40 +0800
> > > > > > > > > >
> > > > > > > > > >The local port 2065is the write pipe port and local port
> > 2067 is
> > > > > the
> > > > > > > > read
> > > > > > > > > >port.
> > > > > > > > > >
> > > > > > > > > >Jianxin
> > > > > > > > > >
> > > > > > > > > >-----Original Message-----
> > > > > > > > > >From: Denise Donohue [mailto:fradendon@home.com]
> > > > > > > > > >Sent: Thursday, December 13, 2001 1:12 PM
> > > > > > > > > >To: 'Albert Lu'; ccielab@groupstudy.com
> > > > > > > > > >Subject: RE: Custom queue-list for DLSW
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >DLSW has to be listed twice in the access list because
> > messages
> > > > are
> > > > > > > both
> > > > > > > > > >coming in and going out. Look at the two top lines in
>that
> > > > access
> > > > > > list
> > > > > > > > way
> > > > > > > > > >down at the bottom of this email. The first line covers
> > packets
> > > > > from
> > > > > > > > > >anybody with a dlsw source port, bound for anybody, any
> > > > destination
> > > > > > > port.
> > > > > > > > > >The second line covers packets from anywhere, any port,
> > destined
> > > > > for
> > > > > > > > dlsw.
> > > > > > > > > >
> > > > > > > > > >-----Original Message-----
> > > > > > > > > >From: nobody@groupstudy.com
>[mailto:nobody@groupstudy.com]On
> > > > Behalf
> > > > > > Of
> > > > > > > > > >Albert Lu
> > > > > > > > > >Sent: Wednesday, December 12, 2001 5:02 PM
> > > > > > > > > >To: ccielab@groupstudy.com
> > > > > > > > > >Cc: 'Richard Gallagher'; 'David Vu'
> > > > > > > > > >Subject: RE: Custom queue-list for DLSW
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >Ok, did some testing. Take a look at the results. The top
>one
> > is
> > > > > > > without
> > > > > > > > > >the
> > > > > > > > > >priority keyword, and the second one is with the priority
> > > > keyword.
> > > > > > > Looks
> > > > > > > > > >like priority keyword has to be used for port 1981, 1982,
> > 1983 to
> > > > > be
> > > > > > > > used.
> > > > > > > > > >Otherwise it's just port 2065.
> > > > > > > > > >
> > > > > > > > > >Port 2067 seems like a port used for non cisco dlsw
>routers.
> > This
> > > > > was
> > > > > > > > from
> > > > > > > > > >looking at the archives.
> > > > > > > > > >
> > > > > > > > > >But I'm also confused about why 2065 has to be included
>twice
> > in
> > > > > the
> > > > > > > > access
> > > > > > > > > >list for source and destination traffic.
> > > > > > > > > >
> > > > > > > > > >4d18h: tcp0: O CLOSED 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 3979558325
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: I SYNSENT 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > > 4145548835
> > > > > > > > > > OPTS 4 ACK 3979558326 SYN WIN 2144
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 3979558326
> > > > > > > > > > ACK 4145548836 WIN 20480
> > > > > > > > > >4d18h: tcp0: I LISTEN 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > 4145571375
> > > > > > > > > > OPTS 4 SYN WIN 2144
> > > > > > > > > >4d18h: tcp0: O SYNRCVD 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > > 3917049564
> > > > > > > > > > OPTS 4 ACK 4145571376 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: I SYNRCVD 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > > 4145571376
> > > > > > > > > > ACK 3917049565 WIN 2144
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 3979558326
> > > > > > > > > > DATA 395 ACK 4145548836 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 4145548836
> > > > > > > > > > ACK 3979558721 WIN 20085
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > 4145571376
> > > > > > > > > > DATA 428 ACK 3917049565 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > 3917049565
> > > > > > > > > > ACK 4145571804 WIN 20052
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 3979558721
> > > > > > > > > > DATA 76 ACK 4145548836 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:11000 172.1.1.2:2065 seq
> > > > 3917049565
> > > > > > > > > > RST WIN 20052
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:2065 172.1.1.2:11000 seq
> > > > 4145548836
> > > > > > > > > > ACK 3979558797 WIN 20009
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
>
>---------------------------------------------------------------------------
> > > > > > > > -
> > > > > > > > > >--------
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:2065 172.1.1.2:11001 seq
> > > > 2117597008
> > > > > > > > > > DATA 395 ACK 4217556762 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:2065 172.1.1.2:11001 seq
> > > > 4217556762
> > > > > > > > > > ACK 2117597403 WIN 20085
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:11001 172.1.1.2:2065 seq
> > > > 4217579488
> > > > > > > > > > DATA 428 ACK 477058866 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:sh11001 172.1.1.2:2065 seq
> > > > 477058866
> > > > > > > > > > ACK 4217579916 WIN 20052
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:2065 172.1.1.2:11001 seq
> > > > 2117597403
> > > > > > > > > > DATA 76 ACK 4217556762 PSH WIN 20480
> > > > > > > > > >4d18h: tcp0: O CLOSED 172.1.1.1:1981 172.1.1.2:11002 seq
> > > > 3562669525
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: O CLOSED 172.1.1.1:1982 172.1.1.2:11003 seq
> > > > 1040855164
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: O CLOSED 172.1.1.1:1983 172.1.1.2:11004 seq
> > > > 1592008227
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:11001 172.1.1.2:2065 seq
> > 477058866
> > > > > > > > > > RST WIN 20052
> > > > > > > > > >4d18h: tcp0: I ESTAB 172.1.1.1:2065 172.1.1.2:11001 seq
> > > > 4217556762
> > > > > > > > > > ACK 2117597479 WIN 20009
> > > > > > > > > >4d18h: tcp0: I SYNSENT 172.1.1.1:1981 172.1.1.2:11002 seq
> > > > > 4217767660
> > > > > > > > > > OPTS 4 ACK 3562669526 SYN WIN 2144
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:1981 172.1.1.2:11002 seq
> > > > 3562669526
> > > > > > > > > > ACK 4217767661 WIN 204
> > > > > > > > > >4d18h: tcp0: R SYNSENT 172.1.1.1:1982 172.1.1.2:11003 seq
> > > > > 1040855164
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: R SYNSENT 172.1.1.1:1983 172.1.1.2:11004 seq
> > > > > 1592008227
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: I SYNSENT 172.1.1.1:1982 172.1.1.2:11003 seq
> > > > > 4219752345
> > > > > > > > > > OPTS 4 ACK 1040855165 SYN WIN 2144
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:1982 172.1.1.2:11003 seq
> > > > 1040855165
> > > > > > > > > > ACK 4219752346 WIN 20480
> > > > > > > > > >4d18h: tcp0: R SYNSENT 172.1.1.1:1983 172.1.1.2:11004 seq
> > > > > 1592008227
> > > > > > > > > > OPTS 4 SYN WIN 4128
> > > > > > > > > >4d18h: tcp0: I SYNSENT 172.1.1.1:1983 172.1.1.2:11004 seq
> > > > > 4223752716
> > > > > > > > > > OPTS 4 ACK 1592008228 SYN WIN 2144
> > > > > > > > > >4d18h: tcp0: O ESTAB 172.1.1.1:1983 172.1.1.2:11004 seq
> > > > 1592008228
> > > > > > > > > > ACK 4223752717 WIN 20480
> > > > > > > > > >
> > > > > > > > > >-----Original Message-----
> > > > > > > > > >From: nobody@groupstudy.com
>[mailto:nobody@groupstudy.com]On
> > > > Behalf
> > > > > > Of
> > > > > > > > > >Richard Gallagher
> > > > > > > > > >Sent: Thursday, December 13, 2001 3:13 AM
> > > > > > > > > >To: David Vu; ccielab@groupstudy.com
> > > > > > > > > >Subject: Re: Custom queue-list for DLSW
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >David,
> > > > > > > > > >
> > > > > > > > > >"dlsw" keyword is only for FST encapsulation, for TCP you
> > need to
> > > > > > > specify
> > > > > > > > > >all
> > > > > > > > > >the ports involved.
> > > > > > > > > >
> > > > > > > > > >Rich
> > > > > > > > > >CCIE #7211
> > > > > > > > > >
> > > > > > > > > >On Dec 12, 9:38am, David Vu chatted about:
> > > > > > > > > > > Subject:Custom queue-list for DLSW
> > > > > > > > > > > In bootcamp lab 20, it asks you to do a custom queue
>with
> > > > > > > > > > >
> > > > > > > > > > > 50% on DLSW
> > > > > > > > > > > 25% on IP
> > > > > > > > > > > 25% on IPX
> > > > > > > > > > >
> > > > > > > > > > > For DLSW, the solution is
> > > > > > > > > > > access-list 101 permit tcp any eq 2065 any
> > > > > > > > > > > access-list 101 permit tcp any any eq 2065
> > > > > > > > > > > access-list 101 permit tcp any any eq 2067
> > > > > > > > > > > access-list 101 permit tcp any any eq 1981
> > > > > > > > > > > access-list 101 permit tcp any any eq 1982
> > > > > > > > > > > access-list 101 permit tcp any any eq 1983
> > > > > > > > > > > queue-list 1 protocol ip 1 list 101
> > > > > > > > > > >
> > > > > > > > > > > Would it be easier to do "queue-list 1 protocol dlsw
>1"
> > > > instead
> > > > > of
> > > > > > > > using
> > > > > > > > > >an
> > > > > > > > > > > access-list?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:25 GMT-3