Policy route on CSS11506 management interface?

can I setup policy route, so that, all the response traffic came from management interface will go out by it?
If so, please advice how to do it.
Any comments will be appreciated
Thanks in advance

not possible.
If you want this behavior, you can achieve it by source nating on the next-hop all traffic going to the CSS. This will force the CSS to responds back to the nated ip address on the same interface.
Gilles.

Similar Messages

Can Policy Routing be configured on the RPR interface?

We have three 10720 routers connected via RPR ring. And we found the policy routing is not working, however the same config works on Ethernet interfaces.

Are you applying the config on the DPT interface or the Ethernet interface? I'd be suprised if you could configure any policy routing on the DPT interface. Rather I would have thought it should be applied on the Ethernet interfaces involved in the connection. Bear in mind that the router function of the 10720 does not really see the DPT ring, but as logical point to point links.

Can't apply policy route-map on C3750 stack vlan interface

Hi All.
I've come up with this problem and i could see some people have had the same issue. I've tried to overlook and check other replies but it didn't help me. So I'm hoping someone could spot the problem. Here are the details:
2 x WS-C3750G-24T-E in stack
Cisco IOS Software, C3750 Software (C3750-ADVIPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)
switch#sh sdm prefe
The current template is "desktop IPv4 and IPv6 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:                  1.5K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    2.75K
    number of directly-connected IPv4 hosts:        1.5K
    number of indirect IPv4 routes:                 1.25K
number of IPv6 multicast groups:                  1.125k
number of directly-connected IPv6 addresses:      1.5K
number of indirect IPv6 unicast routes:           1.25K
number of IPv4 policy based routing aces:         0.25K
number of IPv4/MAC qos aces:                      0.5K
number of IPv4/MAC security aces:                 0.5K
number of IPv6 policy based routing aces:         0.25K
number of IPv6 qos aces:                          0.5K
number of IPv6 security aces:                     0.5K
There are 2 ISPs, G1/0/1 and G2/0/1. After creating a route-map i can apply a policy route-map to Vlan5 and it accepts without any errors. But when you do sh run vlan5 the command is not there, it's not applied.
Any help will be appretiated.
Thanks.

Hi Jon.
Thanks for your reply. I didn't put those configs as they're basic without use of VRF and WCCP. Also i've checked or tried to find the list of unsupported commands and didn't see them in that list. See config below with some extras:
track 11 rtr 1 reachability
track 22 rtr 2 reachability
ip routing
no ip dhcp use vrf connected
interface GigabitEthernet1/0/1
description ISP1
no switchport
ip address 9.9.9.2 255.255.255.252
no ip proxy-arp
no ip mroute-cache
speed 100
duplex full
ipv6 address 2B01:4B8:0:3::2/64
ipv6 ospf 1 area 0
no mdix auto
no cdp enable
interface GigabitEthernet2/0/1
description ISP2
no switchport
ip address 9.9.9.5 255.255.255.252
ip ospf cost 10000
speed 1000
duplex full
ipv6 address 2B01:4B8:0:7::2/64
ipv6 enable
ipv6 ospf cost 10000
ipv6 ospf 1 area 0
interface Vlan5
description Company Ext Subnet
ip address 9.9.8.1 255.255.255.128
no ip proxy-arp
no ip mroute-cache
ipv6 address 2B01:4B8:1:22::1/64
ipv6 ospf 1 area 15
access-list 111 permit tcp any any eq www
route-map pbr1 permit 10
match ip address 111
set interface GigabitEthernet2/0/1 GigabitEthernet1/0/1
route-map pbr1 permit 20
set interface GigabitEthernet1/0/1 GigabitEthernet2/0/1
route-map pbr2 permit 10
match ip address 111
set ip next-hop verify-availability 9.9.9.6 1 track 11
set ip next-hop 9.9.9.1
route-map pbr2 permit 20
set ip next-hop verify-availability 9.9.9.1 1 track 22
set ip next-hop 9.9.9.6
I've tried to apply both policies pbr1 and pbr2, it allowed to do that without errors but at the end it wasn't there.
Cheers,

Ironport WSA - Management interface

Hello,
I have installed one Ironport WSA appliance for my customer.
I would configure the following interface :
-M1 : for the management
-P1 : for the production interface
-T1 : for L4 inspection
I have specified a default route for M1 and P1.
When I tryed to ping Internet or perform an update of the WSA, I watched the request exit by the M1 interface.
It doesn't work because the management network can't exit in Internet (it's the policy of the customer).
-It's normal that the upgrade of WSA and the ping exit by the M1 interface ?
-If I want perform authentication in NTLM (with an AD domain) the request with the server and the client is performed with P1 or M1 ?
-The upgrade of antivirus & sensor base use M1 or P1 ?
-I thinked that M1 was only used for the management of the WSA (SSH and HTTPS).
-How the WSA appliance can manage two default routes ?
Can you give me more information about M1 and P1 and the role of each one ?
Best Regards
Cédric

You can change the route that the update and upgrades use by going to System Adminstration>Upgrade and Update Settings. Then click on the "Edit Update Settings". You can pick the routing table/interface here. By default its set to the managment interface.
I'm fairly sure that the NTLM traffice from the WSA to the domain is via the managment interface.
P1 is for the proxy traffic. Whatever way you get internet traffice to the box, it goes through P1, in and out (unless you use P2)
M1 is for all of the other stuff: web management, ssh, updates, ldap/ntauth, etc.

Home Hub 3.0B Management interface unresponsive.

This month (2 weeks ago) I upgraded to Infinity 2 and got a new Home Hub 3.0 Type B.
I was able to get it all working as I wanted to - home network using 172.16.0.1/23 (because of conflicts with vpning into work which already routes 192.168./16 and 10./8)
However, often, very often, trying to access the Hub web interface on 172.16.0.1 or via bthomehub.home simply fails to respond. Regardless of the browser, or me using telnet to simulate a HTTP call.
#host bthomehub.home 172.16.0.1
Using domain server:
Name: 172.16.0.1
Address: 172.16.0.1#53
Aliases:
bthomehub.home has address 172.16.0.1
# telnet 172.16.0.1 80
Trying 172.16.0.1...
Connected to 172.16.0.1.
Escape character is '^]'.
GET /
And it just hangs.
Even though the web management interface is unresponsive, the internet seems to work ok, though wifi is sporadic.
Rebooting the hub doesn't seem to help. I read some reports of badly fitted heatsinks on these Type B's - so could mine be over heating and causing this lock up? If I leave it and try again in a few hours it may work again. Yesterday the internet connection dropped twice and when I was able to login to the web interface, the Event log showed that the hub had spontaneously rebooted itself.
Do I have a bad home hub?

Hi pgregg,
Have you tried a full reset of the hub yet? Not just a reboot?
Chris
BT Mod Team.
If you like a post, or want to say thanks for a helpful answer, please click on the Ratings star on the left-hand side of the post.
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

Ipfilter: does policy routing work on Solaris 10?

Hello,
- Does the ipf redirection (aka policy routing) feature work with the
ipfilter that comes with Solaris 10?
I would like to use the the ipf redirection statements "to
interface:router_ip" or "reply-to interface:router_ip" as decribed in
http://coombs.anu.edu.au/~avalon/ipf.new.txt
(The syntax is mentionned in the BNF of the Solaris 10 ipf(4) man
page, but the explanations there are lacking.)
On a machine that has two interfaces, the purpose is to send output
reply packets of a TCP session to the same interface that the input
packets came from. The idea to use ipfilter to do this comes from the
blog entry:
Packets out of the wrong interface
http://blogs.sun.com/carlson/entry/packets_out_of_the_wrong
My first try was to use "reply-to" in a "keep state" rule:
pass in quick on e1000g305000 reply-to e1000g305000:10.13.5.1 proto tcp from any to any port = 443 keep state keep frags group i_sso-test1
Which I understand as "once a connection to port 443 starts on
interface e1000g305000 send all reply packets to the same interface to
the gateway 10.13.5.1"
But it does not work; in the ipf log it shows that the rule matched:
22:56:32.770690 e1000g305000 @i_sso-test1:1 p 10.194.17.11,5648 -> 10.13.5.181,443 PR tcp len 20 60 -S K-S K-F IN
22:56:32.770783 e1000g0 @i_sso-test1:1 p 10.13.5.181,443 -> 10.194.17.11,5648 PR tcp len 20 44 -AS K-S K-F OUT
But the reply packet is not seen on the router (10.13.5.1), nor does
it get to 10.194.17.11 through another route (no firewall on that
machine).
My second try was to use two stateless rules, and to do "source port
routing" for outgoing packets:
pass in quick proto tcp from any to any port = 443 group i_sso-test1
pass out quick on e1000g0 to e1000g305000:10.13.5.1 proto tcp from any port = 443 to any group o_sso-test1
pass out quick proto tcp from any port = 443 to any group o_sso-test1
Which I understand as "incoming packets to port 443 are allowed and
outgoing packets from port 443, if passing on interface e1000g0, are
redirected through interface e1000g305000 via the gateway 10.13.5.1,
if not, are just allowed".
It does not work either; in the ipf log it shows that both the in and
the first out rules matched:
23:09:00.591163 e1000g305000 @i_sso-test1:1 p 10.194.17.11,26080 -> 10.13.5.181,443 PR tcp len 20 60 -S IN
23:09:00.591363 e1000g0 @o_sso-test1:1 p 10.13.5.181,443 -> 10.194.17.11,26080 PR tcp len 20 44 -AS OUT
But again the reply packet seems to be lost in thin air.
I have tried various other rules to no avail.
- Should this work with ipfilter v4.1.9 (592) coming with Solaris 10
u7?
- Am I missing something in the configuration?
- Shouldn't the ipf log show the outgoing reply packet twice? (Once on
the "wrong" interface e1000g0 and once on the interface it is
redirected to e1000g305000.) Or indicate in another manner that the
redirection occurred (like it indicates K-S for "keep state")?
Context:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
default 10.194.7.1 UG 1 2407
default 10.194.7.1 UG 1 5104 e1000g0
10.13.5.0 10.13.5.181 U 1 5 e1000g305000:1
10.194.7.0 10.194.7.81 U 1 3 e1000g0:2
224.0.0.0 10.194.7.81 U 1 0 e1000g0:2
127.0.0.1 127.0.0.1 UH 1 7 lo0:7
# cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009
# ipf -V
ipf: IP Filter: v4.1.9 (592)
Kernel: IP Filter: v4.1.9
Running: yes
Log Flags: 0x70000000 = pass, block, nomatch
Default: pass all, Logging: available
Active list: 0
Feature mask: 0x107
If it matters, this is occuring in a Solaris 10 zone, whith virtual
interfaces one of which uses 801.q tagging (vlan 305, subnet
10.13.5.0/24), and the "router" is a Cisco ACE load balancer with
interface 10.13.5.1 on the server side.
Thanks in advance for your help in this matter!
Best regards,
Dominique
Mr Dominique Petitpierre Email: User@Domain
Division Informatique User=Dominique.Petitpierre
University of Geneva Domain=unige.ch

I was saying
If it matters, this is occurring in a Solaris 10 zone, whith virtual
interfaces one of which uses 801.q tagging (vlan 305, subnet
10.13.5.0/24),...Well, it turns out that 802.1q tagging does matter: packets redirected
by an ipf policy based routing rule to an interface with tagging are
not transmitted.
In order to better see what was happening the ipf rules were extended
like this (stateless case):
@1 pass in quick on e1000g0 proto tcp from any to any port = 443 group i_sso-test1
@2 pass in quick on e1000g305000 proto tcp from any to any port = 443 group i_sso-test1
@1 pass out quick on e1000g0 to e1000g305000:10.13.5.1 proto tcp from 10.13.5.181/32 port = 443 to any group o_sso-test1
@2 pass out quick on e1000g305000 to e1000g0:10.194.7.1 proto tcp from 10.194.7.81/32 port = 443 to any group o_sso-test1
@3 pass out quick on e1000g305000 proto tcp from any port = 443 to any group o_sso-test1
@4 pass out quick on e1000g0 proto tcp from any port = 443 to any group o_sso-test1Also, for the purpose of the demonstration, the zone configuration was
modified to direct all packets to the same interface with tagging,
thus having just one default route:
zonecfg -z sso-test1 info net
net:
        address: 10.13.5.181/24
        physical: e1000g305000
        defrouter: 10.13.5.1
net:
        address: 10.194.7.81/24
        physical: e1000g305000
        defrouter: 10.13.5.1
netstat -rn
Routing Table: IPv4
Destination           Gateway           Flags Ref     Use     Interface
default              10.194.7.1           UG        1       2867
default              10.13.5.1            UG        1         86 e1000g305000
10.13.5.0            10.13.5.181          U         1          2 e1000g305000:1
10.194.7.0           10.194.7.81          U         1          0 e1000g305000:3
224.0.0.0            10.13.5.181          U         1          0 e1000g305000:1
127.0.0.1            127.0.0.1            UH        1          7 lo0:7     (In this peculiar case the default route to 10.194.7.1 is an artifact
displayed by netstat due to the zone isolation mechanism, but it is
not actually used for routing at the zone level; the interface without
tagging, e1000g0, is only displayed on the global zone where ipfilter
operates)
When testing from 10.194.17.11 with "telnet 10.13.4.180 443", it
works. And one can see in the ipf logs that it is the third out rule
that matched (@o_sso-test1:3), i.e. there was no redirection on
another interface (proof that there is nothing wrong with the context
setup):
16:59:30.479660 e1000g305000 @i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 PR tcp len 20 60 -S IN
16:59:30.479844 e1000g305000 @o_sso-test1:3 p 10.13.5.181,443 -> 10.194.17.11,2111 PR tcp len 20 44 -AS OUT
16:59:30.480182 e1000g305000 @i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 PR tcp len 20 40 -A INWhen testing from 10.194.17.11 with "telnet 10.194.7.81 443", it works
also. This time one can see in the ipf logs that it is the second out
rule that matched (@o_sso-test1:2), i.e. there was redirection from
e1000g305000 to e1000g0.
16:59:41.247101 e1000g0 @i_sso-test1:1 p 10.194.17.11,3851 -> 10.194.7.81,443 PR tcp len 20 60 -S IN
16:59:41.247206 e1000g305000 @o_sso-test1:2 p 10.194.7.81,443 -> 10.194.17.11,3851 PR tcp len 20 64 -AS OUT
16:59:41.247508 e1000g0 @i_sso-test1:1 p 10.194.17.11,3851 -> 10.194.7.81,443 PR tcp len 20 52 -A INA packet capture confirms this and one can see in the capture the
SYN-ACK reply packet go out on e1000g0.
The reverse case, essentially the original setup shown in my first
post, where the default route is the interface without tagging
(e1000g0) and the reply packet matches the redirection rule from
e1000g0 to the interface with tagging e1000g305000, the packet is lost
(i.e. is not visible in the packet capture on either interface).
Further tests with stateful redirection ("reply-to") show the same
pattern (does not work when packets are redirected to an interface
with tagging).
It looks like it is a bug: may be ipfilter injects the redirected
packet at a processing stage where it should already have a 802.1q tag
but does not, or something similar; in the working case, ipfilter acts
on a not yet tagged packet which can be used "as is" at the same
processing stage on the non tagging interface, and thus is correctly
transmitted.
Conclusion: ipfilter policy based routing does work on Solaris 10u7,
but, at least in my setup, not when redirection occurs to a 802.1q
tagging interface.
- Could somebody confirm this?
- Is this a known bug? (I didn't find anything relevant on sunsolve or
on the ipfilter mailing list)
Edited by: kleinstein on Oct 1, 2009 4:22 AM
Edited by: kleinstein on Oct 1, 2009 4:25 AM
Edited by: kleinstein on Oct 1, 2009 4:30 AM
Edited by: kleinstein on Oct 1, 2009 4:32 AM
Edited by: kleinstein on Oct 1, 2009 4:37 AM
Edited by: kleinstein on Oct 1, 2009 4:40 AM
Edited by: kleinstein on Oct 1, 2009 4:41 AM

Setting management interface WLC 7.4.121.0

Hello.
I have a problem setting Management interface IP in new controller 5508. I get the error "Error in setting management interface IP".I can not place a management controller IP.
Starting IPv6 Services: ok
Starting Config Sync Manager : ok
Starting Hotspot Services: ok
Starting PMIP Services: ok
Starting Portal Server Services: ok
Starting mDNS Services: ok
Starting Management Services:
Web Server: CLI: ok
Secure Web: Web Authentication Certificate not found (error). If you cannot access management interface via HTTPS please reconfigure Virtual Interface.
License Agent: ok
(Cisco Controller)
Welcome to the Cisco Wizard Configuration Tool
Use the '-' character to backup
Would you like to terminate autoinstall? [yes]: -
Invalid response
Would you like to terminate autoinstall? [yes]: no
System Name [Cisco_bf:dd:c4] (31 characters max):
AUTO-INSTALL: process terminated -- no configuration loaded
Enter Administrative User Name (24 characters max): admin
Enter Administrative Password (3 to 24 characters): ********
Re-enter Administrative Password : ********
Service Interface IP Address Configuration [static][DHCP]: none
Service Interface IP Address: 1.1.1.1
Service Interface Netmask: 255.255.255.0
Enable Link Aggregation (LAG) [yes][NO]: no
Management Interface IP Address: 192.168.10.1
Management Interface Netmask: 255.255.255.0
Management Interface Default Router: 192.168.10.10
Error in setting management interface IP
Management Interface IP Address: 10.10.10.1
Management Interface Netmask: 255.255.255.0
Management Interface Default Router: 10.10.10.100
Error in setting management interface IP
Management Interface IP Address:
Does anyone faced this issue?
Thanks.

Hi,
Try these:
1. With the WLC, Please set flow control(in SecureCRT or hperterminal) to none. Once the changes are made, CLI will start working as usual.
2. Another common reason can be related to the virtual interface configuration of the controller. In order to resolve this problem, remove the virtual interface and then re-generate it with this command:
WLC>config interface address virtual 1.1.1.1
Then, reboot the controller. After the controller is rebooted, re-generate the webauth certificate locally on the controller with this command:
WLC>config certificate generate webauth
In the output of this command, you should see this message: Web Authentication certificate has been generated.
Now, you should be able to access the secure web mode of the controller upon reboot.
3. Try to use some diff IP address for service interface don't use 1.1.1.1.
Regards
Dont forget to rate helpful posts

Mobility group only works using management interface?

Hello, in order to stablish the control traffic between 2 WLC-5508, it's necessary to use the management interface??
It's possible using a dynamic interface o service port ?
I think it only works with management interface, but I don't understand the meaning of this text in the Configuration Manual:
"Mobility control packets can use any interface address as the source, based on routing table."
Thank you,

No... mobility communication is done only with the management interface.
Thanks,
Scott
*****Help out other by using the rating system and marking answered questions as "Answered"*****

Multiple routing tables and/or policy routing

Hey all,
I'm trying to configure a Mac Mini (10.8) for multiple routing tables and policy routing. This server runs Ostinato, a freeware traffic generator. My purpose is to generate traffic on multiple VLANs towards different gateways and different destinations. To that end, I have VLAN tagged the (only) Ethernet port and configured 5 VLANs on it. The first one has the default route (I manage this Mac over this VLAN). The other four have IP addresses in the test range I'm using.
The goal is to have traffic sourced from IP-address-X go out vlanX towards gateway-X. It's counterpart on the far end runs Linux and I have configured it in this way:
ip route add default via <gateway-X> dev ethX table X
ip rule add from <network-X> table X priority X
Researching on OpenBSD forums (since it's the base of MacOS X), provided this:
route -T X add 0.0.0.0/0 -iface <gateway-X>
echo pass in from <network-X> to 0.0.0.0/0 rtable X | pfctl -mf -
However, the Mountain Lion "route" command does not support the -T option, so that killed that idea. Another forum suggested that this would have worked on 10.4:
ipfw add X fwd <gateway-X> ip from <IP-address-X> to any
I tried this on 10.8 though the man page says it's deprecated, and (surprise, surprise) it did not work.
Any ideas to get this working appreciated!
Thanks,
Aaron

Still doesn't have it in 10.9.4.
irene:~ cschwartz$ sudo bash
bash-3.2# route -T add
route: illegal option -- T
usage: route [-dnqtv] command [[modifiers] args]
I'm guessing you want policy-based routing due to VLANs...? If you can get a USB-to-Ethernet adapter, then maybe you can work around this by using multiple physical links instead of VLAN tagging. But if you need source-based routing etc. then no.

WLC 5508 management interface

Hi, I have a particular wireless design that requires one WLC 5508 to be connected to two seperate swithces. Port 1 of WLC is connected trunk to Switch A and Port 2 of WLC is connected to Switch B. Each switch has its own local VLANS. When I connect 1130s LAPs they need to find the management interface initially and then use only AP management interfaces. since there is only one management interface, if I assign management interface on a vlan that is configured on switch A then APs on switch A join fine but those on switch B keep asking for management interface and from capwap debug on WLC it says that join request was received on wrong ineterface ....
the only work around to this was to make routing between switch A and switch B for the two vlans on which APs reside... but for security purposes - client would like to avoid this
any help much appreciated ..

Hi thanks for your reply,
Yes I agree perfectly with your explanation - On both switches I have UDP forward for 5246 and 5247 and everything works fine.
You understood exactly what's happening for initial discovery the Guest AP asks for managemnt interface through WLC port 2 but managerment IP is on admin side WLC port 1 and then it drops packet saying that it was received on the wrong port. In fact that is why I put an ACL between the Admin switch and guest switch taht allows only 5426 capwap control - just to allow that initial discovery from guest AP to contact Management interface which can only be assigned to one port and in my case it is on the admin switch side. And that is why I had to make a route between the two independent switches.
My question is to know if there is any other way with my given design to eliminate this initial discovery to the management inetrface, as my client would like the admin and guest switches to be completely seperated i.e. without the routing. Is there any way that the guest APs can make contact with the AP management interface on their side only skipping the discovery of the management interface ? the guest APs were primed on the admin side so they know the IP. After the initial discovery, if I remove the routing between admin and guest switch, guest APs keep their connectivity without any problems.

LAP registration with ap-manager interface only

Hi, is it possible to register an APs with no visibility of the management interface? The WLC would have a separate ap-manager interface but in a different vfr then management interface. APs can see the ap-manager interface one but not the management one.

I don't mind to use for example service port for the isolated management. But i heared the service port has restrictions under HA design.
Exactly what firmware or model of WLC are you using?
You can't use ther Service Port for production. This port is primarily used for Out-of-Band-Management and for HA SSO.
The document is dated five years ago and describes the 4.0 SW. My question was if there is any trick or possibility to arrange it under present HW & SW.
The document may be five years old, but when you are dealing with WLC 4400, WiSM or 2000/2100 then it's still valid. The APs talk to the controller using the AP-manager interface. This is the main reason why AP-manager interface and management interface IP addresses is recommended to be in the same subnet. It will work if either one is on a different subnet but you'll need to do some routing work done.

AP Manager interface and Virtual Interface

What do each of these interfaces do on the 526 WMAC? I am not sure I understand the functionality and did not find the answer to this in the documentation.
Thanks

Well from a WLC, the management is used to access and manage the wlc. It is also used for communication with the mobility group. AP-Manager is the interface the wlc and the ap's use and the virtual interface is used by internal dhcp, mobility group, webauth, etc. The virtual interface is not routable in your network, it is mainly used by the wlc's for various features.
Here is from a Cisco Doc:
The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA server. If the service port is in use, the management interface must be on a different subnet than the service port.
The AP-Manager interface is used as the source IP address for all Layer 3 communications between the controller and the lightweight access points. The AP-Manager must have a unique IP address and should be on the same subnet as the management interface.
The virtual gateway interface is used to support mobility management, DHCP relay, and embedded Layer 3 security, like guest web authentication and VPN termination. The virtual interface must be configured with an unassigned and unused gateway IP address. If multiple controllers are configured in a mobility group, the virtual interface must be the same on all controllers for seamless roaming.
The service-port interface is mapped only to the physical service port. The service port interface must have an IP address on a different subnet from the management and AP-Manager interfaces. A default-gateway cannot be assigned to the service-port interface, but static routes can be defined through the controller command-line interface for remote network access to the service port.

Policy Routing - Unix and MS (Dare I ask?)

Guys,
Need to route out of a dual homed Unix and Windows box based on the source address or source interface as not to follow the default route.
ie, Packet arrives at host x on interface eth0 but the default route is out of eth1 so I get assemetric packet forwarding on the box.
I think ipfw is the way to policy route on unix, but anyone got a plan for windows?
Many thx indeed, and kind regards,
Ken

The standard action, as performed by router software (such as Cisco IOS), is to select the next hop address and the output device. I will refer to this action as a "match & set" style of action. However, Linux takes a much more flexible approach. In Linux, there are several actions to choose from. The default action performs a route lookup from a specified destination-based routing table. The match & set action then becomes the simplest case of Linux route selection, which is realized when the specified destination-based routing table contains only a single default route. Linux supports multiple routing tables, containing multiple standard destination routes. Bear in mind that each of these routing tables is the same as the entire routing table for any other OS. Linux effectively provides 255 Ciscos to choose from. (For number freaks, Linux 2.2.12 supports 255 routing tables, 255 aggregate realms, and 232 (4294967296 decimal) policy rule priorities.

Local policy route-map for policy route

Hi
this is related my previous question:
I want to set policy route on asr1004, that redirect vpn traffic.
my case is:
asr1004 import a default route 0.0.0.0 from int 0 with bgp neibour address 10.100.100.100
assume internal traffic 10.10.10.0/24 coming into asr1004 on int 1.
assume vpn with ip address 10.2.2.2 is direct linked to asr1004 int 2, and int 2 ip address is 10.2.2.1
assume taget network is 10.200.200.0/24
I want internal traffic (10.10.10.0/24) go to target (10.200.200.0/24) to be redirect to10.2.2.2 (vpn) first, so I add "ip route 10.200.200.0/24 10.2.2.2" on asr1004.
Than, I want vpn (10.2.2.2) encrypt traffic and send it to one of ip in10.200.200.0/24 range again. at this point if I put local policy route-map below, is it will work?
ip local policy route-map vpn-out
access-list 100 permit ip 10.2.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
if not, do I have any change to do policy route for this case?
any comment will be appreciated
Thanks in advance
Julxu

hi Jon
can I refresh the question again:
my case is:
asr1004 import a default route 0.0.0.0 from int 0 with bgp neibour address 10.100.100.100
assume internal traffic 10.10.0.0/16 coming into asr1004 on int 1 with ip address 10.3.3.3
assume vpn with ip address 10.10.2.2 is direct linked to asr1004 int 2, and int 2 ip address is 10.10.2.1
assume taget network is 10.200.200.0/24
I want internal traffic (10.10.0.0/16) go to target (10.200.200.0/24) to be redirect to10.10.2.2 (vpn) first, so I add "ip route 10.200.200.0/24 10.10.2.2" on asr1004.
Than, I want vpn (10.10.2.2) encrypt traffic and send it to one of ip in10.200.200.0/24 range again. at this point if I put local policy route-map below, is it will work?
ip local policy route-map vpn-out
access-list 100 permit ip 10.10.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
such as:
interface TenGigabitEthernet0/0/0
description bgp to get default
ip address 10.100.100.100 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
interface TenGigabitEthernet0/1/0
description get internaltraffic
ip address 10.3.3.3 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
interface GigabitEthernet0/2/1
description vpn
ip address 10.10.2.1 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
media-type rj45
negotiation auto
ip local policy route-map vpn-out
access-list 100 permit ip 10.10.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
ip route 10.200.200.0/24 10.10.2.2
Could you please advise if it is correct?

Policy routing via address ranges

Is it possible to use policy routing based on ranges of a subnet? I want to have 192.168.1.1-100 go out e0 and 192.168.1.101-250 go out e1. From what I've read it only looks like policy routing works with route-maps using access lists

You certainly can.. just use multiple lines in your ACLs to cover each range.
For example,
192.168.1.1-100 can be covered by:
access-list 1 permit 192.168.1.0 0.0.0.63
access-list 1 permit 192.168.1.64 0.0.0.31
access-list 1 permit 192.168.1.96 0.0.0.3
access-list 1 permit 192.168.1.100 0.0.0.0
And use the following for everything else:
access-list 1 permit 192.168.1.0 0.0.0.255
So you can use the following:
route-map PBR permit 10
match ip address 1
set interface e0
route-map PBR permit 20
match ip address 2
set interface e1
Hope that helps - pls rate the post if it does.
Paresh

Policy route on CSS11506 management interface?

Similar Messages

Maybe you are looking for