Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Switch, IPX and filtering

Hi all,

I have couple C2960G and C3750. And I have very simple question.

Is there any way to filter (on ingress port) type of traffic? I would like to allow IP only, and discard (i.e.) IPX, or other garbage, that any device can produce.

I have tried to find something about this, but only thing I have found is feature : protocol filter, which doesn't seems to be working on my hardware.

Any suggestion?

Thanks and regards

Pavel

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Switch, IPX and filtering

Hello Pavel,

I believe that VLAN ACLs can be nicely used for this.

Consider the following configuration:

mac access-list extended IPX

  permit any any 0x8137 0x0

  permit any any lsap 0xffff 0x0

  permit any any lsap 0xe0e0 0x0

vlan access-map NoIPX 10

  match mac address IPX

  action drop

vlan access-map NoIPX 20

  action forward

vlan filter NoIPX vlan-list 100,200,300,400

First we create a MAC ACL that should match the EtherType or DSAP/SSAP of IPX packets inside Ethernet frames. Then we define a VLAN access-map that causes IPX packets to be dropped and all other traffic should be forwarded. Then this VLAN access-map is applied to VLANs 100,200,300 and 400.

Can you give this a try and let us know if it worked for you?

Best regards,

Peter

6 REPLIES
VIP Super Bronze

Switch, IPX and filtering

Hi Pavel,

IPX and Apple Talk are not supported on the 3750 series:

Q. Is there a road map for support of IPX and AppleTalk routing?

A. No, there are currently no plans to support either IPX or AppleTalk  routing. Fallback bridging can be configured to allow bridging of non-IP  traffic between VLANs.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/prod_qas09186a00801b0971.html

HTH

New Member

Switch, IPX and filtering

Hi Reza,

Thank you for reply.

But I'm not interested in IPX routing. As I mentioned, I want to discard anything non-IP (i.e. IPX) on input (access port) to my network.

So, it's not about IPX routing, but about IPX on L2.

Thanks for suggestion.

Cisco Employee

Re: Switch, IPX and filtering

Hello Pavel,

I believe that VLAN ACLs can be nicely used for this.

Consider the following configuration:

mac access-list extended IPX

  permit any any 0x8137 0x0

  permit any any lsap 0xffff 0x0

  permit any any lsap 0xe0e0 0x0

vlan access-map NoIPX 10

  match mac address IPX

  action drop

vlan access-map NoIPX 20

  action forward

vlan filter NoIPX vlan-list 100,200,300,400

First we create a MAC ACL that should match the EtherType or DSAP/SSAP of IPX packets inside Ethernet frames. Then we define a VLAN access-map that causes IPX packets to be dropped and all other traffic should be forwarded. Then this VLAN access-map is applied to VLANs 100,200,300 and 400.

Can you give this a try and let us know if it worked for you?

Best regards,

Peter

New Member

Re: Switch, IPX and filtering

Hello Peter,

I have tried, and with short packet capturing on fw, I can see only IPX RIP remaining (maybe more, not enough time to explore now).

In wireshark, I can see Packet type : RIP (0x01) - shall I add it to this (if I want detect and delete)?

mac access-list extended IPX

permit any any 0x01 0x0

Your solution seems to be working, but maybe I would prefer the oposite way.

To make nad ACL, which detects IP packets inside frame - then allow them, and everything else to drop. Can you show me how would you (if it is easy).

From this:

http://en.wikipedia.org/wiki/EtherType

I would put to ACL statement:

permit any any 0x800 0x0, which I would forward (in 10) and (in 20) I would put action drop. Do you think, it will work?

But, maybe I will have to put there more Ethertypes (ARP, RARP, 0x8100 - for upstream traffic, maybe 0x8808).

What's your opinion? Anyway, thanks for directing me right way.

Pavel

Cisco Employee

Re: Switch, IPX and filtering

Hello Pavel,

In wireshark, I can see Packet type : RIP (0x01) - shall I add it to this

Can you please save the Wireshark capture as a file and post it here? It has been a loooooong time since I saw live IPX packets and I would need to see the details.

To make nad ACL, which detects IP packets inside frame - then allow  them, and everything else to drop. Can you show me how would you (if it  is easy).

Unfortunately, that won't be that easy. On recent Catalyst platforms, MAC ACLs apply only to non-IP traffic while IP ACLs apply (obviously) to IP traffic only. It is not logical - but it's just the way it is implemented in hardware. In particular, it is not possible to define a MAC ACL matching for EtherTypes 0x0800 (IPv4), 0x0806 (ARP), 0x86DD (IPv6) etc., so your idea can not be readily implemented.

You could perhaps think of using IP ACL to permit all IP traffic and a separate MAC ACL to selectively permit selected types of non-IP traffic. However, I also suggest avoiding this approach. Remember that there is a lot of non-IP traffic that might be very important - ARP, STP, CDP/LLDP, VTP, PAgP/LACP, LOOP... keeping track of all these kinds of protocols and probably missing some is ultimately going to cause troubles.

So really, the approach of filtering out specific unwanted non-IP traffic while allowing all other non-IP traffic pass is the safest way to do things here.

Best regards,

Peter

New Member

Re: Switch, IPX and filtering

Hello Peter,

Thank you, for correcting my euphoria ;-).

You're absolutely right, about rest of non-IP traffic. So I will switch my approach to first version. Eliminate what I see now (IPX mess), and when comes something wrong, I will extend matchning ACL.

However I wasn't lucky about recaptuing IPX RIP, so it looks like it was an accindent.

Solution you provided (mac ACL) works fine, and I can seen no IPX on L3 anymore.

Thank you very much

Pavel

1191
Views
5
Helpful
6
Replies