cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
810
Views
5
Helpful
12
Replies

change an extend access list in a prefix list

fabio.marino
Level 1
Level 1

Hallo All,

 

I would like to translate an extend access list in a prefix list.

 

ip access-list extended x_to_y

permit ip 1.1.1.1 0.0.1.255 any

deny ip any host 3.3.3.3

 

Any hint?

 

Thanks!!!

1 Accepted Solution

Accepted Solutions

Hi Fabio,

I am sorry but to my best knowledge, this is not going to work.

You want to perform Policy Based Routing (PBR). For PBR, the packet selection is based on inspecting their header values by an ACL. A prefix-list does not inspect header values; rather, it would inspect routing update contents. This is also the reason why you cannot figure out how to rewrite the second line - because a prefix-list does not have a source-and-destination semantics. It is simply a list of network addresses you would be looking for in routing protocol updates.

Even the documentation at

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html

clearly shows that the only supported match commands are match length and match ip address - not match ip address prefix-list.

I wonder - how come that your platform is unable to accomodate an ACL for PBR in hardware? Can we perhaps try to make this work? A prefix-list is not the way to go.

Best regards,
Peter

View solution in original post

12 Replies 12

Peter Paluch
Cisco Employee
Cisco Employee

Hi Fabio,

Nice to see you here again!

Please keep in mind that prefix lists can only be used for route filtering in routing protocols, and cannot be applied as packet filters onto interfaces to provide traffic filtering. Has this ACL been used for a routing protocol? If so, in which one and in what application? Was it a route-map, or a distribute-list? I am somewhat surprised to see this ACL using both source and destination portions in its entries. It is very uncommon for such ACL to be used for route filtering (though not absolutely impossible).

Looking forward to hearing from you.

Best regards,
Peter

Dear Peter,

Thank you for your kind reply.

Scenario is the following

-No routing protocol. Only static route

-Problem here is that I have to apply a route-map  to one interface

-The route map can be defined using only prefix-list. No use of access list is possible due to the hardware limitation.

Idea is the following

 

ip access-list extended x_to_y
permit ip 1.1.1.1 0.0.1.255 any
deny ip any host 3.3.3.3

route-map via_route permit 10
 match ip address x_to_y       --------> x_to_y can be only a prefix-list. NO ACL!!
 set ip next-hop 10.10.10.254


interface Vlan40
 description Local Network
 ip address 172.17.24.25 255.255.255.0
 ip policy route-map via_route

ip route 0.0.0.0 0.0.0.0 10.10.10.254

 

I am open to any solution of course.

 

Thank you!!!

 

 

I would say that the permit entry is not big issue,

permit ip 1.1.1.1 0.0.1.255 any

because I can use a prefix-list.

The problem is the

deny ip any host 3.3.3.3

In this case I need to block all the traffic that is using as destination ip the 3.3.3.3. With the prefix-list  I am not able to figure out how to manage it.

 

 

Hi Fabio,

I am sorry but to my best knowledge, this is not going to work.

You want to perform Policy Based Routing (PBR). For PBR, the packet selection is based on inspecting their header values by an ACL. A prefix-list does not inspect header values; rather, it would inspect routing update contents. This is also the reason why you cannot figure out how to rewrite the second line - because a prefix-list does not have a source-and-destination semantics. It is simply a list of network addresses you would be looking for in routing protocol updates.

Even the documentation at

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html

clearly shows that the only supported match commands are match length and match ip address - not match ip address prefix-list.

I wonder - how come that your platform is unable to accomodate an ACL for PBR in hardware? Can we perhaps try to make this work? A prefix-list is not the way to go.

Best regards,
Peter

Hi Peter,

 

The platform is an HP5412R.

 

Regards,

 

Fabio.

Fabio,

The platform is an HP (read: non-Cisco) switch? I am afraid I cannot help much with that one. Do you at least have a link to its documentation?

Best regards,
Peter

Hi Peter,

 

It is ok. I have some documentation, I will try to find a workaround.

Thank you for your effort.

 

Regards,

Fabio.

 

 

 

Fabio,

By asking for the link, I meant to ask you to provide it here. I'd like to have a look in my spare time.

Best regards,
Peter

Hi Peter,

 

Here the link 

ftp://ftp.hp.com/pub/networking/software/3500_5400_6200_AdvTrfGde-July2006-59913827.pdf

One question if you can answer.

What is the effect of the below configuration?

Honestly speaking is not clear.

For example if to the vlan 40 is arriving the packet

src 6.6.6.6, dst 3.3.3.3

This packet is denied -> Means that the next-hop for routing the packet will not be the  10.10.10.254. At this point this packet will be dropped or will be routed using the default gateway 10.10.10.254? (and for me it makes no sense if it is like this)

ip access-list extended x_to_y
permit ip 1.1.1.1 0.0.1.255 any
deny ip any host 3.3.3.3

route-map via_route permit 10
 match ip address x_to_y       
 set ip next-hop 10.10.10.254


interface Vlan40
 description Local Network
 ip address 172.17.24.25 255.255.255.0
 ip policy route-map via_route

ip route 0.0.0.0 0.0.0.0 10.10.10.254

 

Hi Fabio,

That configuration does not make sense to me, either. Either the packet will be PBR-routed through 10.10.10.254, or it will be routed according to the routing table where the default route again points toward 10.10.10.254. Unless there was a more specific route toward 3.3.3.3 than the default route in the routing table, the packet toward 3.3.3.3 would be routed through the same next-hop of 10.10.10.254.

Best regards,
Peter

Hi Peter,

 

Thank you very much for your time.

There is no specific route and no dynamic Routing protocol defined. The above config is what I received and now, after your Review, I agree with you that it makes no sense.

 

I will close the topic here.

 

I learned something new today and I really appreciate your Support. 

 

Have a nice evening.

 

Best Regards,

 

Fabio. 

Hi Fabio,

It was a pleasure. Thank you very much for your generous rating!

Best regards,
Peter
 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco