A ‘permit’ ACL rule hit in a ‘permit’ PBR route-map causes the ‘set
next-hop’ action to occur.

In the case that no explicit rule is hit, the implicit deny rule that
terminates all ACLs will be hit.

A ‘deny’ ACL rule hit in a ‘permit’ PBR route-map causes the next route-map
in sequence to be tested.



Other options:

A ‘permit’ ACL rule hit in a ‘deny’ PBR route-map causes the next route-map
in sequence to be tested.

A ‘deny’ ACL rule hit in a ‘deny’ PBR route-map causes the next route-map
in sequence to be tested.



*From:* Odilo Schwade Junior [mailto:[email protected]]
*Sent:* Tuesday, June 12, 2012 4:16 PM
*To:* Enterasys Customer Mailing List
*Subject:* [enterasys] PBR precedence N7



Hi all,



We are testing some PBR on our Matrix N7 Platinum with FW: 07.41.03.0009
and we are a little bit confuse about precedence and stuff..



Here is some example:



*Access-List:*

!

ip access-list extended 101

  permit ip 10.0.0.0 0.255.255.255 X.X.X.X 0.0.15.255 { OUR ROUTED IPs }

  exit

ip access-list extended 102

  permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

  exit

ip access-list extended 103

  permit ip 10.0.0.0 0.255.255.255 any

  exit

ip access-list extended 104

  permit ip any 10.100.252.0 0.0.1.255   { VPN }

  exit





*Our Route Map for testing *:

route-map policy 113 permit 96

  match ip address 103

  set next-hop { OUR NAT IP}

route-map policy 113 permit 97

  match ip address 102

route-map policy 113 permit 98

  match ip address 101

route-map policy 113 permit 99

  match ip address 104

  set next-hop {OUR VPN IP}

Policy matches: 1836 packets





*Our Old Route Map*:

route-map policy 110 permit 5

  match ip address 104

  set next-hop { OUR VPN IP }

route-map policy 110 permit 10

  match ip address 101

route-map policy 110 permit 20

  match ip address 102

…

… {LOTS OF same stuff..}

…

route-map policy 110 permit 99

  match ip address 103

  set next-hop { OUR NAT IP }

Policy matches: 1736276030 packets





We tested invert the precedence to see the behavior of precedence matches.



Our real problem is ANY internal IP is accessing ANYthing through our NAT,
for instance, ours VOIP Phones (10.x.x.x) when calling another VOIP Phone
(10.x.x.x) we are able, using TCPDUMP on our NAT (Linux machine), to see
that connection between them are passing through NAT.. that’s so wrong
right?!

Anyways, all of our network now is passing through our NAT.. this may be
the cause of some slow connections, VOIP problems, etc., this is old
configuration (something like 7 years, imported to router to router) that
we discovered just now.



Any ideas our miss match configuration that we were not able to see that
you can help us??!

Any other information needed please just tell me..



--

*Odilo Schwade Junior*

GTI - Gerência de Tecnologia da Informação

Universidade do Vale do Itajaí – UNIVALI

( +55 (47) 3341 – 7777

* [email protected]

* [email protected]

P *ANTES DE IMPRIMIR*, tenha em mente seu compromisso com o *MEIO AMBIENTE*!
**



   - --To unsubscribe from enterasys, send email to [email protected] with
   the body: unsubscribe enterasys [email protected]

---
To unsubscribe from enterasys, send email to [email protected] with the body: 
unsubscribe enterasys [email protected]

Reply via email to