您的当前位置：首页思科与F5对接Radius

思科与F5对接Radius

来源：爱问旅游网

简介

本文描述如何配置在F5本地流量管理器(LTM)的iRules思科身份服务引擎的(ISE) Radius和HTTP负载均衡。

先决条件

要求

Cisco 建议您了解以下主题：

• 思科ISE部署、验证和授权

• 在F5 LTM的基础知识

• 在Radius和HTTP协议的知识

使用的组件

本文档中的信息基于以下软件和硬件版本：

• Cisco Catalyst 交换机

• F5 BIG-IP版本11.6

• Cisco ISE软件版本1.3及以后

配置

网络图

F5 LTM配置作为Radius的一loadbalancer。确保是重要的，所有验证和核算数据包同一会话的重定向对同一个ISE节点。IETF属性呼叫站点Id使用持续时间配置文件。

没有使用NAT。LTM路由虚拟服务器的数据包给包括两个成员的正确池。

确保回来从ISE节点的流量通过LTM去是重要的。如果不是纳季将看到在答复的实际IP地址而不是虚拟。在这样方案中SNAT在LTM将必须使用-，但是那将中断大多ISE流-，因此不支持。

配置

ISE

为了简化条款ISE配置被跳过。请参考的其他资源。在ISE的特别配置没有需要除了网络设备(172.16.33.1)的新增内容。

F5 LTM

LTM已经预先配置与正确VLAN/接口。

两ISE节点被添加作为节点：

池为两节点创建(监听是基于的icmp，可能是udp/radius) ：

iRule创建。它寻找每属性值对查找IETF呼叫站点Id的(31)每Access-Request并且创建根据它的持续时间规则是值：

iRule的内容：

when CLIENT_ACCEPTED {

binary scan [UDP::payload] ccSH32cc code ident len auth attr_code1 attr_len1

set index 22

while { $index < $len } {

set hsize [expr ( $attr_len1 - 2 ) * 2]

binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2

# If it is Calling-Station-Id (31) attribute...

if { $attr_code1 == 31 } {

persist uie $attr_value 30

return

}

set index [ expr $index + $attr_len1 ]

set attr_len1 $next_attr_len2

set attr_code1 $next_attr_code2

}

持续时间哈希基于配置文件创建。该配置文件在iRule上使用：

标准的虚拟服务器创建。UDP配置文件选择：

该虚拟服务器使用配置池和持续时间配置文件：

验证

可能使用要检查流量是否正确地被平衡radius模拟程序。

发送4访问请求到与特定呼叫站点Id属性的虚拟服务器(172.16.33.103)地址：

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -ai 21:11:11:11:11:21 -n 4

Starting sniffing daemon

Choosen vmnet3 interface for sniffing

Sniffing traffic from udp and src 172.16.33.103 and port 1812

Sending Radius Access-Requests

Sending Radius Packet.......

Radius packet details: 172.16.33.1:27483 -> 172.16.33.103:1812

Radius Code: 1 (Access-Request)

Radius Id: 179

AVP[0] Type: 1 (User-Name) Value: cisco

AVP[1] Type: 2 (User-Password) Value: *

AVP[2] Type: 4 (NAS-IP-Address) Value: 172.16.33.1

AVP[3] Type: 31 (Calling-Station-Id) Value: 21:11:11:11:11:21

Sending Radius Packet.......

Radius packet details: 172.16.33.1:27483 -> 172.16.33.103:1812

Received Radius Packet......

Radius packet details: 172.16.33.103:1812 -> 172.16.33.1:27483

Radius Code: 2 (Access-Accept)

Radius Id: 236

AVP[0] Type: 18 Value: Hello, cisco. This is server1.

Waiting 5 seconds for the responses

Finishing sniffing thread

Results:

Radius-Request sent: 4

Radius-Accept received: 4

Radius-Reject received: 0

Other Radius messages received: 0

Finishing main thread

两个ISE服务器配置返回到达根据服务器的另外的AV对。ISE-PSN1一将返回server1的Hello消息， ISE-PSN2将返回server2的Hello消息(在ISE网络访问：ISE主机名使用等于条件)。

确认另外服务器响应基于另外呼叫站点Id属性：

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -ai 21:11:11:11:11:21 -n 4 | grep \"Hello\"

AVP[0] Type: 18 Value: Hello, cisco. This is server1.

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -ai 21:11:11:11:11:22 -n 4 | grep \"Hello\"

AVP[0] Type: 18 Value: Hello, cisco. This is server2

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -ai 21:11:11:11:11:23 -n 4 | grep \"Hello\"

AVP[0] Type: 18 Value: Hello, cisco. This is server1.

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -ai 21:11:11:11:11:24 -n 4 | grep \"Hello\"

AVP[0] Type: 18 Value: Hello, cisco. This is server2

在LTM池的统计信息能验证：

LTM的持续时间缓存：

root@(f5)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /ltm persistence persist-records

Sys::Persistent Connections

universal 32313a31313a31313a31313a31313a3234 172.16.33.103:any 172.16.34.101:any (tmm: 1)

Total records returned: 1

值\"32313a31313a31313a31313a31313a3234\"是ascii表示\"21:11:11:11:11:24\"。匹配此的所有后续的流量将发送对ISE-PSN2 (172.16.34.101)。持续时间条目创建与超时30秒(根据仍然存在in命令iRule)。

在条目以后超时：

root@(f5)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /ltm persistence persist-records

Sys::Persistent Connections

Total records returned: 0

同样呼叫站点Id的流量也许重定向到ISE-PSN1 (172.16.34.100)，新建的条目将创建：

root@(f5)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /ltm persistence persist-records

Sys::Persistent Connections

universal 32313a31313a31313a31313a31313a3234 172.16.33.103:any 172.16.34.100:any (tmm: 1)

Total records returned: 1

然而对于以后30秒匹配此模式的所有流量将重定向对ISE-PSN1。

Radius Cisco AV对审计会话id

IETF呼叫站点Id属性持续时间的是最常用的。但是能也使用其他属性。与审计会话id iRule示例的Cisco AV对：

when CLIENT_ACCEPTED {

binary scan [UDP::payload] ccSH32cc code ident len auth attr_code1 attr_len1

set index 22

while { $index < $len } {

set hsize [expr ( $attr_len1 - 2 ) * 2]

binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2

# If it is Vendor specific atribute...

if { $attr_code1 == 26 } {

#search for string audit-session-id

if { $attr_value contains \"617569742d73657373696f6e2d69\" } {

persist uie $attr_value 30

return

}

set index [ expr $index + $attr_len1 ]

set attr_len1 $next_attr_len2

set attr_code1 $next_attr_code2

}

radius模拟程序使用再要测试：

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -avi 9 -avt 1 -avv \"audit-session-id=0A30276F00001225751086B9\" -avx string -ai 21:11:11:11:11:20 -n 4 | grep Hello

AVP[0] Type: 18 Value: Hello, cisco. This is server1

root@arrakis:# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s Krakow123 -avi 9 -avt 1 -avv \"audit-session-id=0A30276F00001225751086B9\" -avx string -ai 21:11:11:11:11:20 -n 4 | grep Hello

AVP[0] Type: 18 Value: Hello, cisco. This is server2

结果两个持续时间条目创建：

root@(f5)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /ltm persistence persist-records

Sys::Persistent Connections

universal 00000009012b617569742d73657373696f6e2d693d30413330323736303030303132323537353130383238 172.16.33.103:any 172.16.34.100:any (tmm: 1)

universal 00000009012b617569742d73657373696f6e2d693d30413330323736303030303132323537353130383239 172.16.33.103:any 172.16.34.101:any (tmm: 1)

Total records returned: 2

(只要那些条目存在)，并且与同一个模式的所有后续的流量重定向到同一个ISE服务器。

LTM版本更改

请注意没有建议再使用CLIENT_DATA添加持续时间规则。从版本9.4开始应该使用CLIENT_ACCEPTED ：

UDP虚拟服务器的事件

并且RADIUS属性的更加简单的访问允许。示例：

when CLIENT_ACCEPTED {

set framed_ip [RADIUS::avp 8 ip4]

set calling [RADIUS::avp 31 \"string\"]

persist add uie $framed_ip 1800

persist add uie $calling 1800

}

文档陈述使用RADIUS配置文件是必要的，但是在版本11.6工作，即使虚拟服务器的(VS) RADIUS配置文件设置对无。

HTTP负载均衡

典型地没有需要装载CWA和其他访客流的平衡HTTP数据流。访客的重定向直接地对特定节点，不用需要使用loadbalancer。

在手工访问的相反赞助商和设备门户能容易地被平衡。

请读更多在被参考的非常好文档：

HowTo ：思科和F5部署指南ISE负载均衡使用BIG-IP

当CWA +其他访客流也许要求HTTP负载均衡，但是有方案。第三方集成是这样方案。原因是会配置

与静态重定向指向同样VS (FQDN)的每纳季。访客流负载均衡是有唯一的解决方案在这样方案的高可用性。与那的挑战亲切重定向是匹配与核算的RADIUS验证与HTTP会话和确保他们同样PSN的所有地产。

达到两VS创建。一HTTP的，一个Radius的(验证和核算)。而不是古典持续时间会话使用概念。

请注意它是需要被平衡的HTTPS流量(卸载的SSL)并且它是HTTPS流量需要到达PSN (节点)。卸载配置的SSL在下一部分被提交。

• 一旦RADIUS验证(Access-Request)开始Radius VS的iRule是检查执行的会话的查找是否有该呼叫

站点Id属性的持续时间。如果不新条目创建。如果旧有条目使用是。

• 对于所有随后的RADIUS信息包重新使用现有项-结果我们重定向对同一个节点。

• 在终端是指定的IP地址Radius后有framed-ip-address的临时核算数据包发送，条目的这次另外的

会话(基于framed-ip-address)是创建的重定向对同一个节点为RADIUS流量已经选择

• 一旦HTTP数据流接收HTTP VS的iRule是根据来源ip的执行的会话查找。上次会话

(framed-ip-address)匹配和同一个节点选择

Radius VS的iRule代码：

# adding persistence based on Calling-Station-ID

when LB_SELECTED {

log local0. \"session table entry added: \"

session add uie \"persist:[RADIUS::avp 31]\" [LB::server addr]

}

# lookup and adding persistence based on Framed-IP-Addr

when CLIENT_ACCEPTED {

log local0. \"session table lookup result for calling station ID of [RADIUS::avp 31]: [session lookup uie \"persist:[RADIUS::avp 31]\"]\"

if {[session lookup uie \"persist:[RADIUS::avp 31]\"] ne \"\

log local0. \"lookup match: [session lookup uie \"persist:[RADIUS::avp 31]\"]\"

node [session lookup uie \"persist:[RADIUS::avp 31]\"]

log local0. \"session table entry added: \"

session add uie \"persist:[RADIUS::avp 8]\" [session lookup uie \"persist:[RADIUS::avp 31]\"]

}

HTTP VS的iRule代码：

#lookup based on client_addr expecting to match entry created based on Framed-IP-Addr

when HTTP_REQUEST {

log local0. \"session table lookup result for web client of [IP::client_addr]: [session lookup uie \"persist:[IP::client_addr]\"]\"

if {[session lookup uie \"persist:[IP::client_addr]\"] ne \"\

node [session lookup uie \"persist:[IP::client_addr]\"]

}

验证流发送与呼叫站点Id 11:11:11:11:11:17的一测验Access-Request到Radius VS ：

# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s cisco -ai 11:11:11:11:11:17 -n 1

结果在LTM的/var/log/ltm将记录那里是该呼叫站点Id的没有条目，并且，一旦负载均衡决策做重定向对节点172.16.34.101的新建的条目创建。

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:17:

Rule /Common/radius : session table entry added: 所有随后的RADIUS信息包重定向对该节点。在该阶段(在客户端通过DHCP得到地址)后， framed-ip-address传送：

# ./radiustest.py -d 172.16.33.103 -u cisco -p Krakow123 -s cisco -fi 172.16.33.1 -ai 11:11:11:11:11:17 -n 1

LTM将记录根据正确节点选择的呼叫站点Id的那(172.16.34.101) -，而且个新会话条目根据framed-ip-address创建(172.16.33.1)。同一个节点(172.16.34.101)为该条目选择。

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:17: 172.16.34.101

Rule /Common/radius : lookup match: 172.16.34.101

Rule /Common/radius : session table entry added:

在此阶段从IP地址172.16.33.1的任何HTTP GET请求：

# curl -k https://172.16.33.103:8443

触发在LTM的以下结果(流量重定向对一个匹配的节点：172.16.34.101) ：

Rule /Common/http : session table lookup result for web client of 172.16.33.1: 172.16.34.101

同一个终端的这样Radius和HTTP数据流总是重定向对同一个节点。

现有项每请求刷新会话条目。

默认会话条目计时器是60s。

如果在此阶段新建的呼叫站点Id出现一切是由临时开始。若需要并且新建的条目能改写旧有一个。从LTM的示例日志：

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:18:

Rule /Common/radius : session table entry added:

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:18: 172.16.34.100

Rule /Common/radius : lookup match: 172.16.34.100

Rule /Common/radius : session table entry added: 172.16.34.100>

Rule /Common/radius : session table entry added:

Rule /Common/http : session table lookup result for web client of 172.16.33.1: 172.16.34.100

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:19:

Rule /Common/radius : session table entry added:

Rule /Common/radius : session table lookup result for calling station ID of 11:11:11:11:11:20:

Rule /Common/radius : session table entry added: node 172.16.34.101>

Rule /Common/http : session table lookup result for web client of 172.16.33.1: 172.16.34.100

请注意最后HTTP数据流仍然去节点172.16.34.100，因为没有framed-ip-address传送与呼叫站点Id值11:11:11:11:11:19亦不11:11:11:11:11:20。

SSL卸载

这是为HTTPS流量负载均衡要求的典型配置。以下屏幕画面被提交正参考，为了更多文档请参考正式F5指南。

用于的CA证书签署PSN (和VS)导入对委托存储：

终止HTTPS会话的VS的证书生成，上传的密钥和cert。服务名称是vip.example.com

(将静态配置作为在所有NAD的重定向) ：

SSL客户端配置文件创建， VS证书，并且密钥被参考。此配置文件对从客户端的SSL终端将负责。

并且SSL服务器配置文件需要创建-与默认设置(解密的SSL流量再将加密，当到达PSN)时。若需要服务器证书忽略选项可以设置到真：

HTTP的VS创建(所有TCP端口和有启用的HTTP配置文件的) ：

并且两SSL配置文件在高级配置里被参考：

重定向和SSL卸载可以从客户端测试：

# curl -k -i

https://vip.example.com:8443/portal/gateway?sessionId=ac101f1400016000566dd7c4&portal=27963fb0-e96e-11e4-a30a-005056bf01c9&action=cwa&token=313cae956bd3f60f7a8531bbc019e8

LTM将生成一本正确“匹配查找”日志，并且正确PSN节点的数据包捕获将确认正确重定向。

CWA流平衡在F5优良工作。

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文