ClearPass – dual interface and routing

When you are using both interfaces on a ClearPass server (MGMT and DATA) than ClearPass uses the DATA interface to connect to services, like LDAPS to Active Directory, SMTP delivery, Active Directory joining and more. ClearPass uses the DATA interface as default gateway if no specific route is available on the MGMT interface.

That being said, you have the option to add routes to the ClearPass routing table. Routes are added via the ClearPass shell. Use the following command to add a route.

Usage:

network ip add <mgmt|data|greN|vlanN> [-i <id>] <[-s <SrcAddr>] [-d <DestAddr>]> [-g <ViaAddr>]

Where:

  • greN — Name of the gre tunnel where N corresponds to the gre
    tunnel number ranging from 1,2,3…N
  • vlanN — Vlan interface where N corresponds to the vlan id ranging from 1,2,3…N. For example if the configured vlan identifier is ’85’ then input ‘vlan85’
  • -i — Optional parameter. Id of the network ip rule. If unspecified the system will auto generate the Id
  • -s <SrcAddr> — Optional parameter. The source interface ip address or netmask from where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -d <DestAddr> — Optional parameter. The destination interface ip address or netmask where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -g <ViaAddr> — Optional parameter. The via or gateway ip address through which the network traffic should flow. The allowed value is valid IP Address

An example:

[appadmin@CPPM01]# network ip add mgmt -d 10.10.10.0/24 -g 20.20.20.1
INFO – Added route for destination=10.10.10.0/24 via=20.20.20.1
INFO – New ip rule created with the id = 12000

You can check the routing table via the command: network ip list.

XS4ALL, Cisco 877 and IPv6

A while ago my ISP XS4ALL started with the distribution of IPv6 prefixes to their customers. So as a network engineer I wanted to have my own /48 prefix. Sadly I didn’t had time to start testing at the beginning of the IPv6 “launch”.

Last week I found some time to start my testing. I started by configuring my external DSL interface to run in dual-stack mode. The IPv4 configuration is straightforward and isn’t part of this article.

Below you see the basic configuration of the Dialer interface to enable IPv6. The commands configure the Dialer interface as DHCP client (autoconfiguration on the interface) and the prefix delegation name is “my_prefix”.

interface Dialer1
ipv6 address autoconfig
ipv6 enable
ipv6 dhcp client pd my_prefix rapid-commit
end

You can check the allocation of the IPv6 address prefix with the following command:

C877W#show ipv6 general-prefix
IPv6 Prefix prefix_ipv6, acquired via DHCP PD
2001:980:3441::/48 Valid lifetime , preferred lifetime
BVI1 (Address command)

More information about the allocation can also be obtained with the following command:

C877W#show ipv6 dhcp interface
Dialer1 is in client mode
State is OPEN
Renew will be sent in 00:11:48
List of known servers:
Reachable via address: FE80::90:1A00:1A1:88E6
DUID: 000200000A4C453332302F373435414333334558322F01
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00100001, T1 3600, T2 5760
Prefix: 2001:980:3441::/48
preferred lifetime 7200, valid lifetime 7200
expires at Jan 31 2011 12:24 PM (4310 seconds)
DNS server: 2001:888:0:6::66
DNS server: 2001:888:0:9::99
Information refresh time: 0
Prefix name: my_prefix
Rapid-Commit: enabled

Now you need to configure IPv6 routing, especially the default route and enabling unicast-routing, with the following commands:

ipv6 unicast-routing
ipv6 route ::/0 Dialer1

The next step involves the configuration of the LAN interface to support IPv6. RFC 3177 recommends the delegation of /48 prefixes to home network subscribers, small and large organizations. It looks like my ISP follows that recommendation. The same RFC states that a /64 prefix should be assigned to different host subnets. So I can configure 2^16 host subnets and each subnet can contain 2^64 IPv6 addresses. Seems enough for my home environment.

The inside interface (a Bridged Virtual Interface in my scenario) is configured with the following /64 prefix.

ipv6 address my_prefix 0:0:0:1::/64 eui-64

You can use the following command to look at the IPv6 configuration of the different interfaces.

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1::FFFF
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684

The basic IPv6 configuration is done. The next step is testing IPv6 connectivity via an IPv6 ping to ipv6.google.com

C877W#ping ipv6 2a00:1450:8005::68 source bvi1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A00:1450:8005::68, timeout is 2 seconds:
Packet sent with a source address of 2001:980:3441:1::FFFF
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms

Ping can reply with different characters. The characters are listed below.

! Each exclamation point indicates receipt of a reply
. Each period indicates that the network server timed out while waiting for a reply
? Unknown error
@ Unreachable for unknown reason
A Administratively unreachable. Usually, this output indicates that an access list is blocking traffic
B Packet too big
H Host unreachable
N Network unreachable (beyond scope)
P Port unreachable
R Parameter problem
T Time exceeded
U No route to host

Prefix Delegation (PD) in IPv6 is very useful when deploying IPv6 in the network. The deployment of IPv6 to hosts also involves the distribution of additional parameters, like IPv6 DNS servers. The next step involves the configuration of Router Advertisement (RA) messages on the Bridged Virtual Interface.

I configured an DHCPv6 pool and configured the BVI interface as DHCP server interface with the following commands:

ipv6 dhcp pool ipv6_inside
dns-server 2001:888:0:6::66
domain-name booches.nl
!
interface BVI1
ipv6 address my_prefix 0:0:0:1::/64 eui-64
ipv6 nd other-config-flag
ipv6 dhcp server ipv6_inside rapid-commit
end

The other-config-flag sets the O-bit in IPv6 RA messages to inform hosts that they can use autoconfiguration for their IPv6 configuration. This results in DHCPv6 INFORMATION-REQUEST messages from the hosts to the DHCPv6 server. The router will reply to these message, because it is configured as DHCP server for the prefix.

I started testing, but my hosts didn’t receive any IPv6 address and debugging IPv6 on the router didn’t output any useful information. Of course the hosts couldn’t receive any IPv6 address, because of the well-known bug CSCej50923 (CCO ID required) on BVI interface routing, which does not work for IPv6 addressing. I didn’t want to upgrade my router directly, so I created another VLAN with the appropriate Switched Virtual Interface. I configured the same commands as under the BVI interface, but this time with prefix 0:0:0:2::/64. Now I have 3 interfaces enabled for IPv6 addressing, like shown below:

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1:21A:6DFF:FE7D:B684
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684
Vlan2                      [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:2:21A:6DFF:FE7D:B684

You can see the difference in the prefix between BVI1 and Vlan2. I issued a ipconfig /release6 and ipconfig /renew6 on the hosts and IPv6 is working like a perfectly.

The complete output of the ipconfig /all and a ping to ipv6.google.com can be found below.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : booches.nl
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : 00-25-64-F6-1C-D7
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:980:3441:2:c527:8966:a47f:55d2(Preferred)
Temporary IPv6 Address. . . . . . : 2001:980:3441:2:cd4d:b38b:e861:f43(Preferred)
Link-local IPv6 Address . . . . . : fe80::c527:8966:a47f:55d2%11(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.2.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, January 31, 2011 4:02:01 PM
Lease Expires . . . . . . . . . . : Thursday, February 03, 2011 4:02:00 PM
Default Gateway . . . . . . . . . : fe80::21a:6dff:fe7d:b684%11
10.10.2.1
DHCP Server . . . . . . . . . . . : 10.10.2.1
DHCPv6 IAID . . . . . . . . . . . : 234890596
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-65-AE-74-00-25-64-F6-1C-D7

DNS Servers . . . . . . . . . . . : 2001:888:0:6::66
10.10.2.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
booches.nl

C:\Users\RJN>ping ipv6.google.com

Pinging ipv6.l.google.com [2a00:1450:8005::68] with 32 bytes of data:
Reply from 2a00:1450:8005::68: time=29ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=26ms

Ping statistics for 2a00:1450:8005::68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 28ms, Average = 26ms

Policy-based routing in a nutshell

Lately I received some questions about routing decisions and how to influence the routing decisions via access control lists. The following example shows a simple configuration for policy-based routing. The example uses the following logical setup:

simple-pbrI configured two routers and connected each router to two PVC’s on the same ATM interface. I configured one subnet per location. All normal traffic is router through PVC #1, but all traffic to or from the servers in the picture should be routed to PVC #2.

The top router has SVI VLAN 1 configured to connected to the inside LAN. The first step in configuring policy-based routing is defining which traffic should be routed over PVC #2. I configured the following access-list.

ip access-list extended acl-pbr
permit ip 10.10.10.0 0.0.0.255 host 192.168.1.100
permit ip host 192.168.1.100 10.10.10.0 0.0.0.255

Next you need to configure a route-map with a “match” statement and configure the appropriate “set” conditions.

route-map rm-pbr permit 10
match ip address acl-pbr
set ip next-hop <PVC #2 IP address>

The last step is applying the configured route-map to the correct interface. As stated before, we are using SVI VLAN 1.

interface Vlan1
ip address 10.10.10.254 255.255.255.0
ip policy route-map rm-pbr

As you can see, configuring policy-based routing is very simple, and yet very powerful.

One issue is when testing policy-based routing from the router. By default, locally-generated packets are not inspected by outgoing access-lists. To enable local packets from being re-entered into the router, you should issue the ip local policy route-map <rm-name>.

HSRP and ACL’s

I added a Guest VLAN to a network environment with two multi layer switches running HSRP. To secure the internal network from the Guest VLAN, I added a ACL to the Guest VLAN SVI. The ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any
remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The ACL allows querying the DHCP server to obtain the necessary IP address. Next the ACL denies access to all RFC 1918 IP addresses, which are used on the internal LAN segment of the customer. The last two statements allow HTTP and HTTPS access to the Internet.

At first, I just applied the ACL to both the multi layer switches and thought I was ready. After configuring some other tasks and finishing my work, I always check the configuration. Looking at the show standby brief output, I noticed that the primary HSRP switch didn’t have any standby switch anymore, as show in the output below:

Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl1            1    200 P Active    local         10.1.0.3          10.1.0.1
Vl2            2    200 P Active    local         unknown         10.1.2.1

Because the only change was applying the ACL to the SVI, I already know where to search to correct the problem. Adding a deny ip any any log statement at the bottom of the ACL gave me the information I needed to know.

05:48:09.366: %SEC-6-IPACCESSLOGP: list GUEST-DENY-RFC1918 denied udp 10.1.2.2(1985) -> 224.0.0.2(1985), 360 packetsde

The ACL is blocking the multicast HSRP packets. Looking at the log output, you can see that the HSRP multicast IP address is 224.0.0.2 and port UDP/1985 is used. The multi layer switch is using his SVI IP address as source in the HSRP packet.

I changed the ACL on both multi layer switches by adding a statement to allow the HSRP packets. The new ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any

remark Allow HSRP PACKETS

permit udp host 10.1.2.[2|3] eq 1985 host 224.0.0.2 eq 1985

remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The HSRP packets weren’t blocked anymore after applying the new ACL to the SVI’s. The primary multi layer switch got his secondary switch back.

Applying an ACL to a SVI happens more often, so it is important to remember if you are running some sort of special protocol on the SVI or somewhere else in the configuration when applying an ACL.

Looking at the Internet I found a nice article on Aaron’s Worthless Words blog about multicast addresses, port numbers and associated protocols.

Policy-Based Routing Catalyst 3560

Today I visited a customer where the power a Cisco Catalyst 3548XL blew up. The switch had a manufacture date of December 2000. It is an old one, but still I haven’t seen a power supply being blown up from a Cisco switch from that age.

But oké, the switch needed to be replaced. The customer ordered some 3560 switches, so all the 3548 switches could be replaced. The customer was also using a Cisco 2650XL router for routing between the different VLAN’s. Because they purchased some layer 3 switches, I also wanted to remove the Cisco 2650XL router.

The configuration of the router wasn’t that spectacular, there was only some policy-based routing (PBR) configured. The switches had IP base images, so I had to upgrade one switch with IP services firmware. After upgrading the switch, I configured the ACL and route-map as listed below.

ip access-list extended ACL-PBR
permit ip 10.10.10.0 0.0.0.255 any

!

route-map RM-PBR permit 10
match ip address ACL-PBR
set ip default next-hop 10.10.10.253

Next I wanted to apply the route-map to the correct interface, but that resultant in the following syslog message.

%PLATFORM_PBR-4-SDM_MISMATCH: PBR requires sdm template routing

Looking at the internet for a PBR example on a Cisco Catalyst 3560, I found that I had to change the SDM (Switch Database Management) template. The SDM manages the layer 2 and layer 3 switching information that is maintained in the Ternary Content Addressable Memory (TCAM). The TCAM is used for forwarding lookups.

Looking at the default configuration the switch had the following SDM configuration.

SW01-L3(config)#do sh sdm prefer
The current template is “desktop default” 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:                  6K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    8K
number of directly-connected IPv4 hosts:        6K
number of indirect IPv4 routes:                 2K
number of IPv4 policy based routing aces:         0
number of IPv4/MAC qos aces:                      0.75K
number of IPv4/MAC security aces:                 1K

Looking at the output, there is no memory configured for IPv4 policy based routing aces. This means that I have to change the SDM template to routing. This is achieved be entering the global configuration command:

sdm prefer routing

The execution of the command requires a switch reboot. After the reboot I checked the SDM configuration and noticed that memory is allocated for PBR, like displayed below:

SW01-L3(config)#do sh sdm prefer
The current template is “desktop routing” template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

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

So I try to apply the route-map to the specific interface, but this resulted in another syslog message.

%PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map RM-PBR not supported for Policy-Based Routing

Seems that the PBR configuration is not supported on the switch. At least some commands are not supported. Checking the internet again, I found a document with Unsupported Route Map Commands for a Catalyst 3550.

I had to change the next-hop configuration. I replaced the route-map with the following commands.

route-map RM-PBR permit 10
match ip address ACL-PBR
set ip next-hop 10.10.10.253

Finally, after changing the route-map it could be applied to the interface. After replacing the components I tested the route-map and it is working without any problems.