cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2149
Views
20
Helpful
11
Replies

Help to understand this wildcard mask 0.0.255.31

giuse63
Level 1
Level 1

Hi all,

I'm migrating configuration from an old Cisco switch to a new SG350X

In the old configuration I've some ACL to control the access via telnet/ssh

One of them:

 

access-list 25 permit 172.20.0.0 0.0.255.31

 

the sintax for the new switch require:

 

access-list 25 permit 172.20.0.0/X 

 

I cannot find how to translate the wildcard   0.0.255.31 in CIDR format.

in standard format will be 255.255.0.224
how I should convert it ?

/27 woud cover 255.255.255.224
but not idea about 255.255.0.224

Many Thanks
Joshep

 

2 Accepted Solutions

Accepted Solutions

Hello @giuse63 ,

actually in IOS ACLs can use wildcard masks with these strange patterns that cannot be converted to a prefix in the original ACL it means

 

allow each source address like 172.20.X.1-30  with X= 0 to 255

 

see last octet in binary 0000 0000    the boundary line is 000 || xxxxx   first three digits must be 0 like in the 4th byte of the base address

access-list 25 permit 172.20.0.0 0.0.255.31

 

This would translate in 256   prefixes /27 the following ones ( but I am afraid the GUI of new switch  will not allow you to add so many lines )

 

172.20.0.0/27

172.20.1.0/27

172.20.1.0/27

.......

[ omitted ]

 

172.20.254,0/27

172.20.255.0/27

 

Ask the customer what are the really important of these /27 prefixes  and implement only the selected important ones.

 

Hope to help

Giuseppe

 

 

View solution in original post

Joshep

access-list 25 permit 172.20.0.0 0.0.255.31 uses a pretty odd mask. But it is legitimate. In subnet masks there is a requirement that all zeros be contiguous and all ones be contiguous. But that does not apply to masks used in access lists. So what does this mask mean?

- The first 2 octets must be 172.20

- The third octet can be anything

- The fourth octet must be between 0 and 31

We are told that this access list was used to control access via telnet/ssh. So it was used with access-class. This would make sense if this organization used class B private address 172.20, and if this organization specified that subnets would be /24, and if this organization specified that the first group of 32 addresses in each subnet would be reserved (perhaps in a DHCP scope) for users who should have remote access privileges.

So this syntax works for an access list in an IOS device using CLI. Unfortunately it does not work on the SG switches.

I am puzzled that it appears that there are at least 2 statements in access list 25

access-list 25 permit 172.20.0.0 0.0.255.31

access-list 25 permit 172.20.0.0 0.0.0.255

They are mutually contradictory. The first statement says that it applies to 256 subnets and the first 32 addresses are permitted. The second statement says that it applies to one subnet and that all 256 addresses are permitted. So the order of statements is significant. Which ever one is first controls the behavior and the second one will be ignored.

HTH

Rick

View solution in original post

11 Replies 11

Hello,

 

there is no way to create such a wildcard mask. What IP address range do you want to cover, what start and end host IP addresses ?

giuse63
Level 1
Level 1

Hello,

many thanks to answered my question, since I needed just a confirmation that I cannot get a CIDR format for this subnetmask.

 

In the acl, there is also  access-list 25 permit 172.20.0.0 0.0.0.255   that i've translated  /24

I will ask the customer if they can say something about.

 

Anyhow seems that on Sg350X  I cannot apply an acl to control from what subnet is performed SSH or Telnet access. So the acl above is unusefull.

Many thanks

Regards

Joshep

Hello @giuse63 ,

actually in IOS ACLs can use wildcard masks with these strange patterns that cannot be converted to a prefix in the original ACL it means

 

allow each source address like 172.20.X.1-30  with X= 0 to 255

 

see last octet in binary 0000 0000    the boundary line is 000 || xxxxx   first three digits must be 0 like in the 4th byte of the base address

access-list 25 permit 172.20.0.0 0.0.255.31

 

This would translate in 256   prefixes /27 the following ones ( but I am afraid the GUI of new switch  will not allow you to add so many lines )

 

172.20.0.0/27

172.20.1.0/27

172.20.1.0/27

.......

[ omitted ]

 

172.20.254,0/27

172.20.255.0/27

 

Ask the customer what are the really important of these /27 prefixes  and implement only the selected important ones.

 

Hope to help

Giuseppe

 

 

Hi Giuseppe,

Many thanks for your explanation.

Regards

Josepp

balaji.bandi
Hall of Fame
Hall of Fame

Looks for me Typo error, may be some OLD Code may accept that mask,

 

SG350X  was the new device may be GUI issue :

 

 

https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-350-series-managed-switches/smb3025-configure-ipv4-based-access-control-list-acl-and-access-cont.html

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Joshep

access-list 25 permit 172.20.0.0 0.0.255.31 uses a pretty odd mask. But it is legitimate. In subnet masks there is a requirement that all zeros be contiguous and all ones be contiguous. But that does not apply to masks used in access lists. So what does this mask mean?

- The first 2 octets must be 172.20

- The third octet can be anything

- The fourth octet must be between 0 and 31

We are told that this access list was used to control access via telnet/ssh. So it was used with access-class. This would make sense if this organization used class B private address 172.20, and if this organization specified that subnets would be /24, and if this organization specified that the first group of 32 addresses in each subnet would be reserved (perhaps in a DHCP scope) for users who should have remote access privileges.

So this syntax works for an access list in an IOS device using CLI. Unfortunately it does not work on the SG switches.

I am puzzled that it appears that there are at least 2 statements in access list 25

access-list 25 permit 172.20.0.0 0.0.255.31

access-list 25 permit 172.20.0.0 0.0.0.255

They are mutually contradictory. The first statement says that it applies to 256 subnets and the first 32 addresses are permitted. The second statement says that it applies to one subnet and that all 256 addresses are permitted. So the order of statements is significant. Which ever one is first controls the behavior and the second one will be ignored.

HTH

Rick

Hi Rick,

many thanks for your explanation.

I think the customer or who made the configuration, made some mistake with this network. SInce on the acl 25 there are a lot of redundant entry. for exampe 172.20.00 0.0.255.255 that allow the /16 subnets.

Regards

Joshep

Joshep

I agree that it sounds like the customer did make mistakes. And this is an easy mistake to make. Many people who do not have a good understanding of how IOS works think that if there is a problem with an entry in an access list that they can just type a new entry and it would replace the problematic entry. But IOS does not work that way and it just adds the new entry at the bottom of the acl. So if mistakes in the acl make it difficult to know what was the expected result perhaps you can ask them to tell you how they wanted it to work, and perhaps you can find a way to accomplish it on the SG switch.

I am glad that our explanations have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

Hello BB,

many thank to provide that link, usually I use CL, but in this case perhaps is more simple use the web gui.

Regards

Joseph

Hello

Wild card acls can be used in few things but mainly filtering i would say it the most applicable use for them.

 

Example

10.0.0.0/8

0.254.255.255
would expect to match all even hosts from above range -  allow 10.0.x.x.x, 10.2,1.0,10.4.3.0 etc.

 

10.0.1.0/8

deny 0.0.254.0

permit any

would expect to match all odd hosts from above range -  deny 10.0.1.0 10.0,3.0,10.1.5.0 etc.

10.0.1.0/8
deny 0.0.255.31
permit any
would expect to match all odd hosts/27 addressing from above range -  deny 10.0.1. 10.0,3.32,10.1.5.64 etc.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul,

many thanks for your help

 

Review Cisco Networking for a $25 gift card