From: garcia (e_garcia@xxxxxxxxxxxx)
Date: Wed May 08 2002 - 14:28:54 GMT-3
ying,
Re.: "My gut feeling tells me it's equal to port 2065, but I don't have
anything to support it."
have you tried 'debug ip tcp transactions' during dlsw establishment? i
believe you will see the port #'s there. when you add 'priority' keyword to
remote peer you should see 2065, 1981, 1982, 1983 show up in debug. the
ports are associated to high, med, normal, low priority respectfully along
with port/traffic defaults.
example:
dlsw remote-peer 0 tcp 192.168.1.2 priority
as my lab partner and i have tested, you could then create a
'sap-priority-list' to further manage traffic as necessary, i.e. -
sap-priority-list 1 high ssap f0 dsap f0 high ---> associate netbios to high
(port 2065)
sap-priority-list 1 med ssap 04 dsap 04 ---> associate sna path ctl -
individual to med (port 1981)
sap-priority-list 1 low ssap 80 dsap 80 ---> associate xns to low (port
1983)
alternatively, you can set up sap-priority-lists for sap pairs with
smac/dmac and/or use with a locaddr command - sorry don't remember it
(applies to programmed pu/lu def in an sna major node under vtam).
as things never seem to end with networking and studying for ccie, each port
(2065, 1981, 1982, 1983) is assigned an ip precedence by default. 2065 is
011 (critical) for example. you can also change ip precedence (talking
ipv4 tos) as well...
with cq using a custom queue-list you set byte-counts as a percentage of
available bandwidth given to a specific protocol.
for dlsw to have 50% of bandwidth, ip to have 25% of bandwidth and
protocol-x to have 25% of bandwidth you would do something like:
queue-list 1 prot dlsw 1
queue-list 1 prot ip 2
queue-list 1 prot protocol-x 3
queue-list 1 queue 1 byte-count 3000
the above would cause ip and protocol-x to get default queue size 1500 and
1500 or you could explicitly set them if you like:
queue-list 1 queue 2 byte-count 1500
queue-list 1 queue 3 byte-count 1500
to confirm that you add up the byte counts 3000+1500+1500 = 6000 so ...
(3000=50%, 1500=25%, 1500=25%) = 100%
and with pq using a priority-list you set priority based on the protocol
(and then to tcp port level) or even by interface. by default the pq packet
limits for high, med, normal, low queues are 20, 40, 60, 80 respectfully.
the high queue will be emptied 4 times as fast as the low queue (4:1).
with pq, in the case of dlsw and back to the 'priority' keyword you could
further granularize and prioritize the dlsw ports/sessions (1981, 1982, 1983
opened up by 'priority' keyword, further controlled by sap-priority-list)
between peers by setting a priority as necessary. if no sap-priority-list
was set after the priority keyword is added to remote peer you run default
priority mode set for ports. you can also change the pq queue-limits as you
see fit.
useful from cco (sorry lost the url):
By default DLSw+ assigns certain traffic to specific TCP ports:
* TCP port 2065 defaults to high priority; in the absence of any other
configuration, this port will carry all circuit administration frames
(CUR_cs, ICR_cs, contact SSP frames, disconnect SSP frames, XID, ICR_ex),
peer keepalives, and capabilities exchange
* TCP port 1981 defaults to medium priority; in the absence of any other
configuration, this port will not carry any traffic
* TCP port 1982 defaults to normal priority; in the absence of any other
configuration, this port will carry information frames (nonbroadcast
datagram frames)
* TCP port 1983 defaults to low priority; in the absence of any other
configuration, this port will carry broadcast traffic (CUR_ex,
Name_query_ex, SSP DATA/DGRM broadcasts)
----------------------------------------------------------------------------
---- Note You can configure specific traffic to go into either port 2065, 1981, or 1983. If you specify priority in the dlsw remote-peer command and do nothing else, all data traffic goes in TCP port 1982 and all unspecified traffic goes in TCP port 1982.hope this clears it up. there are other ways using acl, etc. as i'm sure others have noted ... ;)
Frank Garcia
----- Original Message ----- From: ying chang <ying_c@hotmail.com> To: <j.self@wcom.com>; <steven.j.nelson@bt.com>; <ccielab@groupstudy.com> Cc: <stephen.paynter@bt.com> Sent: Wednesday, May 08, 2002 6:22 AM Subject: RE: DLSW Custom Queuing.
> Thanks. I probably misinterpreted Steve's original post, which stated > > "... i.e That this keyword permits SNA traffic only and not all DLSw > traffic,..." > > The word "only" made me to beleive if the keyword "dlsw" is used, SNA > traffic will be the only type of traffic that can go through, but that's not > the case. I still don't know when to use "dlsw" keyword, but I'll stick with > port number for now just to play safe. My gut feeling tells me it's equal to > port 2065, but I don't have anything to support it. > > Chang > > >From: James Self <j.self@wcom.com> > >To: ying chang <ying_c@hotmail.com>, steven.j.nelson@bt.com, > >ccielab@groupstudy.com > >CC: stephen.paynter@bt.com > >Subject: RE: DLSW Custom Queuing. > >Date: Wed, 08 May 2002 08:58:38 -0400 > > > >try this website.. this is what I use.... > > > >http://www.cisco.com/warp/public/cc/pd/ibsw/ibdlsw/prodlit/dlsw5_rg.htm > > > >Hopefully it can be of some help.... > > > >Thanks, > >James L. Self > >CCDP,CCNP,CCDA,CCNA,CNE > >Sr. Network Engineer I > >Lead Engineer Team C > >GNO/Advance Technical Support > >Worldcom Managed Services > >vnet 966-7450 or 919 377-7450 > >ATS_Team_C@lists.wcom.com > > > >-----Original Message----- > >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of > >ying chang > >Sent: Tuesday, May 07, 2002 6:50 PM > >To: steven.j.nelson@bt.com; ccielab@groupstudy.com > >Cc: stephen.paynter@bt.com > >Subject: RE: DLSW Custom Queuing. > > > > > >Steve, > > > >Thanks for the info. However, let's go back to the original question: > > > >"I was wondering does anyone have a URL that outlines the behaviour of > >custom queuing when using DLSw keyword. i.e That this keyword permits SNA > >traffic only and not all DLSw traffic" > > > >The above question troubles me a little bit, because if I interpret the > >statement correctly, what you are saying is if I use the dlsw keyword in my > >access-list, then SNA traffic will be allowed to go through, but not > >NetBIOS > >or other non-routable traffic. > > > >Why a port number has anything to do with different layer's traffic? From > >the web page, I suspect the dlsw keyword probably is the same as port 2065, > >and we'll only have to worry about the port numbers when the priority queue > >is applied. Otherwise, as far as the custom queue concern, port 2065 should > >be sufficient. I know this contradict with the answers I've seen in the > >past, but I'm more confused than ever when I think about the statement. > > > >Well, I guess I'll have to spend sometime to test it out and see what's > >going on. Until then, if anyone knows when I have to use the the keyword > >"dlsw" and when I should not (other than priority queue), please let me > >know. > > > >Thanks, > >Chang > > > > > > >From: steven.j.nelson@bt.com > > >Reply-To: steven.j.nelson@bt.com > > >To: ying_c@hotmail.com, ccielab@groupstudy.com > > >CC: stephen.paynter@bt.com > > >Subject: RE: DLSW Custom Queuing. > > >Date: Tue, 7 May 2002 18:25:52 +0100 > > > > > >Chang Et al, > > > > > >I have found the relevant document on CCO, the URL is :- > > > > > >http://www.cisco.com/warp/public/cc/pd/ibsw/ibdlsw/prodlit/dlsw5_rg.htm > > > > > >Interestingly enough it states that ports 2065 is also only used when > > >prioritisation is required. > > > > > >Thanks > > > > > >Steve > > > > > >-----Original Message----- > > >From: ying chang [mailto:ying_c@hotmail.com] > > >Sent: 07 May 2002 17:14 > > >To: Nelson,SJ,Steven,IVNH25 C; ccielab@groupstudy.com > > >Subject: Re: DLSW Custom Queuing. > > > > > > > > >Hi Steve, > > > > > >I also have the same question. Have you verified it can only send SNA > > >traffic already? If you haven't, I would say setup two PCs and see if > > >NetBIOS traffic can pass thru the pipe would be a quick way to verify > >this > > >behavior. After you finish this, you can use dspu to see if there's any > >SNA > > >circuits. I'm not working on DLSW right now, but please keep me posted, > > >because I'd like to know the answer too. > > > > > >Thanks, > > >Chang > > > > > > > > > >From: steven.j.nelson@bt.com > > > >Reply-To: steven.j.nelson@bt.com > > > >To: ccielab@groupstudy.com > > > >Subject: DLSW Custom Queuing. > > > >Date: Tue, 7 May 2002 16:20:26 +0100 > > > > > > > >All > > > > > > > >I have noted and tested the scenarios using custom queuing to restrict > > > >bandwidth on an interface based on packet sizes, and I have used as > > > >mentioned in this list the access list for DLSw ports instead of the > >DLSw > > > >keyword in the queuing argument. > > > > > > > >I was wondering does anyone have a URL that outlines the behaviour of > > > >custom > > > >queuing when using DLSw keyword. > > > > > > > >i.e That this keyword permits SNA traffic only and not all DLSw > >traffic, > > >I > > > >have searched CCO but cannot find any reference to it. > > > > > > > >Thanks in advance > > > > > > > >Steve > > > > > > > >Steve Nelson > > > >Customer Engineer > > > >BT Ignite- National Solutions > > > >T: +44 (0)1422 338881 M: +44 (0)7811 944172 > > > >e-mail: steven.j.nelson@bt.com > > > >pp HW A170, PO Box 200(HOM-NZ), London, N18 1ZF > > > > > British Telecommunications plc > > > > > Registered office: 81 Newgate Street London EC1A 7AJ > > > > > Registered in England no. 1800000. > > > > > This electronic message contains information from British > > > >Telecommunications plc which may be privileged or confidential. The > > > >information is intended to be for the use of the individual(s) or > >entity > > > >named above. If you are not the intended recipient be aware that any > > > >disclosure, copying, distribution or use of the contents of this > > > >information > > > >is prohibited. If you have received this electronic message in error, > > > >please > > > >notify us by telephone or email (to the numbers or address above) > > > >immediately.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:53 GMT-3