DLSW and 4510

Hi,
We are trying to configure dlsw on a Cat4510R switch that is connected to 2 routers for redundancy. DLSW is not supported on the 4500 switches. What is the best way to configure DLSW in this situation?  Looking for configuration assistance.
Thanks,
Greg

You don't need to do anything in the switch.
The routers must be configured properly, and the details are dependant by the topology and applications.
In case of doubts, I recommend you engage a reputable consultant or certified partner with proven SNA-specific experience.

Similar Messages

  • Issues with CWLMS 3.2 RME 4.3.1 cannot fetch vlan.dat off a VSS and 4510.

    Hi,
    I am having a major headache with RME collecting the vlan.dat from a VSS and 4510, the device and credentials work fine, however when archiving the config i get partial success due to vlan failing. You can see in the IC_Services log that it attempts to TFTP the .dat file off which it fails with, i believe vlan fetch is only supported by SSH or telnet
    when you do a CDA test both devices pass on everything..

    managed to log on and please see below, tftp on one device works fine but from the 4510 or vss still fails
    GRA_CHUB_CR_01#copy cat4000_flash: tftp:
    Source filename []? vlan.dat
    Address or name of remote host []? 172.20.220.10
    Destination filename [vlan.dat]?
    %Error opening tftp://172.20.220.10/vlan.dat (Timed out)
    GRA_CHUB_CR_01#
    DAR_R002_AS_01#
    DAR_R002_AS_01#copy flash:vlan.dat tftp:
    Address or name of remote host []? 172.20.220.10
    Destination filename [vlan.dat]?
    616 bytes copied in 0.009 secs (68444 bytes/sec)
    DAR_R002_AS_01#

  • Dlsw and 802.1q

    Will DLSw and 802.1q ever be supported together or are there some technical issues that will always force you to use isl trunking with dlsw instead of 802.1q?
    problem is that there are switches that don't support isl.

    DLSW support matrix documentation at:
    http://www.cisco.com/warp/public/cc/pd/ibsw/ibdlsw/tech/dls24_rg.htm
    in table B-3 and note 5, clearly states that 802.1q is not supported.
    If you configure, it might work but it's not supported by TAC as it has not been dev-tested for this function

  • DLSW and Tunnel Interfaces problem

    We have a pair of routers with tunnel interfaces and DLSW between them.
    Some times the tunnel interface goes down thus loosing service trough DLSW.
    Is there any problem reported between DLSW and this kind of tunel interfaces ?

    Hi,
    i assume you are using dlsw tcp peers.
    In general dlsw does not know over what infrastucture the connection really runs. Dlsw gives data to tcp and tcp is responsible for doing the actual transmission.
    I dont know of any problems with dlsw and tunnel interfaces in general.
    Some more information might help to understand the problem.
    What type of tunnel are you using? GRE?
    What version of ios are you running?
    Do you use additional encapsulation overhead like ipsec ect?
    Does tcp on this router use path mtu discovery?
    thanks...
    Matthias

  • DLSw and IPSEC

    Can anybody tell me if you can have a DLSw+ peer and IPSEC tunnel on the same router? We want to utilize DLSw+ on a branch router and use IPSEC across the WAN back to the corporate office?
    Has anybody configured this before?
    Any lessons learned?
    Recomendations?
    Thanks!

    Hi David,
    Yes, multiple customers have deployed this, and it has been tested and measured in specific customer proof of concept labs. The only issue that I'm aware of is that the MTU size requirements are affected by encryption, so be sure to take that into account.
    http://www.cisco.com/en/US/tech/tk331/tk336/technologies_tech_note09186a00801d3a9d.shtml
    In terms of performance, everyone's traffic is somewhat different, so it's impossible to say for sure. From what I remember of the proof of concept tests, 2600 routers did DLSw+ and software encryption just fine at DS0 rates.
    Rgds, Dan

  • 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 and the MAC that won't bridge....

    I'm trying to migrate from a CIP attached router (7204) to an OSA card on our mainframe for our SNA connectivity. I've run into a bit of an odd problem.
    It seems I can make a connection to the MAC on the OSA card from a subnet within my data center (I've tried several), but I can't make one work from a remote location via DLSW. The same connections work to the CIP attached router. To me, it looks like I have a problem with bridging, but I'm not 100% sure. I'm tring to connect to 00096b1ade31 on SAP 4.
    I have a DLSW tunnel up and running from my remote location directly to my core switch (6509). The MAC in question is attached directly to the same core switch. I have bridging enabled on the VLAN, but I don't see the MAC in the bridge table. I do however see the MAC in the MAC address table.
    WPG6509-A#SH DLSW REA
    DLSw Local MAC address reachability cache list
    Mac Addr status Loc. port rif
    0000.836c.4278 FOUND LOCAL TBridge-001 --no rif--
    0000.c1a2.e717 FOUND LOCAL TBridge-001 --no rif--
    0002.319c.6194 FOUND LOCAL TBridge-001 --no rif--
    0002.31b8.1483 FOUND LOCAL TBridge-001 --no rif--
    0002.31b8.1576 FOUND LOCAL TBridge-001 --no rif--
    0002.31b8.20e0 FOUND LOCAL TBridge-001 --no rif--
    0002.31c6.39c7 FOUND LOCAL TBridge-001 --no rif--
    0009.6b1a.de31 SEARCHING LOCAL
    0020.00a4.5a28 FOUND LOCAL TBridge-001 --no rif--
    0070.3006.5d03 FOUND LOCAL TBridge-001 --no rif--
    4000.2216.3002 FOUND LOCAL TBridge-001 --no rif--
    4080.0000.0000 FOUND LOCAL TBridge-001 --no rif--
    DLSw Remote MAC address reachability cache list
    Mac Addr status Loc. peer
    0002.31b8.1483 FOUND REMOTE 10.89.1.2(2065)
    0009.6b1a.de31 SEARCHING REMOTE
    4000.0255.1091 SEARCHING REMOTE
    WPG6509-A#sh mac-address-table | include de31
    * 300 0009.6b1a.de31 dynamic Yes 0 Gi2/1
    WPG6509-A#
    WPG6509-A#sh run int vlan 300
    Building configuration...
    Current configuration : 282 bytes
    interface Vlan300
    description Mainframe VLAN
    ip address 10.3.1.2 255.255.255.0
    no ip redirects
    ip directed-broadcast 176
    ip route-cache flow
    ip ospf network broadcast
    standby 3 ip 10.3.1.1
    standby 3 priority 125
    standby 3 preempt
    bridge-group 1
    hold-queue 1000 in
    end
    WPG6509-A#sh run int gig 2/12
    Building configuration...
    Current configuration : 92 bytes
    interface GigabitEthernet2/12
    switchport
    switchport access vlan 300
    no ip address
    end
    Other config tidbits:
    bridge 1 protocol vlan-bridge
    WPG6509-A#sh run | include dlsw
    dlsw local-peer peer-id 10.3.4.1
    dlsw remote-peer 0 tcp 10.123.1.1
    dlsw remote-peer 0 tcp 10.89.1.2
    dlsw remote-peer 0 tcp 10.149.2.1
    dlsw icanreach sap 0 4
    dlsw bridge-group 1
    Ideas welcome!

    Hi Tom,
    The OSA has to be set up in non-QDIO mode.
    Here is a link to an IBM redbook that should help, see Chapter 7.
    http://www.redbooks.ibm.com/abstracts/sg245948.html?Open
    I assume that you have an XCA and a Switched Major Node defined for this and both are active. When you see the MAC seraching, at the router local to the OSA, there is a test frame being sent out to the OSA. If the OSA answers test, then from the "show dlsw reach", it will change to "found".
    We did have a problem where voice discovery caused a problem for the OSA, but this would prevent the link from connecting, see Bug ID CSCea90470. Sounds like this is not the case here.
    I suggest sniffing the port where the OSA is connected to see if the test frame is going out to the OSA. If so and the OSA is not answering the test, then you may have to enlist IBM support at that point.
    Jim

  • Design question about SNASw, DLSW and VDLC

    Hello,
    I have a question about Ethernet redundancy in an APPN environment.
    Let's have an example with 3 routers running SNASw that are on the SAME LAN (no vlans) as the Mainframe's OSA (one OSA only). APPN is configured on the Mainframe.
    Using DLSw+, all downstream PUs are connected to the 3 routers. Can I define in the VDLC interface of each router the SAME MAC address, and this MAC address be the destination MAC of the downstream PUs?

    Hi,
    yes, headend routers are the ones in front of the OSA/mainframe.
    If you replace a tokenring with ethernet in the data center/headend, than the snasw dlsw solution is almost perfect for you. If you use hpr/ip to connect upstream to the host you are all set.
    In that case you dont advertise any mac addresses on the local ethernet between the snasw/dlsw routers and the osa since it is hpr/ip. Basicaly ip routing only.
    From the clients perspective, they dont really know that there is a change since you replicate the old tokenring mac address as vdlc mac address/snasw port and the end systems still connect to them like they did before.
    In respect to dlsw ethernet redundancy we have to be a bit carefull not to mix the scenarios.
    Dlsw ethernet redundancy is designed for the branch. Not the data center.
    If you use dlsw ethernet redundancy with ethernet switches, and in almost all cases today ethernet means ethernet switches, you configure a mac address mapping between artificiall local mac addresses and your real remote mac address of the host.
    On each router you configure a unique local mac address. Than you point half of your end systems dmac to the local mac address configured on router1 and the other half to the local mac address configured on router2. That way you achive load balancing.
    The two routers exchange their mapping and in case router1 looses the connection to router2, router1 will activate the mapping it learned from router2 aswell and then take over those circuits additional.
    If you decide that you configure on router1 the local mac address equal to the remote mac address, because you have a large number of clients and can not simply change the damc's on all of them, than you need to configure a "dummy" mapping on router2 and router1 will get all the circuits in this example. router2 would be purely for redundancy in case router1 goes down.
    If you think about this than it is clear why dlsw ethernet redundancy is designed for the branch. In the branch we map local to remote mac addresses and the remote mac addresses are the hosts. Typically there are only a limited number of host mac addresses to map.
    If you turn this around and put dlsw ethernet redundancy on the host end than you have to map all clients. If you have only one or two clients this is certainly doable. But if you have a large nuber of clients this is simply not manageable.
    thanks...
    Matthias

  • Port Channels - WLC 5508 and 4510

    LACP and PAgP are not supported on the controller and it appears that the 4500 series will not use LAG.
    interface Port-channel10
     description WLC Port-Channel
     switchport
     switchport mode trunk
     service-policy input AutoQos-4.0-Input-Policy
     service-policy output OUTPUT-PRIORITY-POLICING-ETHERCHANNEL
    interface GigabitEthernet3/1
     description Cisco 5508 Wireless Controller 
     switchport mode trunk
     channel-group 10 mode active
     spanning-tree link-type point-to-point
    interface GigabitEthernet3/2
     description Cisco 5508 Wireless Controller 
     switchport mode trunk
     channel-group 10 mode active
     spanning-tree link-type point-to-point
    I am getting the error, "lacp not enabled on remote port..". I removed the 2nd fiber cable and removed the channel-group so I could get the WLC back online. Any help would be greatly appreciated. 

    In order to get the ether channel to work with the WLC you need to change your configuration from:
    interface GigabitEthernet3/1
     channel-group 10 mode active
    interface GigabitEthernet3/2
     channel-group 10 mode active
    To mode ON
    interface GigabitEthernet3/1
     channel-group 10 mode on
    interface GigabitEthernet3/2
     channel-group 10 mode on
    Mode ON tells the switch to do Link Aggregation Protocol and does try and negotiate using one of the two control protocols LACP or PAgP.
    using mode ON is part of the configuration guide when enabling Cisco WLC LAG option.

  • Routing issue between Cisco Nexus and Cisco 4510 R+E Chassis

    We have configured Cisco Nexus 7K9 as core and Cisco 4510 R+E as access switches for Server connectivity.
    We are experiencing problem in terms of ARP learning and Ping issues between Cisco Nexus and end hosts.

    Hi,
    So you have N7k acting as L3 with servers connected to 4510?.
    Do you see the MAC associated with failing ARP in 4510?. Is it happening with all or few servers?. Just to verify if it is connectivity issue between N7k and 4510, you can configure an SVI on 4510 and assign address from same raneg (server/core range) and perform a ping.
    This will help narrow down if issue is between server to 4510 or 4510 to N7k.
    Thanks,
    Nagendra

  • 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 ER+ at the central site

    The network topology that I have is two MSFCs and two external routers at central site and two MSFCs and two external routers at the remote site.
    DLSW is activated on the external routers. In regards to DLSW+ ER at the central site, only one translational or transparent bridge can be active at a time. Manual intervention is required to cause a router to take over for the other router. Is there any other way to have some means of dlsw redundancy (w/o manual intervention) at the central site (for ethernet environment only)?
    Second, DLSW ER+ cannot be deployed easily at the central site, since you need a lot of dlsw mapping. On the other hand, you also need local SNA PUs to be able and reach the CIP (both located at the central site) but reside on a different broadcast domain. Any ideas?
    Thanks

    Hi,
    on the central side, host end, there are a couple of things you can do.
    The potential solutions mentioned below are in the order that cisco would prefer.
    1.
    The most clean thing to do is to upgrade and configure the mainframe for appn and allow hpr/ip between the host end router and the host.
    You will need to run dlsw/vdlc/snasw in the host end routers to be able to do this.
    It also requires that you have ip connectivity to the mainframe.
    If you do this than the mac address, the remote devices connect to, is configured as a snasw vdlc port in the routers. Both of them are active all the time, the remotes will learn the remote mac address over both peers and as such you have automatic, non manual intervention, redundancy, loadbalancing. The mac addresses in this case only exist in the central router. Nowhere else. The remote device does not know anything about this change.
    Each of the head end dlsw/vdlc/snasw routers will have at least one hpr/ip uplink to the host. This is routed ip traffic into the mainframe.
    In that case you can also define the physical ethernets as snasw ports, do hsrp on it and configure a hsrp mac address, this mac address would then be used as dmac for local clients connecting to the host.
    2.
    If for some reason you can not do the appn/snasw configuration you still have some options.
    If you are using cisco cip's with csna today than you most likely have on path into the mainframe today for each mac address.
    You can configure multiple vlans between the dlsw router and the cip router, i.e. dot1q trunk, and on the cip router you can configure multiple virtual ring groups and more than one csna path statement into the host. At the end you attach each vlan to one of the channel path, configure srtlb for each vlan into a unique vring, and then configure a different adapter number on each of the internal tokenring lans with the same mac address.
    On the dlsw router you can configure multiple bridge groups into dlsw and each of those bridge groups goes to a different vlan. If you do this with two dlsw routers going to the same cip router you then end up with two channel access's and one vlan on each of the dlsw routers. If you do it to two cip routers you need 4 vlans. Just make sure that you dont bridge the vlans together.
    The remotes learn than the remote mac address over both peers and your redundancy is established.
    For the local clients this solution has the draw back that you need to pick a vlan where to connect them. There is no automatic redundancy, like hsrp in the first example, for those.
    3.
    You can enable both dlsw routers towards a single bridge-group and apply a mac address filter inbound to the bridge group only allowing the mac address/es of the hosts as source mac address.
    That way you kill the potential loop on the head end. You will also need to put on as much restrictive filtering as possible to only allow the traffic that is wanted.
    thanks...
    Matthias

  • Multiple VLANSs with 1 bridge group for DLSw+

    I am working on a network with a DLSw+ on a 6500 MSFC with multiple VLANs. There is one bridge group and it is mapped to DLSw + and to each VLAN. It is working, but I want to know if there is an and advantage placing each VLAN in it's own bridge group and mapping each bridge group to DLSw+.
    I have an example of the config I am referring to below: I would appreciate any feedback or comments on this.
    bridge 1 protocol ieee
    dlsw local-peer peer-id 10.88.1.2 group 1 border promiscuous
    dlsw bridge-group 1
    dlsw bridge-group 2
    dlsw bridge-group 3
    dlsw bridge-group 4
    dlsw bridge-group 5
    dlsw bridge-group 6
    dlsw bridge-group 7
    dlsw bridge-group 8
    int vlan 10
    bridge-group 1
    int vlan 11
    bridge-group 2
    int vlan 12
    bridge-group 3
    int vlan 13
    bridge-group 4
    int vlan 14
    bridge-group 5
    int vlan 15
    bridge-group 6
    int vlan 16
    bridge-group 7
    int vlan 199
    bridge-group 8
    Thanks,
    Bruce

    exactly.
    When the router receives bridged packet whose destination MAC address is not on the router's bridge table, the router will flood the packet to all the VLANs if all the VLANs are on the same bridge group. Similary, the router forwards broadcast traffic to all VLANs.
    If different VLANs are under different bridge group, the traffic mentioned above is noly forwarded to DLSw.l

  • 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

  • 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!

Maybe you are looking for