ACE inline VS one-armed based
Hello Forum, ;-)
I have 2 basic questions I am having doubts about it and would love to have some clarifications:
1) I configure in one ACE4710 (running 4.2.2) context a bridged interface and in another context the same interface, like here below :
---- Context Microsoft ----
ACE1/Microsoft# sh run
interface vlan 503
bridge-group 3
access-group input NONIP
access-group input ALL
access-group output ALL
service-policy input POLICY
no shutdown
interface vlan 1503
bridge-group 3
access-group input ALL
access-group output ALL
no shutdown
interface bvi 3
ip address 120.223.22.30 255.255.255.0
no shutdown
Then I move to the Juniper context and I try to create an interface (either L-2 or L-3) but it doesn’t work:
---- Context Juniper----
ACE1/Juniper(config)# int vlan 503
Error: VLAN creation is not allowed, shared bridged VLAN exists in another context
ACE1/Juniper(config)#
It gives ERROR!!
So if I configure an interface as bridged in one Context, I cannot configure it in another context??
2) If I want to migrate in context Microsoft from One-armed to inline (L-2 bridged), can I migrate one service at the time ( I.e. the config i showed above for context Microsoft, would it work also for one-armed based???)
Thanks so much for your explanations!!
Giulio.
Hello Giulio-
You can only share vlans in one-armed or routed modes. Think of it this way:
Interface vlan 10 and 11 are bridged on context C1. (bridged mode)
Interface vlan 12 and 13 are configured on context C2. (routed mode)
When you have routed mode, your server's gateway is configured to point to the ACE interface IP (or alias if you are have FT.) If a packet comes into the physical interface on the ACE, the processor has to decide which context it belongs to. Since the mac address is the interface on context X, it knows instantly where it goes. It will either hit a VIP, or be routed via the routing table.
If a packet arrived on vlan 12 or 13 and the MAC address did not belong to the ACE, it would drop the packet by basic routing rules. (think a client connected to a hub sees a packet destine to a MAC that is not its own, it drops/ignores the packet.)
In bridged mode, the gateway for your server is the router on the other side of the bridged vlan. I.e., you server is on vlan 10, the gateway is on vlan 11 and ace is bridging them together. When packets arrive to the physical interface, ACE knows the traffic arrived on vlan 10 or 11 which belongs to context C2. If the MAC address is not a VIP, ACE simply hucks the packet out of the other vlan. If you send traffic to the interface MAC that does not belong to a VIP, ACE drops it because it would not make sense to send a packet out the other vlan that has a MAC address that belongs to the interface of the ACE itself.
One-armed mode is simply routed mode with a single vlan and source NAT. Nothing special applies to how ACE handles the traffic versus routed mode with only a single vlan.
Now imagine this:
Interface vlan 10 and 11 are bridged on context C1.
Interface vlan 11 and 12 are configured on context C2.
Remember 3 things:
a.) ACE conserves MAC addresses - so the VIPs share MAC addresses with the interface.
b.) ACE will never communicate between 2 contexts directly.
c.) If you are in a routed mode and share vlans between 2 contexts, ACE will make each vlan have a unique MAC address. If you create unique vlans on each context, ACE uses the same single MAC across all vlans for all contexts.
With traffic that is destine to ACE's MAC address and the IP is a VIP, its not a problem - ACE could figure out which context the traffic belongs to (especially since vlan 11 would have unique mac addresses on each context. However, what if ACE recieved a packet to the interface 10 and 12 MAC address? How would it know if it belonged to the bridged or routed context if it was not a VIP IP? What about traffic that arrives that doesn't have the MAC of any of the interfaces? 2 different entirely behaviors would occur, ACE should drop the packet on the bridged context, and route the packet on the routed context.
So the bottom line is - you can't determine which context a packet would need to apply to in all circumstances if you tried to share vlans in a bridge mode across multiple contexts.
Regards,
Chris Higgins
Similar Messages
-
I'm using an Ace 4710 Appliance deployed in One-Armed mode, using Source NAT to loadbalance HTTP request to a couple of Proxy servers.
Everything is working fine, but the thing is that I can't see the Clients IP addresses on Proxy's logs, so I can't keep track of them.
The Interfaces and Nat configs are:
interface vlan 200
description Server-Side-VLAN
bridge-group 5
nat-pool 5 10.1.1.5 10.1.1.5 netmask 255.255.255.0 pat
service-policy input VIPS
interface vlan 300
description Client-Side-VLAN
bridge-group 5
interface bvi 5
ip address 10.1.1.3 255.255.248.0
description Client-Server-Virtual-Interface
ip route 0.0.0.0 0.0.0.0 10.1.1.1
and the policy map looks like this
policy-map multi-match VIPS
class Port80
loadbalance vip inservice
loadbalance policy Port80
nat dynamic 5 vlan 200
Resource assignment:
sticky ip-netmask 255.255.255.255 address both RESOURCE-CLASS
timeout 5
serverfarm Service80
Any suggestions will be appreciated,
ThanksHi Kanwal,
Thanks for your quick reply,
I've already tried this but it didn't work. The problem is that I don't manage the proxy servers so I rely on their skills to see the logs.
The Proxies are Squid. Do you know if they need to do something else on the servers to see that field of the HTTP header?
But I'll try again tomorrow and let you know how it goes.
Thank you again. -
Sniffer Trace on ACE w/VACLs and One-Arm Design
Wow...that was a mouthful of a title!
Here is what I'm trying to accomplish. There is an application that is having issues. This application is being load balanced by the ACE. The ACE is configured in a One-Armed design. Essentially the application flow is as follows:
client --> ACE VIP --> SNAT Pool --> rserver and then the reverse.
The vlan for my ACE is 3002. It is the only vlan in this context. I have a WildPackets OmniEngine connected to port on the 6500. Here is its config:
interface GigabitEthernet x/xx
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport capture
switchport capture allowed vlan 3002
no ip address
no cdp enable
Here is the problem. When I take a trace I only see the back half of the conversation. That is I only see from the SNAT pool IPs to the rservers and back. I need to be able to see the conversation between the client IPs and the VIP. Does anyone know how this can be done? If you need more details or have questions please fire away! Thanks for the help...
bcThis can be done by setting up a monitor session on the Sup, with the
TenGig/1 as SPAN
source, and a trunk port as SPAN destination.
For example, if the ACE is in slot X, the configuration would be:
monitor session 10 source interface TeX/1
monitor session 10 destination interface Giy/z
The configuration for this port would be:
int giy/z
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
Syed Iftekhar Ahmed -
ACE in one-arm model. VIP on Client Side, servers in other vlan
Hello All
i have a LAN whit many servers,but only 2 need to be balanced. So i think in one-arm model, due to the higth trafic that not be pass trought ACE.
i have a vlan 900 where is the client side and the VIP also. (10.0.9.64/26)
the servers are in vlan 503 (10.12.3.0/24)
it mi first design with ONE-arm but i thinks something is missing, because doesn't work.
the configuration is the next:
MSFC:
svclc module 1 vlan-group 1,2,
svclc vlan-group 1 503,900-902
svclc vlan-group 2 511
interface Vlan503
description OSS_&_Otros
ip address 10.12.3.253 255.255.255.0
standby 10 ip 10.12.3.254
standby 10 priority 150
standby 10 preempt delay minimum 305
interface Vlan900
description MSF_<->_ACE
ip address 10.0.9.126 255.255.255.192
end
access-list 101 permit ip 10.12.3.0 0.0.0.255 10.0.9.64 0.0.0.63
access-list 101 deny ip any any
route-map From_Server_OSS_to_ACE permit 10
match ip address 101
set ip next-hop 10.0.9.125
ACE_1/admin#
ip route 0.0.0.0 0.0.0.0 10.0.9.126
context OSS
allocate-interface vlan 511
allocate-interface vlan 900
allocate-interface vlan 902
member Max20
ACE_1/OSS# sh run
Generating configuration....
access-list EVERYONE line 10 extended permit ip any any
access-list EVERYONE line 20 extended permit icmp any any
rserver host OSS_FES_1
description OSS_Front_End_Server_1
ip address 10.12.3.140
inservice
rserver host OSS_FES_2
description OSS_Front_End_Server_2
ip address 10.12.3.150
inservice
serverfarm host SERVER_farm_OSS
rserver OSS_FES_1
inservice
rserver OSS_FES_2
inservice
class-map match-all VIP-OSS
2 match virtual-address 10.0.9.66 any
policy-map type loadbalance first-match OSS-LB-POLICY
class class-default
serverfarm SERVER_farm_OSS
policy-map multi-match OSS-POLICY-MAP
class VIP-OSS
loadbalance vip inservice
loadbalance policy OSS-LB-POLICY
loadbalance vip icmp-reply
interface vlan 900
description Clients-side
ip address 10.0.9.125 255.255.255.192
access-group input EVERYONE
access-group output EVERYONE
service-policy input OSS-POLICY-MAP
no shutdown
ip route 0.0.0.0 0.0.0.0 10.0.9.126
maybe a i need to allocate the vlan 503 in OSS Context, any advice?
Thanks in advace,
Gianni From ChileSince you server are not behind the ACE in either bridge or routed mode add the follwoing to your config and use nat to get the traffic back to the ace.
This is how one-armed mode works.
ACE_1/OSS# sh run
Generating configuration....
access-list EVERYONE line 10 extended permit ip any any
access-list EVERYONE line 20 extended permit icmp any any
rserver host OSS_FES_1
description OSS_Front_End_Server_1
ip address 10.12.3.140
inservice
rserver host OSS_FES_2
description OSS_Front_End_Server_2
ip address 10.12.3.150
inservice
serverfarm host SERVER_farm_OSS
rserver OSS_FES_1
inservice
rserver OSS_FES_2
inservice
class-map match-all VIP-OSS
2 match virtual-address 10.0.9.66 any
policy-map type loadbalance first-match OSS-LB-POLICY
class class-default
serverfarm SERVER_farm_OSS
policy-map multi-match OSS-POLICY-MAP
class VIP-OSS
loadbalance vip inservice
loadbalance policy OSS-LB-POLICY
loadbalance vip icmp-reply
nat dynamic 10 vlan 900
interface vlan 900
description Clients-side
ip address 10.0.9.125 255.255.255.192
nat-pool 10 0.9.126 10 0.9.126 netmask 255.255.255.192 pat
access-group input EVERYONE
access-group output EVERYONE
service-policy input OSS-POLICY-MAP
no shutdown -
ACE 4700 one-arm design with SSL termination
Hi,
We are evaluating the one-arm design for the ACE 4700 and need some clarifications:
1. Are there any limitations in the one-arm design and the SSL offloading
2. Can the ACE be configured with an IN and an OUT vlan to the router
CLIENT -> Router -> ACE IN -> ACE OUT -> Router -> Server Vlan
so that the SSL and the clear text traffic is in a separate Vlan?
3. In some sample configuration i saw SNAT configuration on the ACE to modify the client IP. This i assume is for instructing the return traffic from the server to go through ACE? Using SNAT we eliminate the requirement for NAT or PBR on the router? Will i still be able to insert the client IP address after the SSL offload?
I would appreciate if you can share some sample configs
Regards,
George GeorgiouThere are two ways to implement One Arm topology.
1. One Arm with PBR & 2.One Arm with SRC NAT
PBR/Source Nat is needed to ensure that the return traffic from Real Servers should not bypass ACE.
1. Are there any limitations in the one-arm design and the SSL offloading
The limitations/config issues I can think of are following
One ARM with PBR:
Direct access to Servers require the enabling of Assymtric routing (by turning off Normalization). If direct server access is not required then you dont need to enable assymtric routing. Now for these assymetric connection (Direct Server Access return traffic) its required to purge idle connections more frequently (default being one hour).
One ARM with SRC NAT:
You will loose the client information. Server logs will show the connections initiated from NAT IP Pool configured on ACE.
2. Can the ACE be configured with an IN and an OUT vlan to the router
CLIENT -> Router -> ACE IN -> ACE OUT -> Router -> Server Vlan
so that the SSL and the clear text traffic is in a separate Vlan?
Yes you can do that but wouldnt it make it routed mode topology?
3. In some sample configuration i saw SNAT configuration on the ACE to modify the client IP. This i assume is for instructing the return traffic from the server to go through ACE? Using SNAT we eliminate the requirement for NAT or PBR on the router? Will i still be able to insert the client IP address after the SSL offload?
As I said earlier you loose the Source IP address with SRC NAT. But with ACE you have an option to use header-insert and insert this source ip as an HTTP Header.
Details at
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/slb/guide/classlb.html#wp1040008
HTH
Syed Iftekhar Ahmed -
Probe fail on Standby ACE in One-armed mode
Hi there
I'm Kilsoo.
I made One-armed mode using ACE.
Real servers are in away Vlan from ACE.
So, I configured the PBR with ACE alias ip address for the next-hop on the real server's gateway interface.
And, the probe from active ACE works well.
But, the probe from standby ACE was fail.
At this point, my first question
Is it normal situation that the probe fail from standby ACE????
So, I made the route-map for PBR like below for temporary solution.
route-map deny PBR 5
match ip address Probe_ACL
route-map permit PBR 10
match ip address L4_ACL
set ip next-hop <Alias IP address>
ip access-list extended Probe_ACL
pemit ip any <Standby ACE's IP address>
ip access-list extended L4_ACL
permit tcp <Real server's IP address> eq 80 any
Second question...
Do you have any other good solutions???
ThanksHi Cesar
Thanks for your reply.
But I think I was confuse when I wrote the message.
I used both ace's vlan ip address for next-hop ip address like your advice.
Do you know the standby ace can't check probe without route-map in one-armed mode like below diagram???
Backbone Router
|
|
|
Supervisor --------------------ACE(vserver: 172.19.100.100)
| (vlan 200)
|
|
|(vlan 110)
|
|
Real servers
(172.19.110.111) -
Source IP in One armed Mode ACE
Hi,
How do we find actual Client Source IP address in One armed mode ACE for NON-HTTP application like LDAP,FTP and etc....It's not possible. Insertion within header works only for HTTP and HTTPS with SSL offload.
-
ACE One Arm Mode vs Routed Mode
Gents,
When is it required to use the One Arm Mode and one do I use the routed mode? Actually I am confused and would really like to know the pros and cons of each?
Regards,
HeshamHi Hesham,
When you do not want to change the physical topology of your network then you usually go with ONE ARM mode.
Such as default gateway on server, IP addressing on servers. In this case client can access the server directly as well.
Its a flat network topology where your VIP and servers are in the same network ( VLAN ).
You use routed mode when you want to segregate the servers in seperate vlan and don't want to allow client to access it directly.
Client and VIP in same VLAN >>> ACE >>>>>> Server VLAN ( In this case we usually point the default gateway to ACE)
hope it helps.
regards,
Ajay Kumar -
One-armed ACE with servers gateway to ACE (no SNAT?)
Hello ACE experts, I have two questions;
Design;
One-armed ACE appliance where the servers use the ACE as default gateway? (and ACE of course a default route to the router)
Apparently it works in my lab… But since it’s not documented I wonder what the gotcha’s are?
(This would eliminate the SNAT requirement for one-armed)
I know I need;
-no icmp-guard to allow ‘asymmetric icmp’
-no normalisation to allow asymmetric traffic when not using VIP (router to server is direct, but server response uses the ACE)
And other question;
Bandwidth license, apparently ALL traffic counts to this limit, even only routed traffic, is this true?
So In routed mode, all traffic from server backend that needs to be routed over ACE - a backup!? - counts?
Regards KristofHi
the reason I use "process every packet" was it was one of the advantage being offerd by one arm mode to not to process every packet. The main reason for one arm deployment, as i mentioned previously also, is ease in placement of ACE. We can have servers in any vlan and can put ACE altogther iin different VLAN. i guess this advantage is of no use for you because servers are already in same segment as that of ACE.
The main cause ,which i understand, customer don't like the concept of SNAT is because of its restriction on reporting and security. Client IP will be hide, so any reporting on servers for sessions source (or for monitoring attacks) will not be fruitfull. Although with feaures like XFF we can overcome this fault for HTTP traffic, but still customers don't like the consept of hiding details of IP accessing their servers.
regarding B/w count in bridge mode i am not 100% sure but beleive here again every passing traffic will count as ACE still monitor every packet and decide whether its a passing traffic or part of loadbalancing or hitting any of its confiugred policy. -
ACE 4710 one-arm L4 load balancing removes accept-encoding?
We have built a simple one-arm PAT config to round robin load balance two Varnish servers. In the "Default L7 load-balancing action" we have left compression to "N/A". It looks like the ACE removes "Accept-Encoding: gzip, deflate" from the client header.
Is this normal behaviour? We would like the Varnish to do the compression. Do we need modify the headers to get this through the ACE?Hi,
Yes this does seem to be the behavior. Please read below:
HTTP compression is a capability built into web servers and web browsers to improve site performance by reducing the amount of time required to transfer data between the server and the client. Performing compression on the ACE offloads that work from the server, thereby freeing up the server to provide other services to clients and helping to maintain fast server response times.
When you enable HTTP compression on the ACE, the appliance overwrites the client request with "Accept-Encoding identity" and turns off compression on the server-side connection. HTTP compression reduces the bandwidth associated with a web content transfer from the ACE to the client.
So ACE rewrites the ACCEPT-ENCODING header to IDENTITY to indicate to the server that it should not compress the return data. That would be done by ACE.
Also, default method is used when client comes with both gzip or deflate for "ACCEPT ENCODING". For compression to work, a client must send a request with an ACCEPT-ENCODING method of gzip or deflate. If a client sends both methods, then the ACE uses the configured method(default method).
Also, you can see if ACE is compressing the packets or in "show service-policy detail.
switch/Admin#
show service-policy L7_COMP_SLB_POLICY detail
Status : ACTIVE
Description: -----------------------------------------
Interface: vlan 1 108
service-policy: L7_COMP_SLB_POLICY
class: vip
VIP Address: Protocol: Port:
2.0.5.1 tcp eq 80
loadbalance:
L7 loadbalance policy: pm
VIP ICMP Reply : ENABLED
VIP state: OUTOFSERVICE
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 0
dropped conns : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
L7 Loadbalance policy : pm
class/match : h
ssl-proxy client : c
LB action :
primary serverfarm: sf1
state: DOWN
backup serverfarm : -
hit count : 0
dropped conns : 0
compression : on <------------------------------ Compression is enabled if the value is "on"
compression bytes_in : 0 bytes_out : 0 <--- Number of bytes transmitted after compressing the server response
Compression ratio : 0.00% <------------------------------ Percentage of data compressed
Gzip: 0 Deflate: 0 <--------------- Number of times the method is used
compression errors: _
User-Agent : 0 Accept-Encoding : 0 |
Content size: 0 Content type : 0 |
Not HTTP 1.1: 0 HTTP response error: 0 |-- Check these error counters to see if they are increasing
Let me know if you have any questions.
Regards,
Kanwal -
is it possible to preserve the clients originating IP address somewhere while using the 4710 in one armed mode? I have a situation where the client source ip is needed, and I am deciding between one-armed mode and inline. I'd like to use one-armed, so that only load balanced traffic traverses the load balancer, but I haven't seen an example where that can be done without loosing the clients src address.
Only thing I can think of is http header-insertion. Create an action-list, that inserts the original client src.ip/port into the http-header. The configuration is quite simple:
action-list type modify http name
header insert both Host header-value %is:%ps
Then apply the action-list to your loadbalance policy-map.
Take a look at the url below for futher information:
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/classlb.html#wp1131842
But that depends on your situation. If is the original client src.ip/port is expected in the L3/L4 header, this won't cut it. Is this for logging purposes or some form of packet filtering ?
If you intend to run your ACE in one-arm mode, in my opponion, src.nat and header-insertion is your only option.
hth
/Ulrich -
Is't Single-VLAN One-Armed Mode let the pop-ups error?
Dear all
In my network I deployed Single-VLAN One-Armed Mode In this mode,the real server’s default gateway is the upstream router. To ensure the return
flow traverses back through the load balancer, the IP address of the client isrewritten to that of the load balancer.
Direct access web was fine ,however when open Pop-ups website will appear error Example, the figure-1 :
figure-1
When I used real Server IP address not through ACE anything will be fine. Example, the figure-2 :
figure-2
The Web's Code
<%@ page language="java" pageEncoding="UTF-8"%>
<%@ taglib uri="/WEB-INF/hnisi.tld" prefix="hnisi"%>
<%@ include file="/jsp/framework/head.jsp"%>
<%@ page import="cn.sinobest.framework.util.DTOUtil,cn.sinobest.framework.util.Util,cn.sinobest.framework.util.ConfUtil" %>
<%
//当前登录用户 所属系统机构
String orgCode = DTOUtil.getUserInfo().getBAE001();
//操作员ID
String operId = DTOUtil.getValue("OPERID");
//角色类型
String roleType = DTOUtil.getValue("ROLETYPE");
String fromFuncDesc = DTOUtil.getValue("fromFuncDesc");
//所选操作员的姓名
String sOperatorName = DTOUtil.getValue("SOPERATORNAME");
//权限树 where 条件
String whereClsTree = " rightid in ( select distinct B.RIGHTID "+
" from FW_RIGHT B"+
" left join FW_OPERATOR2RIGHT A on LOCATE(B.RIGHTID,A.RIGHTID) = 1"+
" where A.AAE100 ='1'"+
" and B.AAE100 ='1' and A.operid = '"+operId+"' ";
//条件:有效角色,当前登录用户只能操作用户所属系统机构及下级机构的角色,以及上级机构的共享角色
String whereCls =" AAE100 ='1' and (BAE001 like '"+orgCode+"%' or ( IFSHARED = '1' and LOCATE(BAE001,'"+orgCode+"') = 1))";
if(!Util.isEmpty(roleType)){//角色类型
whereClsTree +=" and AUTHTYPE='"+roleType+"' ";
String roleType_zdfpzj = ConfUtil.getDict("ROLETYPE", "13");//最大分配角色
if("2".equals(roleType)){//分配角色包括:分配角色、最大分配角色
whereCls += " and ROLETYPE in('"+roleType+"','"+roleType_zdfpzj+"') ";
}else{
whereCls += " and ROLETYPE='"+roleType+"' ";
whereClsTree +=" )";
%>
<%-- 导航栏标签 --%>
<hnisi:gNavStr />
<legend style="cursor:hand;" >
<span>
<img id="img_fw_authmngr_geneauth_list_grid" src="${ctx}/themes/default/images/query_icon_right.gif">
</span>
<span title="单击展开或收缩">
<b><%=sOperatorName%></b>已拥有的权限树
<hnisi:tree id="menus" type="1" whereCls="<%=whereClsTree %>"/>
</span>
</legend>
<form name="roleListForm" method="post">
<%-- 角色列表--%>
<hnisi:glt id="fw_authmngr_geneauth_role" whereCls="<%=whereCls %>" />
<p align="center">
<%-- 确定按钮 --%>
<hnisi:btn name="btnQuery" onclick="roleAutoOk()" value="保存" href="javascript:void(0)"/>
<%-- 清除按钮 --%>
<hnisi:btn name="btnCls" onclick="cls()" value="清除" href="javascript:void(0)"/>
<%-- 关闭按钮 --%>
<hnisi:btn name="btnClose" onclick="winClose()" value="关闭" href="javascript:void(0)"/>
</p>
</form>
<form name="roleForm">
<input type="hidden" name="OPERID" value="<%=operId %>"/>
<input type="hidden" name="ROLEIDS">
</form>
<script type="text/javascript">
<!--
var orgCode ="<%=orgCode%>";
var operId ="<%=operId%>";
var roleType ="<%=roleType%>";
* 权限列表窗口
* @param roleId:角色ID
function winRight(roleId){
var eventId="1";//授权事件(1 查询、2 授权)
//弹出模态对话框,并加上时间戳以防止缓存
window.showModalDialog("right!left.do?EVENTID=" + eventId+"&ROLETYPE="+roleType+"&ROLEID=" + roleId+"&_t="+new Date().getTime());
* 确定-保存授权信息
function roleAutoOk(){
$(function(){
var roleIds = "";
$.each($("input[name='checkbox']:checked"),function(i,o){
roleIds += (i==0 ? "" : ",")+o.value;
if (roleIds == ""){
FWalert("请选择要操作的角色!");
return;
roleForm.ROLEIDS.value = roleIds;
var params = FWGetForm(roleForm);
if(params.ROLEIDS ==""){
FWalert("请选择要操作的角色!");
}else {
var fromFuncDesc = "<%=fromFuncDesc%>";
//先进入本次权限变更列表页面,确认后再保存
var title = encodeURIComponent('授权确认');//对话框的标题
var url = "right!list.do?OPERID="+operId+"&fromFuncDesc="+fromFuncDesc+"&ROLETYPE="+roleType+"&ROLEIDS="+roleIds+"&title="+title+"&_t="+new Date().getTime();
var position="resizable:1;status:0;help:0;scroll:1;center:1;dialogWidth:800px;dialogHeight:500px";
window.showModalDialog(url,window,position);
* 直接授权:弹出权限树窗口
function directAuto(){
var eventId="2";//授权事件(1 查询、2 授权)
//弹出模态对话框,并加上时间戳以防止缓存
window.showModalDialog("right!left.do?EVENTID=" + eventId+"&ROLETYPE="+roleType+"&OPERID=" + operId+"&_t="+new Date().getTime());
* 清除:清除已选择的角色 checkbox
function cls(){
var c_checkbox=document.getElementsByName('checkbox');
for (i=0;i<c_checkbox.length;i++){
c_checkbox[i].checked=false;
* 关闭窗口
function winClose(){
window.close();
//-->
</script>
</body>
</html>
The ACE's config
`show running-config`
Generating configuration....
boot system image:c4710ace-mz.A4_2_0.bin
interface gigabitEthernet 1/1
switchport access vlan 100
no shutdown
interface gigabitEthernet 1/2
shutdown
interface gigabitEthernet 1/3
shutdown
interface gigabitEthernet 1/4
switchport access vlan 3
no shutdown
access-list ALL line 8 extended permit ip any any
access-list allowany line 8 extended permit ip any any
access-list allowany line 16 extended permit icmp any any
probe icmp Ping
interval 2
faildetect 2
passdetect interval 2
passdetect count 1
receive 2
probe tcp TCP6666
description RPC Client Access
port 6666
interval 30
passdetect interval 60
connection term forced
open 10
probe tcp TCP8888
description RPC Client Access
port 8888
interval 30
passdetect interval 60
connection term forced
open 1
rserver host YB1
ip address 110.43.102.241
inservice
rserver host YB2
ip address 110.43.102.245
inservice
rserver host YB3
ip address 110.43.102.246
inservice
rserver host YB4
ip address 110.43.102.247
inservice
rserver host YB5
ip address 110.43.102.248
inservice
rserver host YB6
ip address 110.43.102.242
inservice
serverfarm host YB01farm
predictor leastconns
probe TCP6666
rserver YB2
inservice
rserver YB3
inservice
rserver YB4
inservice
rserver YB5
inservice
serverfarm host YB02farm
predictor leastconns
probe TCP8888
rserver YB2
inservice
rserver YB3
inservice
rserver YB4
inservice
rserver YB5
inservice
parameter-map type http PRESIST-REBALANCE
persistence-rebalance
sticky ip-netmask 255.255.255.255 address source YB01-GRP
timeout 60
replicate sticky
serverfarm YB01farm
sticky ip-netmask 255.255.255.255 address source YB02-GRP
timeout 60
replicate sticky
serverfarm YB02farm
sticky http-cookie COOKIE1 STICKYYB01
cookie insert browser-expire
timeout 3600
replicate sticky
serverfarm YB01farm
action-list type modify http IP-header
header insert request X-Forwarded-For header-value "%is"
class-map match-all YB01-slb-vip
2 match virtual-address 110.43.102.251 any
class-map match-all YB02-slb-vip
2 match virtual-address 110.43.102.252 any
class-map type management match-any remote_access
description remote-access-traffic-match
2 match protocol xml-https any
3 match protocol icmp any
4 match protocol telnet any
5 match protocol ssh any
6 match protocol http any
7 match protocol https any
8 match protocol snmp any
policy-map type management first-match remote_mgmt_allow_policy
class remote_access
permit
policy-map type loadbalance http first-match YB01-slb
class class-default
sticky-serverfarm STICKYYB01
action IP-header
policy-map type loadbalance http first-match YB02-slb
class class-default
sticky-serverfarm YB02-GRP
action IP-header
policy-map type loadbalance first-match YB6666
class class-default
sticky-serverfarm STICKYYB01
action IP-header
insert-http https header-value "on"
policy-map multi-match client-vips
class YB01-slb-vip
loadbalance vip inservice
loadbalance policy YB6666
loadbalance vip icmp-reply active
nat dynamic 100 vlan 100
appl-parameter http advanced-options PRESIST-REBALANCE
class YB02-slb-vip
loadbalance vip inservice
loadbalance policy YB02-slb
loadbalance vip icmp-reply active
nat dynamic 100 vlan 100
interface vlan 3
ip address 192.168.50.2 255.255.255.240
access-group input ALL
service-policy input remote_mgmt_allow_policy
no shutdown
interface vlan 100
ip address 110.43.102.238 255.255.255.0
access-group input allowany
nat-pool 100 110.43.102.239 110.43.102.239 netmask 255.255.255.255 pat
service-policy input remote_mgmt_allow_policy
service-policy input client-vips
no shutdown
ip route 0.0.0.0 0.0.0.0 110.43.102.112Hi,
The error comes when accessing the website through LB. The error is thrown by the server. Do we know what does that error indicate and will be thrown by server under what circumstances?
Can you just try with one server in the serverfarm and check if it works fine?
Does it load initial page at all or throws error right away.
What do you see in show conn output? Which VIP is in question here?
Regards,
Kanwal -
CSM in one armed mode Redundancy
Hi,
I have a customer with a one arm setup. However they have no server vlan, only a client vlan. They are using source nat and it is working, however I am unsure how to setup redundancy as the alias command seems to be generally used on the server vlan.
i am running hsrp and a ft vlan accross the csm's
Does anyone have any experience of this type of setup, do i need to add any additional config for fault tolerence??
Cheers
ScottScott,
you can use the alias and whatever vlan [client or server].
It is required if your servers or clients are using the CSM as default gateway.
There is no special config required when doing fault tolerance in one-armed mode.
It's the same as inline mode.
Gilles. -
CSM-S, move to one-arm configuration.
Hello.
We are using a couple of CSM-S with a single subnet bridge and fault tolerance configuration. Now we are evaluating to move to an one-arm configuration, so I’m reading some design guides.
We want to move to this topology because there are some advantages like efficient utilization of resources.
Because we are serving different areas with different security level I’m looking for best practices also.
The main question is about security because CSM does not support virtual contexts like ACE.
Any suggestions?
Thanks.
AndreaHello Andrea,
As you noted, the capability for ACE to be able to keep traffic segregated is much easier to work with than the CSM's. Basically, you have to utilize both client groups and the VLAN statement under Vservers to be able to keep traffic segregated. Here is an example:
module ContentSwitchingModule 4
vlan 100 client
ip address 192.168.100.1 255.255.255.0
vlan 150 client
ip address 192.168.150.1 255.255.255.0
vlan 200 client
ip address 192.168.200.1 255.255.255.0
vlan 250 client
ip address 192.168.250.1 255.255.255.0
natpool POOL-1 192.168.100.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-2 192.168.150.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-3 192.168.200.2 192.168.250.2 netmask 255.255.255.0
natpool POOL-4 192.168.250.2 192.168.250.2 netmask 255.255.255.0
serverfarm DMZ1
nat server
nat client POOL-1
real 192.168.100.50
no inservice
real 192.168.100.51
inservice
real 192.168.100.52
inservice
serverfarm DMZ2
nat server
nat client POOL-2
real 192.168.150.82
no inservice
real 192.168.150.83
inservice
real 192.168.150.84
inservice
serverfarm DMZ3
nat server
nat client POOL-3
real 192.168.200.75
no inservice
real 192.168.200.78
inservice
real 192.168.200.90
inservice
serverfarm DMZ4
nat server
nat client POOL-1
real 192.168.250.82
no inservice
real 192.168.250.83
inservice
real 192.168.250.84
inservice
vserver DMZ1
virtual 192.168.100.10 tcp www
vlan 100
serverfarm DMZ1
persistent rebalance
inservice
vserver DMZ2
virtual 192.168.150.10 tcp www
vlan 150
serverfarm DMZ2
persistent rebalance
inservice
vserver DMZ3
virtual 192.168.200.10 tcp www
vlan 200
serverfarm DMZ3
persistent rebalance
inservice
vserver DMZ4
virtual 192.168.250.10 tcp www
vlan 250
serverfarm DMZ4
persistent rebalance
inservice
In the above configuration, if any packet comes into vlan 100 destine to 192.168.100.10 on port 80, it can hit the vip. If the same packet comes into any other vlan, it will not be able to hit the vip. The "vlan 100" statement under DMZ1 vserver filters the traffic so that only traffic that came into that vlan can hit that specific vserver.
If you need to do additional filtering, say by source subnet range, you can use client groups to furthur permit/deny traffic at a more granular level. Here is an example:
(The access-list is created globally on the 6500 - the access list is then referenced by number in the CSM configuration. ONLY standard access lists can be used!!)
access-list 2 permit 192.168.0.0 0.0.255.255
access-list 2 deny any
access-list 3 permit 10.10.0.0 0.0.255.255
access-list 3 deny any
policy 192_subnet_filter
client-group 2
serverfarm DMZ4
vserver DMZ4
virtual 192.168.250.10 tcp www
vlan 250
slb-policy 250_subnet_filter
persistent rebalance
inservice
With this configuration, only traffic with a source IP of 192.168.0.0/16 or 10.10.0.0/16 that arrive on vlan 250 will be allowed to hit the vserver. "Client-Group 2" refers to the "Access-list 2" in the global config.
Note that the serverfarm that used to be under the vserver was removed. If you leave the serverfarm DMZ4 statement under the vserver along with the slb-policy applied, and traffic that does not match your client group is sent to that serverfarm. It is another way of filtering traffic out. If you do not include a fallback serverfarm (like the example above), any traffic that doesn't match the client group is reset.
Let me know if you have any furthur questions!
Regards,
Chris Higgins -
Trade-off between the one-arm and two-arm WAE designs
We are configuring a WAE (model 512) for a branch office and I was wondering if someone could please tell me the trade-off between the one-arm and two-arm WAE designs..
thanks..
greg..if you are using WCCP then the WAE becomes the client withing the servcie groups 61, 62. In order to accelerate both vlans then apply the ip redirect 61 in on the client vlan ineterfaces to the one interface.
If inline, you can use both 2 port groups for each client interface or trunk all to a single inetrface and configure which vlans you would like to accelerate.
Now in terms of of using both GE inetrfaces, I would have to check. A topology diagram would help
Maybe you are looking for
-
Sap UM connector 9.1.2 trouble with "SAP User Management User Recon" task
Hello All, i have a problem with Sap UM Connector version 9.1.2. OIM version 11.1.1.5 Windows 2008 R2 Problem is: Then accounts in Sap are created through direct provisioning feature of connector everything works ok (subsequent update or delete an ac
-
Help for printing PDF docs.
Hi, I am trying to print a PDF doc, and a window appear is " Prop Res DLL not loaded "!!! I can print everything except PDF file Thanks for you help PS: What is the meaning of ERROR Prop .....etc Ce message a été modifié par: chomedey657
-
IPad programming - listing class/object variables
Hey there, Im stuck with a little thing, I think i'm confused with value or object coding, anyways heres the deal: I've made and declared an object which consists of some information (ID, name, etc) and I want to parse XML results into this object. T
-
Disk utility program crashing in lion 10.7.3
The Disk Utilty application will not open, crashes on launch. Does anyone have a solution? Here is the crash report: Process: Disk Utility [3190] Path: /Applications/Utilities/Disk Utility.app/Contents/MacOS/Disk Utility Identifier
-
More than Six Activities in the production
Dear All, In our Project Scenario, We have defined 4 activities, Viz: Labor, Testing, Rework and Set up for Production purpose as per the Client Requirement, but the client wants to have a Production Hrs & Overtime Hrs separately for each of the act