Tuesday, September 21, 2010

Cisco NAC guest server AD sponsor group mapping

NAC Guest Server 2.0.2 will map Sponsor User Groups to users located anywhere in AD. The Guest Server just checks the memberOf attribute of the user contained by the group name.

If your AD contains more than 1000 groups, you will need to manually enter the AD group name in the drop down box.

Monday, September 13, 2010

MS VPN Connection options grayed out

When attempting to create a new Microsoft VPN connection on MS XP Pro, I found the radio button options to select between Dial-up connection and Virtual Private Network connection are grayed out and the Next > button not available.

I found I needed to start the Remote Access Connection Manager service (previously disabled) to allow for configuration.

Friday, September 03, 2010

Translation Rules in IOS gateways

Some quick notes stolen from http://cciev.wordpress.com/2006/06/10/translation-rules-and-profiles/:

voice translation-rule 1
rule 1 /123/ /456/
rule 2 /^123/ /456/
rule 3 /^123$/ /456/
rule 4 /.*/ /456/
rule 5 /^123*/ /456/
rule 6 /^123+/ /456/
rule 7 /^123?/ /456/
rule 8 /^$/ /456/

a. rule 1 is a one to one replacement of any occurence of 123 in the source number with 456.
b. rule 2 replaces any number starting with 123 with a 456.
c. rule 3 replaces only the number 123 as the source number with 456.
d. rule 4 replaces any number with the number 456, including null.
e. rule 5 says any number that starts with 12 and has 0 or more occurence of 3 with 456.
f. rule 6 says any number that starts with 12 and has 1 or more occurence of 3 with 456
g. rule 7 says any number that starts with 12 and has 0 or 1 occurence of 3 with 456.
h. rule 8 says any number with no input digits (empty ani for example) with 456.

Misc items:
A. dot means a single digit.
B. [0-9] specifies a range
C. .* means any digit followed by zero or more occurence, virtually any digit including null
D. .+ means any digit followed by one or more occurence, virtually any digit excluding null
E. ^$ means no digits.
F. () groups digits into sets

Sunday, August 22, 2010

CSIM START call simulator

CSIM START is a badly, if not undocumented Cisco IOS command that allows you to generate a voice call from a voice enabled router. It seems even if buggy, it could be really useful in situations where you are configuring or supporting configurations remotely and / or don't have live users to test configurations for you.

I have used it successfully with version 124-24.T3 with loop start analog POTS lines, but have seen demonstrations with older versions over PRI as well.

It seems that csim always returns a failed=1 code despite calls being made correctly.

I have found debug voip ccapi inout reflects the call generated by csim accurately.

A successful call looks like:

router#csim start 917167994818
csim: called number = 917167994818, loop count = 1 ping count = 0
csim err csimDisconnected recvd DISC cid(21)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

A call to a number without a dial-peer match looks like:

router#csim start 917167994818
csim: called number = 089151, loop count = 1 ping count = 0

csim err:csim_do_test Error peer not found

Thursday, August 19, 2010

qos pre-classify

Absolutely elegant discussion of qos pre-classify at href="http://packetlife.net/blog/2009/jun/17/qos-pre-classification.

I'm reposting it below (with crappy formatting) simply as a backup. Please give credit where credit is due.

QoS pre-classification

By stretch | Wednesday, June 17, 2009 at 10:37 a.m. UTC

Implementing quality of service provisions on virtual tunnel interfaces (VTIs) poses a challenge: QoS policy enforcement is normally applied only after tunnel encapsulation has taken place. Consider the following service policy applied to a GRE tunnel:

class-map match-all ICMP
match access-group name MATCH_ICMP
class-map match-all GRE
match access-group name MATCH_GRE
!
!
policy-map MyPolicy
class ICMP
class GRE
!
interface Tunnel0
ip address 192.168.0.1 255.255.255.252
tunnel source 10.0.0.1
tunnel destination 10.0.0.2
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
service-policy output MyPolicy
!
ip access-list extended MATCH_GRE
permit gre any any
ip access-list extended MATCH_ICMP
permit icmp any any

(Note that the policy map used as an example here does not actually enforce any policy; its class maps are included simply to illustrate the manner in which packets are being matched.)

In default operation, our QoS policy will be applied to packets exiting the physical interface only after they have undergone tunnel encapsulation.

When we generate ICMP traffic to the far end of the tunnel, we can verify that our policy only matches the packets as GRE traffic:

R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 8/10/24 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: protocol icmp

Class-map: GRE (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: protocol gre

Class-map: class-default (match-any)
5 packets, 620 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

This hinders our ability to differentiate between packets which have undergone tunnel encapsulation. However, enabling QoS pre-classification configures the tunnel interface to maintain a copy of the original packet in memory long enough for the physical interface policy to inspect it.

After enabling pre-classification, our policy is applied to the original "inner" header instead of the encapsulation header:

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface tunnel0
R1(config-if)# qos pre-classify
R1(config-if)# ^Z
R1# clear counters f0/0
Clear "show interface" counters on this interface [confirm]
R1# ping 192.168.0.2 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/8/12 ms
R1# show policy-map interface f0/0
FastEthernet0/0

Service-policy output: MyPolicy

Class-map: ICMP (match-all)
10 packets, 1240 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_ICMP

Class-map: GRE (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: access-group name MATCH_GRE

Class-map: class-default (match-any)
2 packets, 120 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
A couple side notes from my experiments on IOS 12.4(22)T:

I initially wrote the class maps to utilize NBAR (match protocol), but for some reason the ICMP class map didn't appear to take effect, so I switched to extended ACLs. Your mileage may vary.

Pre-classification seems to have no effect when applied to a VTI performing native IPsec encapsulation (versus a crypto map). Again, this may be IOS version-specific.