We in DC we have a primary MPLS circuit and a less expensive point to point VPLS type circuit. We identify all of our replication traffic via acls and route accross the point to point. Most ACLs are pretty granular which have source host, destination host and port numbers. Only one ACL identifies all traffic between 2 hosts. Since it is all traffic they make good test subjects.
With the 2 hosts that send all their traffic between each other using PBR i have tried blocking that path and but hosts do not fall back to primary MPLS. How do i get this to work?
router ospf 1
redistribute static subnets route-map STATIC-TO-OSPF-MAP ======= this is to propagate some of our static routes to rest of network.
network 10.2.0.0 0.0.255.255 area x =====ospf being used to advertise networks over MPLS
network 172.16.29.0 0.0.0.255 area x
network 172.16.40.0 0.0.0.255 area x
ACL to identify traffic for PBR
ip access-list extended alt_route_archive
permit ip host 10.2.x.x host 10.3.x.x
route-map alt_route_dc permit 10
match ip address alt_route_evault alt_route_nimble alt_route_sql alt_route_hyperv alt_route_archive
set ip next-hop 172.16.x.x
I when the above routing does not work i want this to fall back to the MPLS.
I am guessing this is possible because it seems pretty simple but am having hard to finding good documentation.
It will be more helpful if you post your topology. Have you tried route-map with different number? Where you apply your PBR?
route-map alt_route_dc permit 20
match ip address alt_route_archive
set ip next-hop 172.16.x.x
How are you blocking the path in your testing ?
If you shut one end of the link does the other end go down as well ?
If so then if the next hop is not available the normal routing table should be used.
You can use CDP with PBR or IP SLA if when one end goes down the other end stays up but can you confirm how you are testing ?
I agree with Jon that it would help to know how you are testing. But my guess is that you test does not cause the outbound interface to go into the state of line protocol down. And with your current configuration interface line protocol down is the only way to get PBR to not set the next hop.
And alternative that you might consider is to use the optional parameter verify-availability in your config of the set ip next-hop command. That can use track or IP SLA (depending on your platform and version of code) to be sure that the next hop is reachable and will cause PBR to not forward traffic if the next hop is not available.
I am sorry that I did not see the responses on this. For some reason I did not get any notifications.
To answer your question I am shutting down interface on the same switch that my hosts for testing. Cut not be a clearer way for the switch to know this link is down. I do have to say that probably would not emulate a real failure. Most likely the link would be up but connection stops passing traffic.
There are a number of things which we do not know about your environment and this keeps us from being able to offer much good advice. Please help us to understand these things:
- would you verify that in normal operation that this PBR does work as expected and that the traffic you are interested in really does use the next hop of 172.16.x.x?
- can you explain why you think it is helpful to hide the last two octets of an address in 172.16? It makes it more difficult for us to understand what is going on and does not protect anything that is unique or sensitive about your network.
- in normal operation if you do show ip route, where would you find 172.16.x.x? Is there a host specific route for it? or a subnet route for it? or a network route for it?
- when you shut down the port and then do show ip route does the entry that you saw previously for 172.16.x.x go away?
- does the path to 172.16.x.x go out a routed port, or out through a vlan? If it goes out through a vlan, then when you shut down the port does the vlan go down?