01-06-2009 12:19 PM - edited 03-04-2019 03:21 AM
Is there a way to stop DLSw from forwarding IPX traffic? I have TONS of printers that have IPX enabled, but they're all hitting the corporate office. I'm under the assumption that it's riding on dlsw, and I'd like to turn it off. In the meantime, I'm turning off IPX on the printers that I can.
Thanks,
John
01-06-2009 12:55 PM
John
If you could make IPX a routed protocol at the remote that would certainly stop DLSw from processing it since DLSW is almost certainly just processing what comes through the bridge group.
HTH
Rick
01-06-2009 12:58 PM
Thanks Rick; that's what I've been reading. The problem is that I don't even *need* IPX on our network. Is there a way for me to quickly filter it other than enabling it on our routers? What type of problems could I get from enabling it to alleviate this problem?
Thanks!
John
01-06-2009 12:59 PM
Hello John,
I see that you found the source of those IPX packets coming into your network
About DLSW if you can control the remote peer you can setup an ethertype based ACL that could block IPX broadcasts from being bridged over DLSW to your side.
give a look to the following
http://www.cisco.com/en/US/docs/ios/ibm/command/reference/ibm_b1.html#wp1012996
bridge-group input-lsap-list
bridge-group input-type-list
to find the correct tool you need to identify what type of encapsulation is used on the IPX SAP packets
Hope to help
Giuseppe
01-06-2009 01:04 PM
Giuseppe,
What is the negative of enabling this on the remote sites, and do I need to enable anything on my local router that everyone connects to?
John
01-06-2009 01:05 PM
John
I did not even ask if the feature set running on the remote routers even has support for routing IPX. If it does, then I believe that just enableing ipx routing on the remote will stop DLSW processing it since it is no longer being bridged as a "non-routed" frame. I see very little down side in doing this.
if your remote routers do not have support for routing IPX then the bridge group filtering that Giuseppe suggests is probably your best bet.
HTH
Rick
01-06-2009 01:12 PM
Do these filters do anything other than filter IPX packets? I don't want any branches to lose connection to anything.
Thanks,
John
01-06-2009 01:18 PM
I'm missing IPX options under my interfaces on most of my routers, so I'm assuming that all of the others are probably the same. The ACL that is applied under the:
bridge-group 1 input-lsap-list 200
Is that acl supposed to have the local subnet listed in it, or is it supposed to have the protocol type listed in hex? There's not an example in what Giuseppe sent me.
Thanks,
John
01-06-2009 01:33 PM
Hello John,
if IPX cannot be enabled the best option you can
or
filter inbound on ethernet interface on remote router
or filter outbond on the dlsw remote-peer on the remote router as suggested by Harold
the problem with IPX is that multiple encapsulations are possible over ethernet.
I found some reference on ethertype values used by ipx
8137
Novell NetWare IPX (old)
8137-8138
Novell, Inc.
So the suggestion is to start from packet capture, identify the encapsulation and then to build the correct ACL to stop this frames
Hope to help
Giuseppe
01-06-2009 01:12 PM
Rick,
This is a good point. Enabling ipx routing globally without assigning any IPX addresses to any interface would work, assuming IPX is supported.
Applying lsap-output-list on the "dlsw remote-peer" statement with the proper ACL would also be an option.
Regards
01-06-2009 01:36 PM
Is this done on the core router, and how would my acl look?
Thanks!
01-06-2009 02:30 PM
John
You do not necessarily need to configure IPX on interfaces, as long as you can enable it globally (make it a routed protocol) then you have removed it from DLSW. If you can not enable IPX (not all feature sets have support for IPX) then the filter is your best option.
The filter is done where IPX enters DLSW - on the remote router.
HTH
Rick
01-07-2009 06:24 AM
Rick/Giuseppe,
When I do the bridge-group 1 input-lsap-list 200, if 200 denies my broadcast, does the command work like a policy map acl? Will it allow all traffic that doesn't match the input list acl, or does it have an implicit deny at the end of the acl? Do I need to permit any other traffic through if I'm not concerned about any IPX? I'm going to test one or two of my sites today, and if it doesn't block SNA traffic, then I'll be rolling it out at all of my locations.
Thanks,
John
01-07-2009 07:11 AM
John,
As with other ACL types, there is an implicit deny at the end. You will therefore need to have a explicit permit any any at the end so that other traffic types do not get denied.
Regards
01-07-2009 03:32 PM
Sounds like IPX sap type 20, IPX bridging. Try blocking that.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide