Policy based routing - Can i have redundancy in PBR?

[habeebuddin786]

Hi,

I need help regarding the PBR implementation. We have a layer 3 access switch with VLANS 2, 5, and 9 configured on it with SVI's (1.1.2.0/23, 1.1.5.0/23, and 1.1.9.0/23 respectively) and EIGRP enabled on it. I am attaching the config file of access switch for reference. This layer 3 switch is connected to Two core layer 3 switches (4506E). They are connected through 1) port channel 1 (1/0/50 and 3/0/50) on access switch to core 1 port channel 17 (3/17 and 3/18). 2) port channel 2 (1/0/52 and 3/0/52) on access switch to core 2 port channel 17 (3/17 and 3/18). I would like to implement the PBR on access switch telling all the subnets should pass through port channel 1 and portchannel 2.  Below is the config I proposed, please let me know if this works fine if one of the port channels 1 of core 1 will get down. If not, I'll appreciate if any expert advice.

access-list 111 permit ip 1.1.2.0 0.0.1.255 any

access-list 222 permit ip 1.1.5.0 0.0.1.255 any

access-list 333 permit ip 1.1.9.0 0.0.1.255 any

!

route-map net-10 permit 10

match ip address 111

set interface Po1

!

route-map net-10 permit 20

match ip address 222

set interface Po1

!

route-map net-10 permit 30

match ip address 333

set interface Po1

!

route-map net-10 permit 40

!

int vlan 2

ip policy route-map net-10

!

int vlan 5

ip policy route-map net-10

!

int vlan 9

ip policy route-map net-10

!

But the problem here is if suppose Core 1, port channel-1 goes down then how this policy will route back to core-2 port channel 2. Will appreciate any help or expert advice on this .

Thanks

Ahmed

[Jon Marshall]

habeebuddin786 wrote:
Hi,
access-list 111 permit ip 1.1.2.0 0.0.1.255 any
access-list 222 permit ip 1.1.5.0 0.0.1.255 any
access-list 333 permit ip 1.1.9.0 0.0.1.255 any
!
route-map net-10 permit 10
match ip address 111
set interface Po1
!
route-map net-10 permit 20
match ip address 222
set interface Po1
!
route-map net-10 permit 30
match ip address 333
set interface Po1
!
route-map net-10 permit 40
!
int vlan 2
ip policy route-map net-10
!
int vlan 5
ip policy route-map net-10
!
int vlan 9
ip policy route-map net-10
!
But the problem here is if suppose Core 1, port channel-1 goes down then how this policy will route back to core-2 port channel 2. Will appreciate any help or expert advice on this .
Thanks
Ahmed

Ahmed

In your route-map statements you can do this -

set interface po1 po2

however why are you using PBR for this. PBR is useful when you want some traffic to go one way and some to go the other. But you want all traffic to go one way and then only use po2 if po1 fails. So why not simply manipulate the EIGRP metrics with an offset-list from the core2 switch so that the metrics seen for the remote subnets on the access switch are better for po1 and will continue to be used unless po1 fails.

Or configure an eigrp summary route on the link on core2 facing the access switch so that the access switch receives the more specific routes via po1 and the summary via po2. Specific routes will always be used over a summary route. This may well be the best solution for you.

PBR is not really the correct solution here.

Jon

[habeebuddin786]

Hi Jon,

Thanks for your response.

Yes you are correct, might be i can try manipulating the EIGRP metric on core side. Can you do one more favor to me. Can i have the steps to set the eigrp metric on the core switch or if you have any reference link that would be helpful for me to refer.

Ahmed

[Jon Marshall]

habeebuddin786 wrote:
Hi Jon,
Thanks for your response.
Yes you are correct, might be i can try manipulating the EIGRP metric on core side. Can you do one more favor to me. Can i have the steps to set the eigrp metric on the core switch or if you have any reference link that would be helpful for me to refer.
Ahmed 

Ahmed

Using an eigrp summary route would probably be easier to be honest. Can you summarise the networks that are not on the access switch ie. are they all 10.x.x.x or 172.16.x.x for example.

I can provide offset-list example and summary route but before that can i ask why you don't want to use both port-channels for the traffic as this would increase throughput ?

Jon

[habeebuddin786]

Hi Jon,

Sorry for the delay in response. Here I'll get you the whole picture. Below is the scenerio.

In our network there are two core switches (4506E), two interfaces (Po1) from core1 and two interfaces (Po2) from core 2 are connected to  First floor Access Layer switch (3750) where the data vlans, wireless vlans and voice vlans resides. From this access layer switch we have the connectivity to NMS (Network Management Switch) where the Management Vlans resides. We have the firewall connectivity between the Core and NMS switch.

Management Vlans are configured on the switch is vlan 5 and we are running EIGRP on both core as well as access layer switch. when we configured Vlan 5 subnet for IT admins on access switch the path is taking from NMS switch then firewall and drops instead of taking path from core switches. This path is taking due to the default eigrp configuration on both sides (core and access). We thought to configure PBR and divert the traffic from NMS to the core sides.

Below are basic configurations for two core and Access switch.

Hopes this helps to understand.

CORE1 configuration:

interface FastEthernet1
description Management port OOB 10.9.9.0/24
ip vrf forwarding mgmtVrf
ip address 10.9.9.40 255.255.255.0
ip access-group 9 in
no ip route-cache cef
no ip route-cache
no ip mroute-cache
speed auto
duplex auto

!

interface GigabitEthernet3/17
description To Access switch 2 GIG CHANNEL
no switchport
no ip address
channel-group 17 mode on
service-policy output AVAYA
!
interface GigabitEthernet3/18
description To Access switch 2 GIG CHANNEL
no switchport
no ip address
channel-group 17 mode on
service-policy output AVAYA

!

router eigrp 10
redistribute static metric 56 1 255 1 1500
no auto-summary
network 10.255.4.0 0.0.3.255

!

logging host 10.9.9.254 vrf mgmtVrf
access-list 9 permit 10.9.9.1
access-list 9 permit 10.9.9.100
access-list 9 permit 10.9.9.254
access-list 9 permit 10.9.9.243
access-list 9 deny   any log
!

ACCESS SWITCH CONFIGURATION:

Vlans data vlans are configured on this switch interfaces:

router eigrp 10
network 10.255.6.96 0.0.0.31
redistribute connected
eigrp stub connected summary
!
ip classless
ip http server
ip http secure-server
!
logging 10.9.9.254
access-list 9 remark Allow access to switch for management
access-list 9 permit 10.9.9.1
access-list 9 permit 10.9.9.100
access-list 9 permit 10.9.9.254
access-list 9 permit 10.9.9.243
access-list 9 deny   any log

!

Regards,

Ahmed

[habeebuddin786]

Need suggestion. I'll appreciate it if any suggestion comes from the expert.

Awaiting for the response

[Jon Marshall]

Ahmed

Apologies, i missed your reply.

It looks like i misunderstood your original request in that i thought you wanted to use just one of the port-channels whereas it looks like you need to force traffic to go via the core switch. Could you draw a very quick topology diagram of which switches are where as it's still not entirely clear.

Are you running EIGRP on the NMS switch ?

Jon

[habeebuddin786]

I think I was not clear in previous threads, sorry about that.

Here is the topology for one of the access switch, there are likely more switches I need to figure it out the solution. Much appreciated your assistance.

You can see from the diagram, 3750 access switch has data, voice and wireless vlans which are passing through Core switches. Also we have connectivity to NMS from FA0 (access switch) acting as routed port. As soon as the IT admin sitting at data vlan with suppose (10.xx.30.xx) IP address as source passing through destination of NMS IP address passed through directly connected FA0 towards the NMS and as TCP - SYN/ACK goes through NMS towards the firewall the packet is dropped. At this point only the IT admins are unable to acccess the network management servers. I thought to traverse the traffic from Core switches, as it passes through the firewall we have the PAT / hide NAT configured and it will passthrough the request from there. Therefore I tried the above PBR but its not working it will effect the data, voice and wireless networks, which is normally working fine without harm. I need some help because i need to figure it out the solution by this friday.

NMS is not having any routing protocols configured on it.

Might the above information and topology might help to understand better.

Kindly assist and let me know if you need more information.

[Jon Marshall]

Ahmed

Could you post .vsd as a .jpg as i don't currently have access to Visio ?

Thanks

Jon

[habeebuddin786]

No probelm. Please find the .JPEG version of the network topology.

[Jon Marshall]

Ahmed

Thanks, makes more sense now. PBR is actually what you want -

access-list 101 permit ip 10.xx.30.xx 0.0.0.254 10.xx.xx.xx 0.0.0.255

route-map PBR permit 10

match ip address 101

set interface po1 po2 <-- personally i would use next-hop ie. the IP addresses of the po6 port channels on the 4500 switches eg.

set ip next-hop

use either interface or next-hop not both

int vlan 300

ip policy route-map PBR

the above config will only use PBR for 10.xx.30.xx traffic to 10.xx.xx.xx/24 network which is your NMS network. All other traffic from 10.xx.30.xx to any other destination will use the routing table as normal.

Jon

[habeebuddin786]

Hey Jon,

Thank you so much for your assistance. That makes sense for diverting the traffic from that vlan but I got another problem. Under interface vlan 300, I am not seeing any IP policy command, below are the following commands for reference. Is it due to the IOS version, we are running IOS version on this switch as c3750e-universalk9-mz.122-52.SE.bin ?

access-switch(config-if)#ip ?
Interface IP configuration subcommands:
  access-group        Specify access control for packets
  accounting          Enable IP accounting on this interface
  address             Set the IP address of an interface
  admission           Apply Network Admission Control
  auth-proxy          Apply authenticaton proxy
  authentication      authentication subcommands
  bandwidth-percent   Set EIGRP bandwidth limit
  broadcast-address   Set the broadcast address of an interface
  cef                 Cisco Express Forwarding interface commands
  cgmp                Enable/disable CGMP
  dampening-change    Percent interface metric must change to cause update
  dampening-interval  Time in seconds to check interface metrics
  dhcp                Configure DHCP parameters for this interface
  directed-broadcast  Enable forwarding of directed broadcasts
  header-compression  IPHC options
  hello-interval      Configures EIGRP-IPv4 hello interval
  helper-address      Specify a destination address for UDP broadcasts
  hold-time           Configures EIGRP-IPv4 hold time
  igmp                IGMP interface commands
  information-reply   Enable sending ICMP Information Reply messages
  irdp                ICMP Router Discovery Protocol
  load-sharing        Style of load sharing
  local-proxy-arp     Enable local-proxy ARP
  mask-reply          Enable sending ICMP Mask Reply messages
  mroute-cache        Enable switching cache for incoming multicast packets
  mtu                 Set IP Maximum Transmission Unit
  multicast           IP multicast interface commands
  next-hop-self       Configures EIGRP-IPv4 next-hop-self
  pim                 PIM interface commands
  probe               Enable HP Probe support
  proxy-arp           Enable proxy ARP
  rarp-server         Enable RARP server for static arp entries
  redirects           Enable sending ICMP Redirect messages
  rgmp                Enable/disable RGMP
  rip                 Router Information Protocol
  route-cache         Enable fast-switching cache for outgoing packets
  rtp                 RTP parameters
  sap                 Session Advertisement Protocol interface commands
  security            DDN IP Security Option
  split-horizon       Perform split horizon
  sticky-arp          Allow the creation of sticky ARP entries
  summary-address     Perform address summarization
  tcp                 TCP interface commands
  unnumbered          Enable IP processing without an explicit address
  unreachables        Enable sending ICMP Unreachable messages
  urd                 Configure URL Rendezvousing
  verify              Enable per packet validation

regards,

ahmed

[Jon Marshall]

Ahmed

Forgot to mention. To run PBR on the 3750 you need Advanced IP Services and you must enable the sdm routing template ie.

3750# sh sdm prefer

if the template in use is not the routing template you need to change it to the routing template and then reboot the switch. Then you should have the "ip policy ..." command available under the interface.

Jon

[habeebuddin786]

Thanks Jon for your quick replies.

I still didn't get the ip policy command under interface vlan 300 despite of enabling sdm routing template. I also rebooted the switch after enabling the sdm routing template but no go. Below are the sdm statistics for your reference:

show sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
    number of directly-connected IPv4 hosts:        3K
    number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         512
  number of IPv4/MAC qos aces:                      512
  number of IPv4/MAC security aces:                 1K

(config)#int vlan 324
(config-if)#ip pol
(config-if)#ip polic
(config-if)#ip policy ?
% Unrecognized command

Regards,

Ahmed

[Jon Marshall]

Ahmed

Then i suspect this is because you have IP BASE and not IP Services. You cannot run PBR on IP BASE i'm afraid.

Can you post the output of "sh version".

Jon