Nov
23

UPDATE: We Have a Winner!

Congratulations to Fredy and Antonis for both answering the question correctly.
Because we only had 2 answers to this contest (and it's the second time we've run it), and they were both correct, as well as both having gone above and beyond the requirements to answer the basic question/problem, but adding additional correct and excellent configurations and annotations -- we are awarding each of them the same prize!

At a most basic level, the problem with my configuration was that you cannot used an AS Numbered Instance of EIGRP at the top level to configure SAF (Service Advertisement Framework). Yes, EIGRP does have to have an AS#, but that must come within an EIGRP Virtual Instance Named (VIN)!

They both went above and beyond by pointing out many other great points that are well worth reading.

Congratulations to both of you, and look for my email in relation to your prizes!
By the way, since this is such a cool new technology that holds so much potential for real world production environments, I will do a follow-up blog post outlining the basics and some advanced topics surrounding CCD and SAF. Look for that here, soon.

 

Original Trivia Challenge Below

Time for another INE CCNP Voice Trivia Contest. This week we will start early and give you until Monday 28 November to choose a winner, giving you a bit over four days to come up with the correct responses.

This is actually a re-post of an earlier contest --one containing knowledge that every CCNP Voice engineer must know to pass the CIPT2 (642-457) exam-- that never met with a correct answer in the previous run. I have recorded around 4.5 hours of material on just this topic beginning here in this video, so take a look at these videos over the next few days, and see if you can sort out the answer.

Here is the problem that needs solving for this week's Voice Trivia Contest:

There are three sites, two site running separate CUCM clusters and one site running an instance of CME on that sites only router. The two sites running CUCM clusters each have their own SAF Forwarder router, and those two routers have been configured and are working properly exchanging primary DNs as well as alias prefix routes between them, and each CUCM cluster can dial the other CUCM cluster using the dynamically exchanged 4 digit DN. However, the CME site's router seems to not have its SAF Forwarder portion configured properly (assume everything else in the router IS configured properly and working), and is not yet receiving or publishing any primary DN or alias prefix routes. Once that problem is resolved, it is also desired that the two CUCM clusters be able to receive the backup PSTN alias prefix routes natively as + (plus) patterns, so that they may use their existing globalized plus dialing patterns (PSTN translation patterns), along with their existing (working) AAR CSS as the patterns for reaching the remote CME site if/when it falls into SRST mode.

So your tasks for this week's trivia contest are these:

  1. Looking at the code just below these tasks (which is the CCD/SAF portion of the CME site's router), copy and paste it into your proposed solution in the comments area below, fixing the parts of the code that are incorrect.
    • I should add a few 'known' attributes to the equation:
    • SIP over TCP 5060 is the correct signaling protocol, transport and port #
    • The other two sites' SAF Forwarders are adjacent, established neighbors on EIGRP AS 1
  2. Provide a configuration solution for how you will allow both CUCM clusters the ability to receive the CME advertised alias prefix routes with a + (plus) prefix, so that they may use their existing globalized patterns for matched routing. You may do this by providing a short sentence/paragraph with what you would do to provide for this, or you may update the below configuration if you believe you are able to fix it there in the CME site's router config.

!
router eigrp 1
!
service-family ipv4 autonomous-system 1
!
sf-interface Loopback0
no split-horizon
exit-sf-interface
!
exit-service-family
!
!
voice service saf
!
profile trunk-route 1
session protocol sip interface Loopback0 transport tcp port 5060
!
profile dn-block 1 alias-prefix 3120703
pattern 1 type extension 6XXX
!
profile callcontrol 1
dn-service name Branch2-CME
trunk-route 1
dn-block 1
!
!
channel 1 vrouter VO_SAF_R3 asystem 1
subscribe callcontrol wildcarded
publish callcontrol 1
!
!


As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is 6.5 Voice rack sessions!)
  • $100USD worth of INE.com online store credit

The rules for this contest are as follows:

  • You must answer any/all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer)
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat' if you will
  • We will not allow any of the response comments to be posted here on this blog post (publicly) until the contest is over, so as not to give an unfair advantage to anyone

I'll be watching the submissions over the next few days, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments along with some of with my own replies and comments, and of course, the correct solution.

Good Luck!
Mark

Sep
13

Time for another INE Voice Trivia Contest. This week we will wait until Friday morning to choose a winner, giving you all a few days to come up with correct responses.

Here is the problem that needs solving for this week's Voice Trivia Contest:

Integration with an corporate LDAP has been properly setup and many users have been imported into the CUCM server, but now it has been requested that an LDAP Custom Filter be built in order to limit the imported users down to only a few.

The base LDAP schema is that there is an OU called "island natural exports" in the domain of "ine.com".

The only desired users to remain imported are:

  • A user with the last name of "Linus"

OR

  • All users who are in the department of "executives" that also have a manager whose canonical name is "Hugo Reyes"

So your task for this week's trivia contest is quite simply to post the proper RFC 4515 compliant LDAP custom filter query string in the comments section below.


As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is 6.5 Voice rack sessions!)
  • $100USD worth of INE.com online store credit

The rules for this contest are as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer)
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat' if you will
  • We will not allow any of the response comments to be posted here on this blog post (publicly) until the contest is over, so as not to give an unfair advantage to anyone

I'll be watching the submissions over the next few days, and I will return on Friday to gather up the winners, choose a random name, and post all of the comments along with some of with my own replies and comments, and of course, the correct solution.

Good Luck!
Mark

We Have a Winner

OK, so first off I should note that I probably should have been just a bit more specific than to say that I only wanted "the proper RFC 4515 compliant LDAP custom filter query string", and if I were to do it over I would change that to say something more like "a single LDAP custom filter query string that works to return actual results against a Microsoft Active Directory LDAP in the CUCM Custom Filter web page, and will also work if using the Microsoft 'Find Custom Search - Advanced tab' in any AD-attached PC where it says 'Enter LADP Query'".

That being said - all of the solutions seem to be RFC 4515 compliant, and so I included them all in my online randomizer when picking the winner.

So first off, we had some very detailed answers - I am impressed! They, of course, can be seen in the comments below. While I definitely agree that one could benefit by filtering out only the import of ObjectClass=user and possibly even UserAccountControl, CUCM will only import the ObjectClass of users anyhow, so we can omit that step when dealing with this in relation to the CUCM filter string. And Dave, while I was not more specific in saying that you couldn't create more LDAP Directory entries in CUCM and have multiple Filters (which is why I included you in the drawing), I want to point out that you can do the query in a single line.

So here is my simplified (and working) official answer:


(|(sn=linus)(&(department=executives)(manager=cn=Hugo Reyes,ou=executives,ou=island natural exports,dc=ine,dc=com)))


See this screenshot below of the query returning results in the DC's "Find Custom Search --> Advanced --> LDAP Query" window:

So after I entered all three names in my online randomizer, it told me that Kevin Dierckx is our winner! Kevin will be receiving his choice from the above prizes.

Congratulations Kevin!

I would like to point out that we never had a winner for a contest that I held for this contest: CCNP Voice Trivia Contest :: CCD Dynamic Routing of DNs, so I will be publishing it again in the not-too-distant future. So have a look at it now, and see what you might be able to see to have a leg-up on the competition. Heck, it could win you $100!

BTW, as a bit of a spoiler for that, I cover exactly that scenario (along with many others) in the ~5 hours of videos that I recorded on that topic of SAF and Call Control Discovery, which can be found in these 6 videos:
Call Control Discovery (CCD) via Service Advertisement Framework (SAF) Overview
Call Control Discovery via SAF - CUCM Inter-Cluster Call Routing
Call Control Discovery via SAF - CUCM Call Routing with PSTN Failover
Call Control Discovery via SAF - CUCM Call Routing during SRST Fallback
Call Control Discovery via SAF - CUCM to CME Call Routing
Call Control Discovery via SAF - Inter-Cluster RSVP via SIP Preconditions

Mar
24

I am running this week's Voice Trivia Contest a bit early (launching it on Thursday instead of Friday) to try to give more people a chance to win that might not otherwise see this over the weekend, however we will still end the contest on Monday morning, as usual.

Here are the facts for this week's Voice Trivia Contest:

  • Tobias has a phone on which he needs to be able to have two BLF SD buttons that accurately show the presence status of Gob, Buster and Lindsay's primary DNs. This needs to include status updates for when either Gob or Lindsay's primary DN is ringing, but not when Buster's primary DN rings.
  • Gob, Buster and Lindsay's primary DNs are all in the same Partition.
  • Tobias has a SUBSCRIBE Calling Search Space that contains that Partition all three phones' primary DNs are in.
  • Tobias also needs to be able to view Call Lists (Missed Calls, Corporate Directory, etc.), but when he views them, he should only see the BLF status change for Lindsay's DN, and not for Gob or Buster's DNs.
  • To aid in that, two Presence Groups have been setup. One for Tobias and Lindsay which have been assigned to both their Phone devices and their Lines. One for Gob and Buster, which have been assigned to both their Phone devices and their Lines. The Presence Groups both explicitly have Disallow Subscription to each other's group reciprocally.
  • All is good with Tobias's BLF SDs on his phone display, and he can see all of their status changes appropriately - including seeing when Gob or Lindsay's DNs ring, but not Buster's.
  • However, there is an issue. When he pulls up the Corporate Directory and searches for everyone, he sees BLF status updates for both Lindsay and Gob, but not for Buster. Remember that he should not see Gob's BLF status updates either.

So, your contest question for this weekend is this: What could the problem be that is causing Tobias to be able to see Gob's (but not Buster's) status in BLF Call Lists, when he shouldn't be able to see either of them?

As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is 6.5 Voice rack sessions!)
  • $100USD worth of INE.com online store credit - which goes perfectly as a complement to your checkout cart containing INE's all new All Access Pass!

The way we will hold the contest is as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer)
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • Simply so that we may give a wide range of people chances to win these contests, we have decided that if you have won a previous Voice trivia contest here on this blog, you will only be eligible to be chosen as this contest winner if you happen to have submitted the only correct answer (so try and answer anyway!)

I'll be watching them over the next few days, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments along with some of with my own replies and comments, and of course, the correct solution.

Good Luck!
Mark



Update: We have a winner!

Congratulations Hristos!

Hristos correctly identified that when a user has a Unified Mobility (SNR) shared line, that user will be the exception from the Presence Group properly working. In fact, depending on the restart iteration, the results can be a but undeterministic.

This was specifically demonstrated in one of our four new Voice Deep Dive modules - Unified Presence.

Feb
25

Austin has devised a dial plan that meets the needs of his company (Backyard Adventures, Inc), and one of the core components of it meets a requirement set forth by his company's executive branch - namely, that although people in U.S. offices of his company dial a '9' as a PSTN access code prior to dialing any additional digits for outside public calls, the executive branch dictates that they do not want the IP phones that dialed such a number to see that preliminary '9' on the phone's display, once the call has been placed.
(e.g. If Pablo dialed 9-206-501-5111 for a local call in Seattle, then his display should only show 2065015111 once the call has been placed)

So Austin --knowing that by default, CUCM updates it's phones' Calling Displays at every digit manipulation step along the way that occurs while the call is still in control of CUCM-- decides to make sure that CUCM strips the '9' off of every egress gateway or trunk, before the call is sent onto the actual IOS device providing gateway services between itself and all of the company's PSTN PRI circuits. This actually meets two objectives of his: the first being the desired behavior just discussed, and the second being the execution of a uniform dial plan with regards to digit manipulation for egress gateways and Called Party Transformation Patterns - whether they be to MGCP gateways (where that '9' must be stripped prior to sending to the IOS device), or to H.323 or SIP GW/Trunks all the same.

Now something that he didn't count on was this: While he was in control of the CUCM and its dial plan, he has to work together with Tyrone who is in control of all the IOS devices, whether for routing or for voice services. Tyrone has informed Austin that all outbound dial peers pointing to the PSTN, begin with a '9' (and are displayed just below). Tyrone also informs Austin that it is fine if Austin sends the PSTN-bound calls to his (Tyrone's) IOS gateways without a '9', but just so that Austin is prepared, he will be reintroducing (prepending) all PSTN-bound calls with a '9' for any gateways that are controlled with the H.323 and/or SIP signaling protocols, so as to match the outbound dial peers - and that he will be doing that on the inbound VoIP dial peer from the CUCM, with Voice Translation Rules as follows:

OUTBOUND PSTN DIAL PEERS
!
dial-peer voice 10 pots
destination-pattern 911$
port 0/0/0:23
forward-digits 3
!
dial-peer voice 11 pots
destination-pattern 9[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 10
!
dial-peer voice 12 pots
destination-pattern 91[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 11
!
dial-peer voice 13 pots
destination-pattern 9011T
port 0/0/0:23
prefix 011
!
INBOUND CUCM DIAL PEER & VTR
!
voice translation-rule 9
rule 1 /^[2-9].........$/ /9&/
rule 2 /^1[2-9].........$/ /9&/
rule 3 /^011.*/ /9&/
!
voice translation-profile Prefix_9_DNIS
translate called 9
!
dial-peer voice 101 voip
translation-profile incoming Prefix_9_DNIS
incoming called-number .
voice-class codec 1
session protocol sipv2
dtmf-relay sip-kpml rtp-nte
!

Now Austin knows that both the H.323 and SIP signaling protocols will retroactively inform the CUCM of any changes to the Called Number, and while he tries to persuade Tyrone to change his method of prefixing the '9', he fails to do so.

So, your contest question for this weekend is this (and requires two separate answers, one for H.323 and different for SIP):

  • Given the above outbound dial peers for any H.323-to-PRI/PSTN and/or SIP-to-PRI/PSTN voice gateways in the Backyard Adventures' unified communications network, and given the fact that Tyrone will not be changing the Voice Translation Rules that he already has implemented on his gateways' inbound dial peers in any way: What configuration can Tyrone add to his H.323 & SIP IOS gateways (separately) to prevent the singaling protocol, and therefore CUCM, from reintroducing the '9' back into the Called Number display of users' such as Pablo's phones when they go to place a call?
  • For extra credit, include the best debug command to ensure that what you wish to happen to the Called Number, is indeed what is actually happening to it. The extra prize to go along with the extra credit answer is this: If you get it correct, you will know you are that much closer to answering exam questions properly for either the TVOICE v8 or the CCIE Voice Lab Troubleshooting tasks! ;-)

As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is just a bit more than 3 Voice rack sessions)
  • $100USD worth of INE.com online store credit - which goes perfectly as a complement to your checkout cart containing INE's all new All Access Pass!

The way we will hold the contest is as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • Also a new one: If you have won a previous contest, you will not be eligable to be in the drawing for this contest, that is unless you happen to be the only correct answer - in which case, we have to give it to someone, don't we? :)

I'll be watching them over the weekend, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments with my own replies and comments.

Again, we will be try to hold these sorts of contests bi-weekly, so check back often to increase your chance of winning!

P.S. Stay tuned at the beginning of next week as we announce an exciting new Non-VPN method of accessing all of our Voice Racks!

Good Luck!
Mark



Congratulations to Earl Hough, the winner of this contest!

As promised below in my comments, here is an updated post with the solution set:
For the H.323 Gateway:

voice service voip
no supplementary-service h225-notify cid-update

... and to verify, run:

debug cch323 h225

For the SIP Gateway:


voice class sip-profiles 1
response 183 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
!
dial-peer voice 101 voip
voice-class sip profiles 1

... and to verify, run:

debug ccsip info

When running the 'debug ccsip info', we see:


//1554/D0D02EC28E93/SIP/Info/sipSPISendInviteResponse: Associated container=0x4A1DBD58 to Invite Response 183
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header before modification : Remote-Party-ID: <sip:92065015111@177.1.254.1>;party=c
alled;screen=no;privacy=off
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header after modification : Remote-Party-ID: <sip:2065015111@177.1.254.1>;party=cal
Feb
04
Pablo is using his Cisco 7961 IP phone. He goes to look at his 'Missed Calls' and sees that he missed a call that had come in from a local PSTN number. The number in his missed call looked exactly like this:
<strong>+12065015111</strong>


He needs the ability to look at this missed call and simply press the 'Dial' softkey --and nothing more-- to return the call immediately - with no inter-digit timeout, and of course successful call routing back to the PSTN caller.


Pablo has the same CSS on his Line, as he does on his Phone Device - which is:
<strong>CSS_CorpHQ-LOCAL</strong>


And the CSS has in it, the Partition of:
CSS_CorpHQ-LOCAL

--> PT_CorpHQ-LOCAL


There is a Route Pattern that points straight to a gateway, that matches his desired return call:
Pattern: \+!

Partition: PT_CorpHQ-LOCAL

Urgent Priority: YES

Gateway: CorpHQ-MGCP-GW


And the MGCP Gateway has a Called Party Transformation CSS:
Gateway: CorpHQ-MGCP-GW

Outbound Called Party Transformation CSS: CSS_CdPTP-CorpHQ-GW


And the CSS with CSS has the PT:
CSS_CdPTP-CorpHQ-GW

--> PT_CdPTP-CorpHQ-GW


And the CdPTP to localize the call egress from the MGCP GW to the carrier (the carrier is expecting 10 DNIS digits) is:
Called Party Transformation Pattern: \+1.206!

Partition: PT_CorpHQ-LOCAL

Urgent Priority: YES!

Discard: PreDot


So as you can see, the call should be returned to the PSTN with no issues.


So Pablo looks at that missed call, and goes to press 'Dial'. No sooner than he has pressed it, his display quickly pulses out the digits '+12065015111' -- then it briefly changes to show only '+1' -- and then the call simply disappears, as the screen returns to a normal, idle state.

He is quite shocked at this, most especially because of the fact that Tom, his cube mate, has the same Cisco 7961 IP phone, with the same dialing permissions (Tom also has the exact same CSS as Pablo, on both his Line and Phone Device), and Tom has absolutely no problem returning this exact same missed call pattern.


There is one small difference between Pablo and Tom's phones -- Tom has a 7961 SCCP phone, while Pablo has a 7961 SIP phone.


BTW, I should probably also note that neither one of them has any trouble placing any sort of normal, local calls when dialing from their keypads.


So, your contest question for the weekend is a three-parter:
  1. Why does Tom's phone work, but Pablo's does not, when attempting to return the very same missed call?
  2. What CUCM entity could you add to this equation to make Pablo's phone work for returning this call (without changing any of the entities or values listed above)?
  3. What would the value be of this newly created entity?
The winner of this contest will have their choice of any one of these items:
  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is just a bit more than 3 Voice rack sessions)
  • $100USD worth of INE.com online store credit
The way we will hold the contest is as follows:
  • You must answer all questions correctly, submitting your answers in the comments section of this post
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • It might be good if you posted with a registered email account -- you know, that way we can notify of your glorious prizes should you win? :-)
I'll return on Monday to gather up the winners, choose a random name, and post all of the comments with my own replies and comments.


Also, we will be holding these sorts of contests bi-weekly, so check back often to increase your chance of winning!


Good Luck!
Mark Snow



Congratulations to Roger Carpio, the winner of this contest!


As promised below in my comments, here is an updated post with the screenshot for the SIP Dial Rule to both fix this problem, and avoid a 10 second inter-digit timeout for all other normal keypad dialed calls:

Click to see full-sized image

Nov
05

Answers for Part II

So the answers to the exciting tasks at hand....

There was a good amount of activity surrounding answers submitted for the contest!  It was good to see that many people interested in them!  Now, it's time to go through the answers and stretch the imagination a bit!  Be prepared for some stretching as well!

One quick thing to point out before we get started, there was a question asked about why /24 routes won't have a ".255" as the fourth octet.  This really depends on how we are using the ACL.  If we are doing traffic filtering, where packets will obviously come from hosts INSIDE the /24, then yes, I'd use a ".255" mask.

However, when the entry is being used for a routing filter, and it's a /24 route...  The fourth octet will, by definition, always be ".0" and shouldn't be changed.  So the mask of ".0" prevents anything from changing!

Now...  On to the answers!

1.  Now, there are a total of 16 things we're trying to match.  So in the best of worlds, we can do this in a single line (because it's an exponent of two), but if and ONLY IF we find a total of four bits different across the entire 32-bit address.  So let's solve it.

Where do we have differences?  All over the place!  So let's isolate them.

2nd octet:

34    00100010
50    00110010

Only the 16-bit position is different here.  (mask of 00010000)  This could have been discovered by the subtraction method!

3rd octet:

80    01010000
208    11010000

Only the 128-bit position is different here.  (mask of 10000000)  This could have been discovered by the subtraction method!

4th octet:

133    10000101
165    10100101
197    11000101
229    11100101

It's a little more difficult to use the subtraction method here as well!   But we discover that there are only two bits of difference here, in the 64-bit position and the 32-bit position. (mask of 01100000)

So we DO have a total of four bits across these numbers.  Cool.  One line, right?

But go back to re-read the question.  There's more to it than that!  The even-numbered bits of the SECOND-HALF of a /24.  Now that's just plain evil!

So numbers from 128-254, and only the even ones.  Now we've done the even numbered thing before.  That's a mask of ".254" (11111110) with the starting point of .0...  But here we want only the second half.  So what else is consistent in even numbers OVER 128?  (hint:  the 128-bit position!)

access-list 101 deny ip 180.34.80.133 0.16.128.96 150.100.32.128 0.0.0.126
access-list 101 permit ip any any

And we'll assume that the access-list is either applied inbound on a WAN link, or outbound on our LAN link!

2.   Pure summarization now.  But there's only 12 lines listed.  That doesn't work out as nicely for single-line summarization!  The best we'll be able to do is two lines.  but let's work through the details.

First octet:

19 00010011
79 01001111
83 01010011

Second octet:

55 00110111
56 00111000

Third octet:

4 00000100
5 00000101
12 00001010
13 00001011
20 00010100

Yeah, now all of a sudden that two-line solution isn't looking nearly as possible!  So let's start isolating.  (Divide and conquer)

Really our consideration will be with the 19 and 83 address sets.  They each have 4, 5, 12 and 13 in the third octet.  The 79 addresses are completely different in the third octet.

First octet:

19    00010011
83    01010011

One bit of difference there in the 64-bit position.  (mask = 01000000)  This could be solved with subtraction.

Third octet:

4    00000100
5    00000101
12    00001100
13    00001101

While we can't really do the subtraction method here, at least there's only two bits of difference here.  (mask = 00001001)  These eight values can be summarized in a single line.  Three bits of difference (2^3 = 8 matches).

access-list 2 permit 19.55.4.0 64.0.9.0

Now, the 79-series of addresses.

Second octet:

55    00110111
56    00111000

Lots of differences here (four bits) so we'll be treating these separately.

Third octet:

4
20

Why bother with the math?  Just subtract!  :)  Only the 16-bit position changes.  (mask = 00010000)

access-list 2 permit 79.55.4.0 0.0.16.0

So our entire solution:

access-list 2 permit 19.55.4.0 64.0.9.0
access-list 2 permit 79.55.4.0 0.0.16.0
access-list 2 permit 79.56.4.0 0.0.16.0

Hey!  Look!  Two lines.   But it seemed so ugly for a while!  We use ".0" for the fourth octet because we were told this ACL is for routing updates.  /24's in a routing update will always have .0 as the fourth octet!

3.  Ooooo..   A big, long, ugly looking one!  Well...  If we count them, there's only 28 lines.  That's definitely not going to solve in one line!  Best we can do there is three lines (16 + 8 + 4).  Hmmmmm.  Time to look at binary!

First octet:

124    01111100
132    10000100

Yeah...  That's not going to happen.  Five bits of difference will get 32 matches.  :)  Even though the subtraction method says "8" is the difference, since we cross a bit-boundary (128), all bets are off!

Second octet:

130    10000010
194    11000010

This is easier!  There's one bit of difference between these two.  (mask = 01000000)  This could be solved via subtraction.

The third octet is all ".1".  So that brings us to the fourth octet:

16    00010000
17    00010001
19    00010011
24    00011000
25    00011001
26    00011010
27    00011011

That's just plain ugly now.  There are actually three bits of difference in there, but one very important piece to note.  18 is missing from the list, so it's not all contiguous that way.

But wait...  The task actually says we need to include "18" as a deny specifically!  So therefore we CAN count it.  Once we do that, three bits of difference makes things work (2^3 = 8 matches).

So let's put it together now.

access-list 3 deny 124.130.1.18 0.64.0.0
access-list 3 deny 132.130.1.18 0.64.0.0
access-list 3 permit 124.130.1.16 0.64.0.11
access-list 3 permit 132.130.1.16 0.64.0.11

line vty 0 15  (optional for grading)
access-class 3 in (optional for grading)

4.  Now we need to first convert a prefix-list into an access-list.  THEN we need to look at the existing access-list and somehow integrate the two together.  Isn't this just pleasant.

This not only tests you on your knowledge of access-lists and binary functions, but also on your knowledge of BGP distribute-lists!  See, our issue is that the current distribute list only looks at /24 information.  And not necessarily very well, but that's the intent.  Our prefix-list looks at many mask lengths from /20, /21, /22, /23 and /24!

BGP distribute-lists can use an extended ACL to match the mask information as well!  Oh boy will this be fun.  Actually, it's not nearly as bad as it looks!

With the prefix list, our binary starting point is all the same.  192.168.0.0/15.  This is 192.168.0.0 0.1.255.255 in "regular ACL" masking.  The masks we are looking for are:

255.255.240.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0

So really, we're matching on third octet values:

240    11110000
248    11111000
252    11111100
254    11111110
255    11111111

So the last four bits, I really don't care what the values are.  Wait.  If we come up with a mask of 00001111 (15), what happens when we're presented with a value of 247?  Wouldn't that match?

Sure, technically it would match the mask we create.  But fortunately for us, there's no way in reality we're going to ever see a mask like that!  Route masking can only be done on bit boundaries!   So reality versus technical possibility (e.g. fantasy) are two completely different ideas!

access-list 104 permit 192.168.0.0 0.1.255.255 255.255.240.0 0.0.15.0

Now, we have to look at the remaining values.  These should be easier as it's just a summarization question.

Third octet:

0    00000000
1    00000001
2    00000010
3    00000011
4    00000100
5    00000101
6    00000110
7    00000111
8    00001000
9    00001001
10    00001010
11    00001011
12    00001100
13    00001101
14    00001110
15    00001111

Again, the masking will be 00001111 (.15).

access-list 104 permit 150.100.0.0 0.0.15.0 255.255.255.0 0.0.0.0

So our whole ACL:

access-list 104 permit 192.168.0.0 0.1.255.255 255.255.240.0 0.0.15.0
access-list 104 permit 150.100.0.0 0.0.15.0 255.255.255.0 0.0.0.0

Well...  That was fun.  I will tell you, it was likely much more entertaining for me than it was for you.  But good stuff.  If nothing else, getting through these exercises, and having them actually make some semblance of sense to you, there's NOTHING that the CCIE Lab can come up with that will scare you!

It's good to be evil.  :)

See the Comments here for the list of winners!

Nov
03

I know, I know...  I promised this a while back, after I did the first part.  Sorry 'bout that!

So we've played around a bit with the access-list idea and some binary matching.  So let's expand our brains even further!

I will start out by telling everyone that I am NOT picking on or otherwise attempting to insult any CCNA's out there by comparing methodology to what is learned in CCNA.  The idea being that there are basic and advanced ways to learn things.

When we all first learned fractions, if anyone attempted to explain more advanced methods of long division, or finite state mathematics, or anything we now consider to be "basic algebra", plain and simple....  our brains would have imploded!  It wouldn't have been pretty at all.

There is a time and a place for everything.  When first beginning as a CCNA, the concept of "network" and "network mask" and wonderful subnets on standard bit-boundaries is good.  It's a starting point.  Just realize that it isn't the end point, and as CCIE Candidates, we need to see beyond those initial learning steps in order to succeed!  If you have stumbled across these blogs, and are still a CCNA, my sincere apologies as I did not mean to offend!  (And my apologies for any induced-brain-implosions!)

Now, all those legal disclaimers aside, it's time to move up a notch in Binary Math.  We're still counting to one, we're just doing it with more finesse now!  So let's start with our first problem for Part II.

Summarize these in as few lines as possible:

168.192.3.0/24
168.192.14.0/24
168.208.11.0/24
168.208.14.0/24
168.208.3.0/24
168.192.11.0/24

Our expansion and brain-freeze difficulty here is that we have differences in two different octets.  Well, I've got one for ya!  Who cares!?!?  The router doesn't.

Let me go out on a limb here and say that ALL access lists in our routers are essentially operating in the exact same fashion.  Now, don't go getting all sulky on me and tell me how they can't all be the same because they're different protocols.  I know that!  :)

But LOGICALLY, it's the same process.  A 200-series ACL is for ethertypes.  They are represented in hexadecimal (for our benefit since ethertype values are routinely expressed in hex).  But the router sees a starting string of 16 bits, and a mask of 16 bits to go with it.

The standard or exteneded IP ACLs are for IP addresses as we all know.  They are expressed in dotted decimal for OUR benefit.  The router sees a string of 32 bits and a mask of 32 bits.

An 800 series ACL is for IPX.  Again, expressed in hexadecimal for our benefit.  The router sees a starting string of 80 bits and a mask of 80 bits.

An IPv6 ACL is the same thing, only with 128 bits starting strings and masks!!!

You get the idea here.  Same #$*&# different ACL!  So that idea of the difference being in different octets. The router doesn't see it that way.  So get it out of your head!  Octet boundaries should make no difference to a CCIE Candidate!  That period is just a bump on the road of learning!

Anyway, enough sophomoric digression here...  Let's look at the binary.

Second octet:

192    11000000
208    11010000

There's only one bit of difference, so we can definitely summarize!  Even if we didn't look any further, we can reduce these to three lines now.

access-list 21 permit 168.192.3.0 0.16.0.0
access-list 21 permit 168.192.11.0 0.16.0.0
access-list 21 permit 168.192.14.0 0.16.0.0

And that would work nicely.  So let's look at the third octet:

3    00000011
11    00001011
14    00001110

Well, we end up with three bits of difference there (in the 1-bit, 4-bit and 8-bit positions).  2^3 will give us eight matches here.  That's not cool.  Only three.  Look more closely at them individually.  14 is really the one that "doesn't belong" or doesn't fit well in the group.  So treat it separately!

Between 3 and 11, there's only one bit of difference (2^1 = 2 matches).  So look at this in conjunction with what we did above.

access-list 21 permit 168.192.3.0 0.16.8.0
access-list 21 permit 168.192.14.0 0.16.0.0

The first line matches four of our original networks, and the second line matches two.  And the fact that the bits are in difference octets only bothers us, not the routers!  This is another one of those "not taught like this in CCNA" moments of discovering the ability to change masks on a per-bit basis!

So let's have a little more fun here....  Summarize these in as few lines as possible:

207.49.164.0/24
208.49.164.0/24
205.49.165.0/24
207.49.165.0/24
192.49.164.0/24

Again, we have varying numbers in two different octets.  One extra step we can take while doing this in the lab (or practicing) is to use Notepad and the Windows Calculator to help.

Notepad is nice because it's a proportional font, so things line up nicely.  By hand, it makes things uglier.  If your handwriting is anything like mine, after a while you can't figure out where the heck your columns are supposed to be lining up!  The other cool part about Notepad is that you can cut and paste to rearrange the order, or put things to the side once you have them matched.

Otherwise, it's all about binary.  The first octet:

192    11000000
205    11001101
207    11001111
208    11010000

Lots of bits of difference there.  Five of them to be exact.  And since 2^5 gives 32 matches, we know it's not going to be that simple!   So start pairing and rearranging!

192    11000000
208    11010000

205    11001101
207    11001111

With those pairs, there's only one bit different between them.  2^1 yields two matches only, so we're good there!  Now, let's look at those pairings with all numbers.  The 192 and 208 addresses match in the second and third octets, so we can remove them.  But we still have variety in the third octet:

164    10100100
165    10100101

Again, one bit of difference makes things nice, but here's our quandary.  We have three items left to match, and no matter how we line things up, a single ACL entry cannot match all three with no extras or leftovers!  (3 is not an exponent of 2!)  So there will have to be an extra statement no matter how we slice things.

There are actually three different ways to solve this, which makes it very interesting to talk through!

Method 1:

access-list 22 permit 192.49.164.0 16.0.0.0
access-list 22 permit 205.49.165.0 0.0.0.0
access-list 22 permit 207.49.164.0 0.0.1.0

Method 2:

access-list 23 permit 192.49.164.0 16.0.0.0
access-list 23 permit 205.49.165.0 2.0.0.0
access-list 23 permit 207.49.164.0 0.0.0.0

Method 3:

access-list 24 permit 192.49.164.0 16.0.0.0
access-list 24 deny 205.49.164.0 0.0.0.0
access-list 24 permit 205.49.164.0 2.0.1.0

All of the methods give us three lines.  One does include a "deny" statement, if required.   Nice things though, and again, the bits-per-octet make no difference to the router!

Let's look at one more.  Create an ACL in as few lines as possible to allow the hosts from these networks in:

182.17.77.0/24
182.81.77.0/24
190.17.73.0/24
190.81.73.0/24
190.81.77.0/24
182.17.73.0/24
182.81.73.0/24
190.17.77.0/24

You can also count on the idea that the numbers presented to you will NOT be in numerical order, so they are intentionally presented in a way that is not as simple to visualize!  (Another good idea to use Notepad!)

In this example, we have differences in THREE octets.  No fear though, right!  Same stuff, different example!  The rules have not changed.  Where's the binary?

182    10110110
190    10111110

17    00010001
81    01010001

73    01001001
77    01001101

Notice that in each of the octets, there is only one bit that is different.  2^1 per octet gives us two matches, which is all we have.  More importantly, 2^3 (total of 3 bits in the entire 32-bit mask string) gives us eight matches, which is all we have listed in he task itself!  So we can do the whole thing in just one line!

access-list 25 permit 182.17.73.0 8.64.4.0

See, it wasn't all that bad, was it?

There are some rules and things to make life a little easier....

You can visually look at a scenario and see what the best possible answer is just by the number of matches you need!

If you have eight entries to match, your best possible outcome is one line.   2^3 = 8, so if you find exactly three bits different in all of them, then that's it!  Life doesn't always work that way, but at least you know the minimum!

Likewise, if you have only six things to match, the best you can possibly do is two lines.  2^2 and 2^1.  Or deny 2^1 and permit 2^3.  Still two lines.  You get the idea.

Again, this is IF things work nicely with bit boundaries and stuff.  But at least you won't have to stress out about "I wonder if I can get less lines than what I already have"!!!

On larger/longer examples, we can do some additional things to check this out.  Namely, the "network" or "binary starting point" will ALWAYS be your lowest matching value (in other words, ever place you have a "1" in the mask, the router will put a "0" value in that position).  To test your mask, type in the ACL with a middle/higher starting point.  As long as the mask is correct, when you look at "show run" or "show access-list" then you should see the starting point.

If you see something that doesn't exist in your list, or is just entirely different...  Well...  You've messed something up!  :)

Another quick check that we can do is to subtract.  When you subtract two numbers and the difference is an exponent of two, then that's the bit that is different between them.

In the last example here:

190 - 182 = 8
81 - 17 = 64
77 - 73 = 4

And those were our mask values there.  Now, be careful since that doesn't always work!  Particularly with "1" being the difference.  If you cross a bit boundary, you'll have problems.  Think about if our values were 7 and 8.  The difference is only 1, yet there are four bits different between those two!   But otherwise, it's a nice shortcut to help quickly check things!

Working with binary really doesn't have to be that scary or difficult!  When you are just getting used to this, it's best to work with the binary and start to SEE things and patterns.  As you get more experienced, you'll be able to do more of the math in your head.

Oh, one last thing....  If the lab makes you do one of these nice access-lists, try really hard NOT to forget to apply it someplace!  ;)

I figure with nine years gone by, it's not really an NDA thing to say I had a difficult ACL on my lab exam.  And I wasn't as good with binary back then, so it took almost an hour to figure out.  And I got it right.  But I found out that I didn't get points for it which really irritated me, and I started to "discuss" it (this was back when we interacted more with the proctors) until the proctor very nicely pointed out to me that it WAS correct, but I forgot to apply it to an interface which makes it entirely useless.

DOH!    So don't overlook the small stuff!  I hope this has helped a bit with all the binary voodoo magic.  In case you are still staring at the screen wondering why you would ever care about this....  Your router does!   If you have used or heard of Turbo ACLs, or Compiled Access Lists, it's the same thing.  Your router does all of this logic in order to make the list smaller and more efficient.

The programmers were smart enough to NOT display the working ACL to users though!  TAC was not equipped to deal with brain implosions from users!   :)

Here's a few extra problems to make life a bit more interesting!

1.   You have hosts on 150.100.32.0/24.  Make sure the following addresses are not allowed to access any even-numbered server in the second-half of your IP range.  All other access should be allowed.

180.34.80.133
180.34.208.197
180.50.208.229
180.50.80.197
180.34.80.197
180.34.208.133
180.34.208.165
180.50.208.133
180.34.80.229
180.50.208.197
180.50.80.133
180.50.80.165
180.34.80.165
180.34.208.229
180.50.80.229
180.50.208.165

2.  For a routing filter, summarize these permissions in as few lines as possible:

19.55.4.0/24
19.55.5.0/24
19.55.12.0/24
19.55.13.0/24
79.55.4.0/24
79.56.4.0/24
79.55.20.0/24
79.56.20.0/24
83.55.4.0/24
83.55.5.0/24
83.55.12.0/24
83.55.13.0/24

3.  The following hosts should be allowed to telnet into your router:

132.130.1.16
132.194.1.16
132.130.1.17
132.194.1.17
132.130.1.19
132.194.1.19
132.130.1.24
132.194.1.24
132.130.1.25
132.194.1.25
132.130.1.26
132.194.1.26
132.130.1.27
132.194.1.27
124.130.1.16
124.194.1.16
124.130.1.17
124.194.1.17
124.130.1.19
124.194.1.19
124.130.1.24
124.194.1.24
124.130.1.25
124.194.1.25
124.130.1.26
124.194.1.26
124.130.1.27
124.194.1.27

Create an ACL to use as an access-class on the VTY ports.  Use as few lines as possible.  You must use two "deny" statements in your ACL.

132.130.1.18 (deny)
132.194.1.18 (deny)

124.130.1.18 (deny)
124.194.1.18 (deny)

4.  You have one router configured with a prefix-list in BGP:

ip prefix-list GoodRoutes permit 192.168.0.0/15 ge 20 le 24

You want the same information configured on a different router, but you need to integrate this with your existing BGP distribute-list.  Your current BGP distribute-list is:

access-list 44 permit 150.100.0.0 0.0.0.255
access-list 44 permit 150.100.1.0 0.0.0.255
access-list 44 permit 150.100.2.0 0.0.0.255
access-list 44 permit 150.100.3.0 0.0.0.255
access-list 44 permit 150.100.4.0 0.0.0.255
access-list 44 permit 150.100.5.0 0.0.0.255
access-list 44 permit 150.100.6.0 0.0.0.255
access-list 44 permit 150.100.7.0 0.0.0.255
access-list 44 permit 150.100.8.0 0.0.0.255
access-list 44 permit 150.100.9.0 0.0.0.255
access-list 44 permit 150.100.10.0 0.0.0.255
access-list 44 permit 150.100.11.0 0.0.0.255
access-list 44 permit 150.100.12.0 0.0.0.255
access-list 44 permit 150.100.13.0 0.0.0.255
access-list 44 permit 150.100.14.0 0.0.0.255
access-list 44 permit 150.100.15.0 0.0.0.255

Create a new BGP distribute-list in as few lines as possible.

So the contest part will begin again....  And hopefully will run more smoothly this time!  :)  Again, a prize for the first person with ALL FOUR correct answers will receive 120 tokens, good for rack rental, mock labs, whatever....  Very useful stuff!

All comments for this will be withheld for 24 hours to allow the entertainment to ensue!  Good luck!!!

Subscribe to INE Blog Updates

New Blog Posts!