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

PBR to Verify Next Hop on MSFC

I have 12.2(17a)SX4 on MSFC and want to insert a static route to an ip next hop based on a L2 interfcae being up...Any ideas.

7 REPLIES
Community Member

Re: PBR to Verify Next Hop on MSFC

HSRP with PBR

Community Member

Re: PBR to Verify Next Hop on MSFC

I don't think that will help..

I want to use a static route pointing to a firewall as a next hop. But I only want the static route to work if the firewall is alive. So I think I have to 'track' the firewall state using either CDP or ICMP, like http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d1e95.html

but I am having trouble getting it going.

If I don't use this method then any ideas are welcome.

Re: PBR to Verify Next Hop on MSFC

we'll work with subnet 10.169.100.0 as users segment and the firewall being 10.10.0.1 ,

10.10.0.2, and 10.10.0.3 will be alternate routes if 10.10.0.1 is down etc..

1- crteate your access list

access-list 1 permit 10.169.100.2 ( per host )

access-list 1 permit 10.169.100.1 ( per host )

access-list 1 permit 10.169.100.10 ( per host )

or

access0list 1 permit 10.168.100.0 ( per subnet )

create a route map

example:

route-map alternate-routes permit 10

match ip address 1

set ip next-hop 10.10.0.1

set ip next-hop 10.10.0.2

set ip next-hop 10.10.0.3

set ip next-hop verify-availability ( verify next hop is a cdp neighbor )

the PBR will try the next available hop , your next hop is 10.10.0.1 firewall and if that hop is down

it will try 10.10.0.2 as an alternate route and so on.

Apply the route map to the interface

interface vlan 169

ip policy route-map alternate-routes

HTH, rate if this helps

Jorge

Community Member

Re: PBR to Verify Next Hop on MSFC

I understand your solution but I have a more complex problem.

The firewall is managed by another provider. I have asked if it will supply CDP or respond to ICMP, I have not heard but I will assume it will for now.

There are two loactions, a hot and a cold site. Each site has a firewall attached to my switch (MSFC). There are approx 10,000 people behind the swicths who want to talk through the host swicth/firewall if it is alive, or through the cold swicth/firewall if the hot one is dead.

Hence I want to inject the hot firewll into OSPF as a next hop only if it is alive.

I tried creating a static

ip route 10.10.0.1

Creating an ACL

access-list 10 per

Biulding the route map

route-map FIREWALL per 10

match ip add 10

set next hop 10.10.0.1

set next-hop ver-avail

But this seems to be mixing features, PBR on the vlan interfcae, and injecting into OSPF based on the same route-map.

I am starting to think that the best way to do it is make the interface between my swicth and the firewall a L3 interfcae, then I can use a static route pointing to the local swicth L3 interfcae. That way if the switch Ethernet is down, the static won't inject into ospf.

ip route Gig3/8

Re: PBR to Verify Next Hop on MSFC

I don't know, perhaps would'nt that be possibly by implemeting two default routes at your core-MSFC?

that is :

say both sites are up, hot and cold.

ip route 0.0.0.0 0.0.0.0 10.10.0.1 (hot site)

ip route 0.0.0.0 0.0.0.0 10.10.0.2 (cold site)

perhaps place and admin distance for route preference .

under ospf

redistribute static

Re: PBR to Verify Next Hop on MSFC

David,

Jorge's recommendation with an additional feature, Reliable static route using object tracking, should help you achieve what you are trying to do.

With this feature you can track the firewall IP address and when the it becomes unreachable the router would remove the primary default route and start using the backup default route (floating static) to route the traffic.

Have a look at this link to configure this feature.

http://cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html

HTH

Sundar

Community Member

Re: PBR to Verify Next Hop on MSFC

My 12.2(17a) IOS may limit me here.

I think I have to use the MSFC interfcae as the next hop, with the caveats that is must be a L3, and I wear the ARP problem as specified. I can poit to multiple /26's behind the firewall, which will limit the ARP issue.

I can redistribute static will differnt costs etc...no brainer.

http://www.cisco.com/en/US/partner/tech/tk365/technologies_tech_note09186a00800ef7b2.shtml

182
Views
0
Helpful
7
Replies
CreatePlease to create content