If your AD contains more than 1000 groups, you will need to manually enter the AD group name in the drop down box.
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
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.
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.
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
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
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.
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.
Subscribe to:
Posts (Atom)