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.
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.
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?
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
to find the correct tool you need to identify what type of encapsulation is used on the IPX SAP packets
Hope to help
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?
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.
Do these filters do anything other than filter IPX packets? I don't want any branches to lose connection to anything.
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.
if IPX cannot be enabled the best option you can
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
Novell NetWare IPX (old)
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
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.
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.
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.
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.