From: Sasa Milic (smilic@xxxxxxxx)
Date: Sun Jan 06 2002 - 01:24:35 GMT-3
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:17 GMT-3