Re: Policy based routing - Can i have redundancy in PBR? - Page 2

habeebuddin786 · ‎07-22-2010

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

habeebuddin786 · ‎07-28-2010

Below is the sh version output.

So what would be the solution for this, is there any alternative like implementing ip vrf instead of PBR. because we are using IP base IOS not IP services.

Also my IT infrastructure lead not recommended to have a solution of upgrading IOS versions at this point of time. Because these changes have to done on almost 40 switches, let me check for other switches what kind of service they are running. so what do you suggest?

sh ver
Cisco IOS Software, C3750 Software (C3750-IPBASE-M), Version 12.2(25)SEE3, RELEA
SE SOFTWARE (fc2)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 22-Feb-07 15:04 by myl
Image text-base: 0x00003000, data-base: 0x00EE40E0

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(25r)SEE4, RELEASE SOFTWA
RE
System returned to ROM by power-on
System image file is "flash:c3750-ipbase-mz.122-25.SEE3/c3750-ipbase-mz.122-25.S
EE3.bin"

cisco WS-C3750G-48TS (PowerPC405) processor (revision F0) with 118784K/12280K by
tes of memory.
Processor board ID FOC1121Y3X0
Last reset from power-on
4 Virtual Ethernet interfaces
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address       : 00:1C:0F:E2:5C:80
Motherboard assembly number     : 73-10218-08
Power supply part number        : 341-0107-01
Power supply part number        : 341-0107-01
Power supply serial number      : AZS1119013T
Model revision number           : F0
Motherboard revision number     : C0
Model number                    : WS-C3750G-48TS-S
System serial number            : FOC1121Y3X0
Top Assembly Part Number        : 800-26857-02
Top Assembly Revision Number    : A0
Version ID                      : V04
CLEI Code Number                : COM7X10ARA
Hardware Board Revision Number : 0x09

Switch   Ports Model              SW Version              SW Image
------   ----- -----              ----------              ----------
*    1   52     WS-C3750G-48TS     12.2(25)SEE3            C3750-IPBASE-M

regards

Ahmed

Jon Marshall · ‎07-28-2010

Ahmed

As you can see you have IP BASE not IP Services so no PBR.

Can i clarify that the problem is that NMS servers have the firewall as their default-gateway, hence the syn/ack is sent back to the firewall even though the syn came directly from the fa0 interface ?

If this is the case how do the non-IT users in vlan 300 access the NMS servers such as DHCP etc. I'm assuming that they use DHCP so how does that work ?

Jon

habeebuddin786 · ‎07-28-2010

Thats a good question. I think the firewall is configured as the default gateway on the NMS servers. But let me double check and get back to you by tommorow regarding this.

The non-IT users are gettting DHCP throug hthe DHCP relay agent as IP helper address is configured as 198.168.xx.xx under interface Vlan configuration.

Hope this helps to understand. Please let me know if need more clarification. I need to provide the solution by this friday.

I really appreciate your quick response towards the resolution. Please keep sending me the response.

Thanks

Ahmed

Jon Marshall · ‎07-28-2010

Ahmed

What you need to find out is if any of the NMS servers are accessed via the fa0 interface by any users other than your IT users. If it is only your IT users that access these servers via fa0 and everybody else goes via the core there is a relatively easy solution but you need to be sure.

If you can get back to me with details of -

1) default-gateway on NMS servers ie. is it firewall hence the syn/ack issue

2) how non IT users within vlan 300 access the NMS servers ie. even with ip helper-address if the DHCP server is actually using a 10.xx.xx.xx address then the DHCP request would go via fa0 interface and not the core so i would have thought you would have same syn/ack issues. Perhaps the DHCP server has 2 NICs, one for DHCP requests that is routed via core and one for IT users in the 10.xx.xx.xx network.

We need to be sure about this otherwise we could break things for the users instead of fixing things for IT users.

Jon

Jon Marshall · ‎07-28-2010

Actually on rereading this the ip helper is pointing to 198.96.x.x address so does it have a second NIC in the 10.xx.xx.xx network ?

Jon

habeebuddin786 · ‎07-28-2010

There is no other NIC configured on the DHCP server except 198.168.xx.xx/24.

The non-IT users traffic are traversing through core switches not through the Fa0. Only IT admins are accessing Network Management servers like Ciscoworks, SNMP server etc.,

regards,

Ahmed

Jon Marshall · ‎07-28-2010

habeebuddin786 wrote:

There is no other NIC configured on the DHCP server except 198.168.xx.xx/24.

The non-IT users traffic are traversing through core switches not through the Fa0. Only IT admins are accessing Network Management servers like Ciscoworks, SNMP server etc.,

regards,

Ahmed

If this is the case and the issue is the default-gateway on the NMS servers then there is a relatively easy solution. The issue you have is that the 3750 that routes vlan 300 also has an interface fa0 in the NMS subnet.

Because the NMS switch is also a 3750 then you can have a different subnet between the vlan 300 3750 and the NMS 3750. So for example -

vlan 300 3750

int fa0

no switchport

ip address 192.168.5.1 255.255.255.252

NMS 3750

int gi0/1

no switchport

ip address 192.168.5.2 255.255.255.252

now the 10.xx.xx.xx network used for NMS servers is no longer directly connected to the vlan 300 3750 switch. So you can now add a route for the 10.xx.xx.xx network via the core.

This will only work if you are absolutely sure that only IT users need to get to 10.xx.xx.xx network. Also still worth checking what the actual syn/ack issue as there may be a simpler solution.

Jon

habeebuddin786 · ‎07-28-2010

Sorry to say Jon. I didn't got you.

Below I am attaching the config samples of access and NMS switch. Can you let me know the changes based on the config files.

I apologies for that.

Regards,

Ahmed

Jon Marshall · ‎07-29-2010

habeebuddin786 wrote:
Sorry to say Jon. I didn't got you.
Below I am attaching the config samples of access and NMS switch. Can you let me know the changes based on the config files.
I apologies for that.
Regards,
Ahmed

Ahmed

No need to apologize.

If you do a "sh ip route" on the access switch you will see 10.19.19.x as a directly connected route because of the fa0 interface. So any traffic going to the 10.19.19.x network will be sent out on the fa0 interface.

But you want that traffic to go via the core switches instead. In order to do this you need to make sure that the access switch does not have a directly connected interface in the 10.19.19.x network or else it will never go via the core. So my suggested solution was to readdress the directly connected interface and create a new routed subnet between the access switch and the NMS switch using the config supplied previously.

If you do that now when you do a "sh ip route" on the access switch you won't have a directly connected interface in the 10.19.19.x network. So now you can add a route(s) to the access switch ie.

ip route 10.19.19.0 255.255.255.0 <4500 core 1 po6 IP address>

ip route 10.19.19.0 255.255.255.0 <4500 core 2 po6 IP address>

and traffic for 10.19.19.x will go via the core. You couldn't do this while fa0 was in the 10.19.19.x subnet because it would always have used that connection.

So the link between the access switch and the NMS switch is now a routed link at both ends using a subnet that is not used anywhere else in your network. You would need to turn on ip routing on the NMS switch for this to work.

Like i say though you need to be absolutely sure that this can only affect the IT users and not normal users which it shouldn't as long as normal users always go via the core anyway.

Jon

Jon Marshall · ‎07-29-2010

Ahmed

There is one other solution if you are unhappy with making the link between the access switch and the NMS a routed link etc.

Take all your IT users and put them in a separate vlan that is routed off the 3750 access switch.

Then on each NMS server add a route to the new IT subnet pointing back to the fa0 10.19.19.x address on the access switch.

This would mean your IT users did not go through the firewall to get to the NMS network which may or may not be what you want. I'm not a big fan of adding routes to servers but it is a possible option.

Jon

habeebuddin786 · ‎07-29-2010

Hey Jon,

Thanks for your response and suggestions.

I already suggested the above two solutions to my IT infrastructure lead on this, he is not recommending this solution at this point. Even I figured it out with ip vrf but due to the IOS version vrf managment is not supported as shown below. Currently we have removed directly connected interface fa0 towards the NMS. Traffic is passing through core towards the NMS through firewall successfully. But this is the temporary solution. They want to fix this issue permanently by keeping the FA0 or anyother interface as routed link connected to NMS switch for Mangement purpose and want to keep same subnet as it has on management switch 10.19.19.0/24.

logging x.x.x.x vrf mgmt
snmp-server host x.x.x.x vrf mgmt community
aaa group server tacacs+ MGMT
vrf mgmt
ntp server vrf mgmt x.x.x.x

We tried solutions so far:

1) with PBR - not supported due to IPBASE IOS

2) with seperate VLAN for IT admin - IT lead is not recommended

3) ip vrf - management vrf is not supported with the current IOS.

Right now I have two things in my mind either I have to check with offset list or IOS image need to be upgraded on all switches.

What IOS version image would you recommend to support PBR, EIGRP, IP services, QoS, SSH support, ip vrf management on 3750 E cat switches.

Thanks & regards,

Ahmed

Jon Marshall · ‎07-29-2010

Ahmed

Right now I have two things in my mind either I have to check with offset list or IOS image need to be upgraded on all switches.

What IOS version image would you recommend to support PBR, EIGRP, IP services, QoS, SSH support, ip vrf management on 3750 E cat switches.

offset list won't help as it is a directly connected interface so it will always choose that path.

Did your IT guy give any reasons why he didn't want to use either solution ?

For IOS you can go for the same version but just go to IP Services rather than IP Base and make sure you still have crypto ie. k9 in the IOS image name.

Jon

habeebuddin786 · ‎07-29-2010

Well. I checked with him, he said its not recommended to have another subnet for IT admins, it seems routes need to be pointing towards the new submnet in the NMS servers. He don't want to do that.

I will look for the IOS upgrade of IP services with K9 support.

Thanks a lot for your help.

Will update you with the test result once I have upraded to IOS with IPservices in the lab.

regards,

Ahmed

habeebuddin786 · ‎07-29-2010

Jon,

One more quick question for you. Suppose even if I implement PBR by upgrading IOS 12.2(53). Ipservices.

1) will the connected route from fa0 is ignored and divert the traffic destined to 10.19.19.0 /24 from core? or still is still take connected route as preference.

2) how do we test the latest IOS version before upgrading - I mean the services are running fine as usual without effect the normal traffic. How to identify whteher the latest IOS version is having bug?

Just for the sake of knowledge which IOS version will support the vrf management like logging and snmp as shown below:

logging x.x.x.x vrf mgmt
snmp-server host x.x.x.x vrf mgmt community
aaa group server tacacs+ MGMT
vrf mgmt
ntp server vrf mgmt x.x.x.x

The above configuration is not supported on current IOS 12.2 version.

regards,

Ahmed

habeebuddin786 · ‎07-29-2010

Hey Jon,

I still see no change in routes towards the NMS after PBR. Below are the Eigrp topology behaviour before and after the PBR.

1) Before PBR implementation:
sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(10)/ID(10.255.6.114)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.255.6.112/28, 1 successors, FD is 1536
        via Connected, Port-channel2
P 10.4.24.0/23, 1 successors, FD is 2816
        via Rconnected (2816/0)
P 10.19.19.0/24, 1 successors, FD is 2816
        via Rconnected (2816/0)
P 0.0.0.0/0, 1 successors, FD is 44912640
        via 10.255.6.113 (44912640/44912384), Port-channel2
P 192.168.50.0/24, 1 successors, FD is 45714688
        via 10.255.6.97 (45714688/45714432), Port-channel1
P 192.168.60.0/24, 1 successors, FD is 44912640
        via 10.255.6.113 (44912640/44912384), Port-channel2
P 10.255.6.96/28, 1 successors, FD is 1536
        via Connected, Port-channel1

sh ip eigrp topology 10.19.19.0 255.255.255.0
EIGRP-IPv4 Topology Entry for AS(10)/ID(10.255.6.114) for 10.19.19.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2816
Descriptor Blocks:
0.0.0.0, from Rconnected, Send flag is 0x0
      Composite metric is (2816/0), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 10 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.255.6.114
      External data:
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)

2) After applying PBR:

sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(10)/ID(10.255.6.114)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.255.6.112/28, 1 successors, FD is 1536
        via Connected, Port-channel2
P 10.4.24.0/23, 1 successors, FD is 2816
        via Rconnected (2816/0)
P 10.19.19.0/24, 1 successors, FD is 2816
        via Rconnected (2816/0)
P 0.0.0.0/0, 1 successors, FD is 44912640
        via 10.255.6.113 (44912640/44912384), Port-channel2
P 192.168.50.0/24, 1 successors, FD is 45714688
        via 10.255.6.97 (45714688/45714432), Port-channel1
P 192.168.60.0/24, 1 successors, FD is 44912640
        via 10.255.6.113 (44912640/44912384), Port-channel2
P 10.255.6.96/28, 1 successors, FD is 1536
        via Connected, Port-channel1

hqans2-602#sh ip eigrp top 10.19.19.0 255.255.255.0
EIGRP-IPv4 Topology Entry for AS(10)/ID(10.255.6.114) for 10.19.19.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2816
Descriptor Blocks:
0.0.0.0, from Rconnected, Send flag is 0x0
      Composite metric is (2816/0), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 10 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.255.6.114
      External data:
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)