DLSW peers causing congestions

I noticed lately that my peers to the datacentre is causing congestions issues. Once I remove the peer or redirect it to another router performance on the WAN to the remote site improves.
This doesn't sound like a new issue can anyone relate?

1. Cisco implements DLSw version 2 in 11.3. DLSw version 2 uses UDP for non-llc2 traffic. If one of the DLSw peers router use 11.2 software, you will not see UDP traffic on the DLSw pipe.
2. DLSw icanreach 00 04 f0 specifies SAP (service access point) transported by DLSw. 04 is the default SAP for SNA traffic. I have seen a couple of companies use other SAP value for SNA. F0 is the default SAP value for NETBIOS. In short, DLSW icanreach command is a filter to filter out all traffic, but SNA and NETBIOS, from DLSw. Very powerful command. Please go to the following URL for details:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fibm_r1/br1fprt2/br1fdlsw.htm#xtocid15
3. As per above URL, DLSw icanreach is introduced in IOS 11.0. If you do not get the global command, you may run a pre 11.0 software. This is a big problem for you because any IOS version before 11.2 is not Y2K compliant. (Does anyone still care on Y2K?) Please verify the IOS version by using show version.

Similar Messages

Dlsw+ problem with SNI connection

We have a cisco 1603 router using dlsw+ to peer with a Nortel ASN.
at the cisco end it is x21 connection from the FEP
at the Nortel end it is token ring to an OSA
when we try and start a JES node we get an IBM sense code 800A0000 and the session drops.
The sense code states the transmission was truncated by the receiving node
because the PIU (path information unit) was to large or there was no buffer space available
has anyone seen a similar problem ?
This link was working I am told there have been no changes to the routers, only thing I can think of is that the network reconverged and it is now taking a different path between the two sites. I am asking for trace routes and trying to check if that is right.
Am I going in the right direction ?

Apparently this is strictly a configuraiton problem on the host. There is nothing wrong with the Cisco or Nortel routers.
Please me explain to you the data flow. Assume that the FEP sends a packet to the 1603. (The following applies to a packet from the OSA to the FEP) If the packet is too large for the 1603 to handle, the 1603 will drop the packet. As a result, the SDLC link will go down. Otherwise, the 1603 adds a DLSw header (16 bytes I think), a TCP header (normally 20 bytes), and an IP header (20 bytes). The 1603 uses TCP to tranport the packet with TCP/IP header. Depending upon your TCP setting, TCP may segment the packets into a number of different segments. Then, TCP uses IP to deliver the segment(s) to the Nortel router. If the TCP segments are too big for any routers between the DLSw peer, the router may either fragment the TCP segments or send an ICMP message, according to RFC 1191, to the 1603. The ICMP causes the 1603 to lower the TCP segment size. If any routers between the DLSw peers do not support RFC1191, the routers will drop the TCP segment. This will cause TCP detecting a gap in TCP sequence number. Eventually, TCP will disconnect the virtual circuit, which cause the peer go down.
Once all the TCP segments for the orignal SNA packet arrive at the Nortel router, the TCP stack on the Nortel router assemble the original SNA packet and put in on the token ring interface.
From the description, it looks like that the SNA packet reaches destination VTAM. VTAM finds out that the PIU is too large. If there is any problem on the IP path, I expect to see either:
1. a disconnect on the LLC2 or SDLC circuit. In other words, a DLSw circuit disconnect
or
2. a DLSw peer disconnect
Please check the modtab and find out the max RU size inside the bind. Make sure both VTAMs can handle the RU size.

Dlsw circuits random disconnect

Hello!!
Could somebody help me with this?
We have a dlsw network of almost 1600 remote dlsw peers.
We have six central peer routers.
Sometimes we saw some SNA PU´s down, and after 1 to 3 min return to "CONNECTED" (dlsw circuit). We dont´n see any dlsw peer down, only dlsw circuit falls.
On branch office router we saw by the command "show dlsw ciscuits history detail", that the event before disconnect is
Event
WAN halt-dl
What does this mean?
It is possibly a problem with the Central Peer Router?
The Carrier confirm us no problem with the WAN Network.
The Central Routers are Cisco7200VXR NPE400 512DRAM and IOS 12.4(4)T1
The branch office routers are Cisco1760 IOS 12.3(9).
Thanks for help!!
Pedro.

I'd look into monitoring the CPU usage (as well as the amount of memory used by DLSw Process) of the 1700 series branch routers. It may be that these TCP based connections from the 6 central routers are overwhelming them.
(i.e., http://www.cisco.com/warp/public/63/highcpu_processes.html#tcp_timer)
Especially if the remote routers are pushing a fair amount of traffic with process switching turned on the intfs (i.e., ACLs with the 'log' option on) or if you have stuff like SNMP polls from network mgmt software going.
Also...................
"Disconnectphase. When an LLC end station wishes
to terminate one of its existing connections, it sends
a disconnect (DISC) frame to the other end station,
which responds with UA. The same frame types are
defined for SDLC. With DLSW, these frames are reflected
between partners using the SSP messages
halt-dl (halt data link) and dl-halted (data link halted)
and the circuit is then disconnected. Another DLSW
disconnect scenario is the loss of a transport connection
due to intermediate router failure. When
a DLSw node detects such a failure, it performs a
local disconnect of all connected data links that
were using the failed transport connection."
from: http://www.research.ibm.com/journal/sj/343/gayek.pdf
**Hope this helps**
Based on your earlier statement...
"On branch office router we saw by the command "show dlsw ciscuits history detail", that the event before disconnect is
Event
WAN halt-dl
What does this mean? "
I'd look into the process utilization on the Branch routers

DLSW peer takes 20 min. to establish..Please Help !!!

I have configured a Cisco 7304 with DLSW and the remote peer is not a Cisco router. When the local peer in the Cisco is not configured as promiscuous, it takes about 20min to 1h30min for the peers to get connected.
If the local peer is configured as promiscous, it works good, but we dont want to use this configuration becasuse we want to control the connections on each router.
What can I do in order to solve this problem ?
Attached is the router configuration and the output of a "debug dlsw peers"

Hi,
based on the debug dlsw peer:
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:ADMIN-OPEN CONNECTION state:DISCONN
00:02:00: DLSw: dtp_action_a() attempting to connect peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:DISCONN->WAIT_WR
00:02:00: DLSw: Async Open Callback 172.25.252.254(2065) -> 11004
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-WR PIPE OPENED state:WAIT_WR
00:02:00: DLSw: dtp_action_f() start read open timer for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_WR->WAIT_RD
00:02:00: DLSw: passive open 172.25.252.254(2067) -> 2065
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-RD PIPE OPENED state:WAIT_RD
00:02:00: DLSw: dtp_action_g() read pipe opened for peer 172.25.252.254(2065)
00:02:00: DLSw: CapExId Msg sent to peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_RD->WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
00:02:00: DLSw: dtp_action_j() cap msg rcvd from peer 172.25.252.254(2065)
00:02:00: DLSw: Recv CapExId Msg from peer 172.25.252.254(2065)
00:02:00: DLSw: Pos CapExResp sent to peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAP
00:02:00: DLSw: dtp_action_j() cap msg rcvd from peer 172.25.252.254(2065)
00:02:0
Torrejon0#0: DLSw: Recv CapExPosRsp Msg from peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->WAIT_CAP
00:02:00: DLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAP
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAP
00:02:00: DLSw: dtp_action_k() cap xchged for peer 172.25.252.254(2065)
00:02:00: DLSw: closing read pipe tcp connection for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:WAIT_CAP->PCONN_WT
00:02:00: DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WT
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:TCP-PEER CONNECTED state:PCONN_WT
00:02:00: DLSw: dtp_action_m() peer connected for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:PCONN_WT->CONNECT
at this point the dlsw peer is in state CONNECTED
However you always get a tcp rst or fin right afterwards. Tcp tells dlsw to disconnect the peer.
This can have two potential sources.
The tcp stack on this router or the tcp stack on the remote router has closed the session.
00:02:00: DLSw: dlsw_tcpd_fini() for peer 172.25.252.254(2065)
00:02:00: DLSw: tcp fini closing connection for peer 172.25.252.254(2065)
00:02:00: DLSw: START-TPFSM (peer 172.25.252.254(2065)): event:ADMIN-CLOSE CONNECTION state:CONNECT
00:02:00: DLSw: dtp_action_b() close connection for peer 172.25.252.254(2065)
00:02:00: DLSw: END-TPFSM (peer 172.25.252.254(2065)): state:CONNECT->DISCONN
so the question really is where does the tcp rst come from? Who is closing the tcp connection?
This sequence repeats itself over and over again until it finally stays up.
You can do a
debug ip tcp driver
debug ip tcp transaction
this will show you if you get a disconnect or if this router is sending one. However you have to be a bit carefull with the debugging if you have a lot of tcp activity going on in this router.
Alternative is to take a sniffer trace on the WAN and find out who is sending the tcp reset/fin in that case.
thanks...
Matthias

DlSW/SDLC 1841 ROUTER.

I have just tried to implement by first 1841 router.
I used the same template that I have for over 400 sites ( 1600 , 1700 , 2500 and 3600 series routers )
I get the dlsw peers established no problem.
The problem is on the serial interface in the router.
It is an IBM 5494 controller .
Here is the configuration that I have for the serial interface.
I have added the routers configuration.
Any ideas??? Is there something that I need to add to the serial interface on the 1841's that was not required before ???
My IOS is (C1841-ENTBASE-M), Version 12.3(11)T2
tks.

Hi,
please open a case with the tac. There have been a few problems with sdlc and 12.3T, also there are some issues depending on the hardware you are using.
The Tac will help you to collect all the needed information to understand your problem and then guide you to a resolution.
thanks...
Matthias

Dlsw problem : stuck in WAIT_CAP

Hi all
we had a great problem with some snasw/dlsw routers.
About all dlsw peers remained in WAIT_CAP state( except few resources where dlsw connection ok ) while no ip issues were present between central routers and dlsw remote routers....
The appn snasw links seemed to be ok ( seeing the snasw link command )
A question : there is a relationship between dlsw peer state and snasw link , ie there is an interaction between the 2 processes that could block dlsw peering establishement if there is a mistake on snasw=appn process??
Thanks for feedbacks
Stefano R.

Stefano,
the debugging is telling us that the tcp write and read pipe was opened. Ok so far. Next the router is sending his cap_ex message and then this router waits for the cap_ex from the peer. Which never arrives.
So why is the cap exchange not arriving? It would be very much needed to see the debug from the other end at the same time to have a chance to understand what goes on.
Feb 1 09:12:25.524: DLSw: START-TPFSM (peer 10.237.88.136(2065)): event:ADMIN-OPEN CONNECTION state:DISCONN
Feb 1 09:12:25.524: DLSw: dtp_action_a() attempting to connect peer 10.237.88.136(2065)
Feb 1 09:12:25.528: DLSw: END-TPFSM (peer 10.237.88.136(2065)): state:DISCONN->WAIT_WR
Feb 1 09:12:26.037: DLSw: Async Open Callback 10.237.88.136(2065) -> 11241
Feb 1 09:12:26.037: DLSw: START-TPFSM (peer 10.237.88.136(2065)): event:TCP-WR PIPE OPENED state:WAIT_WR
Feb 1 09:12:26.037: DLSw: dtp_action_f() start read open timer for peer 10.237.88.136(2065)
Feb 1 09:12:26.041: DLSw: END-TPFSM (peer 10.237.88.136(2065)): state:WAIT_WR->WAIT_RD
Feb 1 09:12:26.726: DLSw: passive open 10.237.88.136(28757) -> 2065
Feb 1 09:12:26.726: DLSw: START-TPFSM (peer 10.237.88.136(2065)): event:TCP-RD PIPE OPENED state:WAIT_RD
Feb 1 09:12:26.726: DLSw: dtp_action_g() read pipe opened for peer 10.237.88.136(2065)
Feb 1 09:12:26.726: DLSw: CapExId Msg sent to peer 10.237.88.136(2065)
Feb 1 09:12:26.726: DLSw: END-TPFSM (peer 10.237.88.136(2065)): state:WAIT_RD->WAIT_CAP
Here you see when the write pipe opens, when the read pipe goes up, the tcp connection from the other router came back to us and this router is sending his CapExId to the peer but we dont get a response and time out.
thanks...
Matthias

How to host addresses with DLSw

I'm not quite sure how to ask this question but...
We have leveraged DLSw peers inside our data center. Leveraged meaning more than one client peers with them. How can I keep a client from advertizing unwanted host mac addresses to us and how can we keep from advertizing other clients mac addresses?
I have been told that access list will not work with DLSW and am looking for somebody with first hand experiance/knowlage to share their experiance.
ie when we do a show dlsw reachability I don't want to see every host a client has nor do I want client A to see client B's host.

Hi,
i assume you are talking about a secnario where you have a host end dlsw router, in the data center, and you have one or more branch routers which form dlsw peers with the host end router.
On the host end you have some form of a host mac address reachable. this mac address is the address your clients are connecting too.
There can be quite some different physical setups so that is why i try to keep this discussion a littlebit "high level".
If you assume that your host end mac address, the one your clients connect too, is 4000.3745.0000, than you can simply configure on the hostend router:
dlsw icanreach mac-address 4000.3745.0000
dlsw icanreach mac-exclusive
If you are in a pure sna environment and you i.e. have the sna saps 4 and 8 in use than you can also configure:
dlsw icanreach sap 0 4 8
All of these commands are advertised via runtime capabilities exchange to all connected dlsw remote peers.
The first one:
dlsw icanreach mac-address....
Is creating a static dlsw reachability cache entry on the remote peers.
That prevents them from exploring to all possible peers. They will only verify that the mac address in the static reach entry is really reachable via the peer the entry points to.
dlsw icanreach mac-exclusive
this one creates a filter, both on the branch and the host end router.
On the branch router it prohibites dlsw canureach frames for any other mac address than the ones you have configured. In other words no sna explorer/test with a different dmac than the configured one is forwarded.
On the host end router it prohibites the same with the source address. So it makes sure that no circuits can come up with any other mac address than the configured one. ( you can configure more than one address, either multiple statements or if it is a block of addresses you can use the address mask).
dlsw icanreach sap 0 4 8
this applies to all frames, basically on the branch routers it prohibits the forwarding of any other frame with dsap anything else than the configured one.
Also:
access-list do work with dlsw!
one very simple and powerfull one is like this:
access-list 200 permit 0x0000 0x0d0d
i.e.
interface ethernet x
bridge-group 1
bridge-group 1 input-lsap-list 200
access-list 200 only allows saps 0, 4, 8, 12. Command and response.
You can also apply the same list on a source-bridge statement on a tokenring interface.
This one filters as close to the source as possible. Frames we dont want to transport dont even enter the router to be processed. However it requires a config step on every branch router. You can also apply address lists on the bridge-group or source-bridge statements.
the dlsw icanreach filters work aswell but the router first processes the frame to figure out it needs to be dropped. But they are configured only on the host end, the central router.
Let me know if you need more information.
thanks...
Matthias

CS6 dreamweaver - adding images causes dreamweaver to hang

We have a cs6 master site licence at our school.
When adding an image or video to a basic html document, via insert/image the application immediately hangs. I have seen similar throughout the forum but nothing for CS6.
This does not happen to all users but about 70%. Any ideas?

Are the images all from the same source? And can we assume all computers are the same, or very similar specs? I have seen cases where it happens because of the remote data source where the data is taking awhile to load. Or it may be possible if the exact same image is being called from a shared data source and all students are accessing it at once it could be causing congestion to access the file.

Load balance between DLSw and CIP routers

Take a look on this environment:
- 4 routers receiving all DLSw peers and circuits
- 4 routers with CIP boards connected to 2 mainframes
All CIP routers are configured with same MAC address. All routers (DLSw and CIP) are connected on a Ethernet LAN switching, so this traffic are pure LLC2.
How I can balance the traffic between DLSw and CIP routers ?
Thank's in advance.

I am not sure if I totally understand the topology. Let me rephrase it. Please correct me if I misunderstand the topology. In a data centre, there are 4 DLSw routers terminating DLSw peer connections from the remote sites. In the same data centre, there are 4 CIP routers which connects to 2 mainframes. CSNA is configured on all CIP router, which uses the same MAC. You configure transparent bridging on the DLSw routers, which connect to the same ethernet switches as the CIP routers. You configure SR/TLB on the CIP routers; so that all LLC2 circuits coming from the DLSw routers connect through the ethernet interfaces of the CIP routers.
Do you want the LLC2 circuits from a DLSw router load balance across 4 CIP routers? As duplicate MAC address is not allowed, there is no way to connect all 4 DLSw routers and CIP 4 routers on the same VLAN.
I can think of a couple of workarounds.
1. Enable SNASw on the 4 DLSw routers. Create a VDLC port on all 4 DLSw routers. The MAC address of the VDLC interface is the same. The VDLC MAC address is pointed by the remote SNA stations. Each DLSw router uses one of the CIP routers as DLUS.
2. If this is the case, create 4 VLANs on the ethernet switches. Connect a pair of DLSw router and CIP router to each VLAN.

DLSW - Transparent Bridging via FE Subinterfaces?

Hi. I have a 7206 router connected with FE to a Catalyst 6509, via 802.1Q trunking. Two VLANs. The router supports DLSW to remote sites, and the switch transports SNA traffic to the router with transparent bridging through one of the FE subinterfaces.
What I'd like to do is establish DLSW peering between the router and another device on the local LAN -- in other words, also through the FE interface connected to the 6509. I don't have another physical FE interface on the router. Two questions:
1) Is there any reason I would run into difficulty setting up another VLAN on the switch and another FE subinterface in the router, and using the new VLAN/subinterface for DLSW, while keeping the other subinterface configured to use transparent bridging?
2) In that configuration, might there be any issue transporting SNA into and out of the router via the one FE subinterface configured with a bridge group and the other FE subinterface being used for the DLSW path? That is, I will need the router to decapsulate the SNA coming in via DSLW on one subinterface, and bridge it out the other subinterface, and vice-versa.
Thanks for any guidance.

I'm not sure how well I managed to explain the scenario in the previous post. An attempt to clarify:
VLAN1 -\ FE.Subinterface1
[6509] VLAN2 --> <=-802.1Q-=> FE.Subinterface2 [7206]
VLAN3 -/ FE.Subinterface3
6509
VLAN 1: bridge group 1
VLAN 2: bridge group 1
VLAN 3: L2-only VLAN (no definition in the MSFC). Used only to transport DLSW (and other IP) traffic to and from a router also running DLSW to FE.Subinterface3 on the 7206 through the 802.1Q trunk.
7206
FE.Subinterface1: bridge-group 1
FE.Subinterface2: bridge-group 1 (blocked by STP)
FE.Subinterface3: not in a bridge group. The interface through which the 7206 communicates with an internal router running DLSW (transporting SNA for a device directly connected to that internal router).
Traffic path
SNA must travel between the device the 7206 is DLSW peering with through FE.Subinterface3, and a device (a mainframe OSA Express interface) the 7206's SNA traffic can reach via transparent bridging through FE.Subinterface1.
The "steps": the 7206 uses FE.Subinterface3 to receive DLSW TCP/IP-encapsulated SNA traffic from the other DLSW router. The SNA traffic gets decapsulated in the 7206, and is bridged to the mainframe OSA Express interface via FE.Subinterface1. And of course the reverse, from the mainframe, transparently bridged into the 7206 through FE.Subinterface1 and sent via DLSW through FE.Subinterface3.
Do-able? Thanks!

SNA over the Internet

I am tasked with finding cheaper broadband solutions for connecting remote facilities back to corporate. I need to set up IPSEC tunnels from the remote to corporate that allow me to not have to change my current private addressing. This I believe I should have no problems accomplishing. The tricky part is I also have to run SNA over the Internet. Has any one tried to run a DLSW type connection over a DSL or Cable modem IPSEC tunnel. If so did, did it work or was the latency of the Internet too large to keep the dlsw peers active?
Any suggestions are appreciated.

Hi,
if you want to run dlsw over a vpn/nat solution you need to look at the following:
http://www.cisco.com/en/US/partner/tech/tk331/tk336/technologies_tech_note09186a0080093db6.shtml
this discusses problems with dlsw version 1, RFC1795, this is the default for cisco routers. The point is that the dlsw peer establishment is defined as a bringup of two single tcp connections until the capabilities exchange is done. Each router opens his own write pipe and recieves the read pipe from the other one. So each of them has two tcp pipes open at that point. Then the router with the "numerical" higher ip address drops his pipe on the local tcp port 2065.
This can cause quite some trouble if you dont control the ip nat translation inbetween. So both sides either think they have the numericaly higher ip address on its local peer and both drop the connection or both think they have the lower one and the connection times out.
Additional we commited a change to dlsw with CSCeb47150 which allows the remote device to bring up a dlsw version 2, RFC2166, peer to head end system, and in that case the peer bringup is defined with only one tcp pipe and the whole problem with who has the numericaly higher or lower ip address does not exist anymore. I copy the release note for CSCeb47150 right below here:
Symptom: Customer has DLSW defined at two locations. The locations are connected together over a
VPN tunnel. The peers start to establish and drop after capabilities excahnge.
Conditions: NAT is being used but outside the customer's point of control.
Problem: DLSw Version 1, RFC1795, defines the dlsw peer with tcp encapsulation to use 2 tcp pipes
for the peer bringup. A Write and a Read pipe. Both routers establish their respective Write pipe.
That means that if router A opens a dlsw peer to router B router A establishes his Write pipe to
router B and router B than establishes his Write Pipe back to router A. Next the capabilities
exchange happens and during this exchange the two routers decide if they can drop one tcp
connection and use the resulting tcp session for traffic in both directions. This decision is
based on the numericaly order of the local peer ip addresses. The peer with the numericaly higher
ip address is supposed to drop his tcp pipe. This is defined in RFC 1795 section 7.6.7.
If ip NAT is used inbetween the two dlsw peer routers and the NAT is changing the order of numericaly
higher or lower local peer ip address the peer may fail to establish. Both routers may think that they
are the higher ip address and both drop their tcp session or both think they are the lower ip address
and wait for the other end to take action.
Workaround: The user must preserve the numericaly order of the dlsw local peer ip addresses through
ip NAT. This is not always possible and in any case it is not an easy task.
Solution:
This ddts added a new configuration option to the dlsw peer statements:
v2-single-tcp
This is intended to do the following:
DLSw Version 2, RFC2166, defines the dlsw tcp peer bringup with a single tcp session. So above Problem
does not exist anymore since there is only one tcp session and it makes no difference which end has the
numericaly higher or lower ip address.
The v2-single-tcp keyword will instruct this router to bring up a dlsw Version 2 peer and thus both routers
will automatically only use 1 tcp session to establish the peer.
The usage of the new keyword should be like this:
Branch router A tries to establish a dlsw peer to data center router B.
Data center router B is running ios 12.0 or higher and thus already supporting dlsw version 2.
The dlsw local peer configuration on data center router B is either promiscous, to allow any incoming
peer connection, or if you have to configure each connection individual the peer to branch router A is
configured to be passive.
Branch router A is configured on his dlsw remote-peer statement with the new keyword v2-single-tcp and thus
it starts a version 2 peer to the central data center router A.
Caveats:
DLSw version 2 does not support priority peers.
thanks...
Matthias

How can we make sure my Dad (92) hangs up properly...

My Dad is 92 and lives alone. He is a Plusnet customer, as is my brother, whilst I am with BT. When my Dad makes or takes a call he doesn't always disconnect it properly on his cordless phone. Then we can't get through to him as we get 1571 instead (for hours!!) and if he does it when he calls my brother then for some reason my brother can't then get dial-tone to ring anyone. I don't seem to have the problem, possibly because he does this locking up thing with a day-time call and then has made another by the time he and I speak.
We've spoken to BT who say they can't test for speech occurring, he doesn't seem to hear the howler and at his age is getting tetchy and confused by us asking him to make sure he has hung up properly. Plusnet told my brother they can't even test the line which seems bizarre.
Some years ago, 'forced release' would have made sure the remaining party was disconnected at the next charge increment and I fail to see why this doesn't happen. So in theory I could ring him, not hang up properly myself, lock his line up and go on 2 weeks holiday coming back to a big bill . . . really?
I'm sure this must be a problem with other elderly users and being over 40 miles away from us both and no idea if he's ok is very concerning. Does anyone have any advice please?

Time it so that it disconnects for one minute before he gets up in the morning, and one minute in the late evening.
The other option is to leave a cheap mobile turned on, so that you can call it to tell him to put the phone back.
Forced release used to be implemented on Strowger Exchanges, to avoid holding up the limited number of switches available, and causing congestion.
With the digital network, its not a problem, however if the called party clears, it will eventually disconnect, but I am not sure what the delay is now.
There are some useful help pages here, for BT Broadband customers only, on my personal website.
BT Broadband customers - help with broadband, WiFi, networking, e-mail and phones.

Intermittently having issue sending scans to networked directory folder HP Officejet Pro 8600 N911g

Hello All,
I have a printer installed an AIO HP Officejet Pro 8600 N911g which is cappable of scanning either by flatbed or feeder to a networked drive/folder. For the most part this works fine, however 2 times out of 10 it produces the following error;
"Cannot connect to \\'Server details\Folder location path'. Make sure the remote computer is turned on."
Now I have seen many post about disabling the filewall and other, however none of this type after an install.
Some obvous checks have been made already, Network cable replace, Changing of the destination folder location, and reseting the password for the scanner to auth as well as confirming the permisions. And each time the tests via the web console and physical tests work fine though this doesn't last.
Could anyone help?
Thanks

Hi @Paperjam27
From your description, it sounds like the issue is intermittent. It can sometimes be challenging to identify the root cause of an issue when the problem is not consistent, but I am happy to work with you towards a solution. I suspect the issue might have something to do with the network. I know you said you have tried a new cable and done some troubleshooting already but bear with me here.
When you say you replaced the cable, do you have an Ethernet cable connected between the printer and the router? if not, then I wonder if there is some sort of interference on your wireless connection. Is your router is a dual band router broadcasting both 2.4 and 5.0 frequency? The printer only works on 2.4GHz, maybe this is the root cause.
The channel your router is set to can impact your network consistency too. For example, if you are on channel 11 and others in your area are also on channel 11 or even 9 or 10 it causes congestion on that channel. Think of the channel like a highway or interstate, the more cars on that highway/interstate, the slower you go due to congestion, if you are on a highway with less people are on it, it is more like smooth sailing! You can print a network configuration page to see what channel you are using and see what channel others in your area are no. If the higher channels are most common you might consider changing yours to 1, 2, or 3, and visa versa. How to: Printing a Network Configuration Page.
has this ben an issue since you have had the printer or did it recently start happening? If this only recently started, can you think of anything that changed recently? Do you have only one access point (router) or do you have a secondary router or extender? Can you think of anything that might be interfering with your network, and do you find the issue occurs more at a certain time of the day than others?
I found on my network at home, I was often seeing delays in response time in the early evening because others are coming home from school and work and 'clogging up the channel', I changed the channel and have had little to no issue since.
Let me know if you think of anything, and post back with the answers to the questions I have posted and I will get back to you. Thanks.
Please click the Thumbs up icon below to thank me for responding.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please click “Accept as Solution” if you feel my post solved your issue, it will help others find the solution.
Sunshyn2005 - I work on behalf of HP

QoS questions SG200

If I don't have any VOIP devices, should I just leave all the QoS settings to default? We have an AirPlay speaker on our network, so could there be benefits in raising the QoS priority so that the audio streams smoothly to this device?
Cheers,
Max

Hi MaxHodges, the default QoS will apply to only tag VLAN packet from 802.1p. Otherwise the traffic is treated first in first out basis and switching at hardware speed.
Unless you have a significant amount of traffic that causes congestion there shouldn't be any problem. Separating traffic on a VLAN may logically separate the packets but it wouldn't separate the physical wire usage. So if everything is working as intended then there shouldn't be any need to do anything.
If you are experiencing problems with things like choppiness, you may want to troubleshoot from a congestion point of view such as removing all other traffic off the link and see if its clear or continues to have a problem. At that juncture, if you determine that with additional traffic load causes a problem then it may be prudent to think about a VLAN or reducing the amount of traffic on the un-aggregated link or possibly adding another uplink in to your network.
If the choppiness/quality doesn't clear with just your music box going then chances are it's not the switch or if it's the switch then it'd likely be a wiring issue or doubtfully the switch itself being flaky.

Query: Best practice SAN switch (network) access control rules?

Dear SAN experts,
Are there generic SAN (MDS) switch access control rules that should always be applied within the SAN environment?
I have a specific interest in network-based access control rules/CLI-commands with respect to traffic flowing through the switch rather than switch management traffic (controls for traffic flowing to the switch).
Presumably one would want to provide SAN switch demarcation between initiators and targets using VSAN, Zoning (and LUN Zoning for fine grained access control and defense in depth with storage device LUN masking), IP ACL, Read-Only Zone (or LUN).
In a LAN environment controlled by a (gateway) firewall, there are (best practice) generic firewall access control rules that should be instantiated regardless of enterprise network IP range, TCP services, topology etc.
For example, the blocking of malformed TCP flags or the blocking of inbound and outbound IP ranges outlined in RFC 3330 (and RFC 1918).
These firewall access control rules can be deployed regardless of the IP range or TCP service traffic used within the enterprise. Of course there are firewall access control rules that should also be implemented as best practice that require specific IP addresses and ports that suit the network in which they are deployed. For example, rate limiting as a DoS preventative, may require knowledge of server IP and port number of the hosted service that is being DoS protected.
So my question is, are there generic best practice SAN switch (network) access control rules that should also be instantiated?
regards,
Will.

Hi William,
That's a pretty wide net you're casting there, but i'll do my best to give you some insight in the matter.
Speaking pure fibre channel, your only real way of controlling which nodes can access which other nodes is Zones.
for zones there are a few best practices:
* Default Zone: Don't use it. unless you're running Ficon.
* Single Initiator zones: One host, many storage targets. Don't put 2 initiators in one zone or they'll try logging into each other which at best will give you a performance hit, at worst will bring down your systems.
* Don't mix zoning types: You can zone on wwn, on port, and Cisco NX-OS will give you a plethora of other options, like on device alias or LUN Zoning. Don't use different types of these in one zone.
* Device alias zoning is definately recommended with Enhanced Zoning and Enhanced DA enabled, since it will make replacing hba's a heck of a lot less painful in your fabric.
* LUN zoning is being deprecated, so avoid. You can achieve the same effect on any modern array by doing lun masking.
* Read-Only exists, but again any modern array should be able to make a lun read-only.
* QoS on Zoning: Isn't really an ACL method, more of a congestion control.
VSANs are a way to separate your physical fabric into several logical fabrics. There's one huge distinction here with VLANs, that is that as a rule of thumb, you should put things that you want to talk to each other in the same VSANs. There's no such concept as a broadcast domain the way it exists in Ethernet in FC, so VSANs don't serve as isolation for that. Routing on Fibre Channel (IVR or Inter-VSAN Routing) is possible, but quickly becomes a pain if you use it a lot/structurally. Keep IVR for exceptions, use VSANs for logical units of hosts and storage that belong to each other. A good example would be to put each of 2 remote datacenters in their own VSAN, create a third VSAN for the ports on the array that provide replication between DC and use IVR to make management hosts have inband access to all arrays.
When using IVR, maintain a manual and minimal topology. IVR tends to become very complex very fast and auto topology isn't helping this.
Traditional IP acls (permit this proto to that dest on such a port and deny other combinations) are very rare on management interfaces, since they're usually connected to already separated segments. Same goes for Fibre Channel over IP links (that connect to ethernet interfaces in your storage switch).
They are quite logical to use and work just the same on an MDS as on a traditional Ethernetswitch when you want to use IP over FC (not to be confused with FC over IP). But then you'll logically use your switch as an L2/L3 device.
I'm personally not an IP guy, but here's a quite good guide to setting up IP services in a FC fabric:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/cli_4_1/ipsvc.html
To protect your san from devices that are 'slow-draining' and can cause congestion, I highly recommend enabling slow-drain policy monitors, as described in this document:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/5_0/configuration/guides/int/nxos/intf.html#wp1743661
That's a very brief summary of the most important access-control-related Best Practices that come to mind. If any of this isn't clear to you or you require more detail, let me know. HTH!

DLSW peers causing congestions

Similar Messages

Maybe you are looking for