Re: Custom queue-list for DLSW

From: KK FoK (rgb98a@xxxxxxxxxxx)
Date: Fri Jan 11 2002 - 01:20:59 GMT-3


   
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:23 GMT-3