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

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

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

Do these filters do anything other than filter IPX packets? I don't want any branches to lose connection to anything.

Thanks,

John

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

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

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

Is this done on the core router, and how would my acl look?

Thanks!

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

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

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