Second mock exam done – INE mock exam 5

On January 24, 2012, in CCIE, by Darren

This exam is graded higher than the last and I got more points than the last. However I still failed. This time I got 59/96

I need to check my configs again though, as the results say I did very poorly on my IGP section. I spent quite a bit of time on that section and I know I should’ve done better. I don’t know if I was marked wrong or what?

However there are a couple of things I need to take from this. I had to set up some IPv6 tunnelling and run OSPFv3 over it. I had that up and working. A later task then required me to do some filtering on ACLs. I was stupid and forgot to allow ipv6ip traffic through this ACL. I noticed when I had about 5 minutes left on my lab that suddenly I didn’t have OSPFv3 adjacencies. I couldn’t even ping my neighbours. I tried to rush to find out what the problem was, but I ran out of time. I therefore lost points both on the OSPFv3 section AND the ACL section for blocking the tunnel :(

Troubleshooting I got 100% – but I must admit the troubleshooting section for this lab seemed almost TOO easy

This is the report:

 

More full scale labbing

On January 22, 2012, in CCIE, by Darren

So I thought I’d take Sunday off but I didn’t. I wasn’t really happy with my first 2 lab results so I did another 2. INE Vol2 labs 8 and 9 are both rated as level 8.

Lab 8 I did yesterday and bagged myself 62/79

Lab 9 I just completed and in total I got 60/79

Both are officially fails, but I’m happy with the progress. Nothing makes you learn the stuff more than just doing the labs. Anything I stumbled on I just used the DocCD. This is good as I’m getting a lot better at navigating that beast finding the things I need quickly.

Tomorrow I do INE’s marked mock exam. Alas I only get the results a day or two later so I’ll have to wait. Apparently Lab5, which is the one I’m doing, is a pretty tought one.

 

Week of full scale labbing

On January 20, 2012, in CCIE, by Darren

I took yesterday and today off, and I also have leave next week Monday and Tuesday.

Monday I take my second INE mock exam. I’m hoping to do much better than last time, but we’ll see what they throw at me this time.

I’m using the other days to do full 8 hour labs as I just don’t have the time for a full lab every day thanks to work. If any of you have dont INE’s Vol2 labs before you’ll know they grade them in different difficulties. 7-8 is pretty much on par with the real lab, while 9 is very difficult indeed.

Yesterday I did a level 6 lab just to start myself off again. I ended up with 50/79 – Which is a fail. You need at least 65 to pass. There are no part credits for any sections, so if a section is worth 5 points and you get a single tiny thing wrong you get 0 for the section.

So I wasn’t feeling too good :(

This morning I then did a level 9 lab. This time I got 49/79 – still a fail, but I’m actually quite happy with it as this stage. This lab is purposefully mad difficult and the fact that I passed most of the sections makes me happy.

Tomorrow I’ll be doing a level 8 lab. Then I might chill a bit on Sunday. Monday is the mock lab and Tuesday I’ll be going over whatever I tanked on with the mock lab

 

CCIE R&S PPP notes

On January 15, 2012, in CCIE, CCIP, CCNP, notes, by Darren

PPP Multilink:

  • You can configure the router to force at least 2 or more link to be up for the multilink interface to be up by using the ppp multilink links minimum (#) (mandatory)
  • The mandatory keyword will tear the link down if the minimum # of links is less than the active links, while not using mandatory will wait for the required links to bring up the interface at first, but keep the link up if the active number of interfaces goes below
  • Int sx/x
  • ppp multilink
  • ppp multilink group 1
  • int multilink 1
  • ip address x.x.x.x x.x.x.x

Misc:

  • show controllers int serialx/x will show you if it’s the DCE or DTE
  • If you are the DCE, and the task states that links are 64k, ensure you set the clock rate to 64000
  • ppp authentication (type) configured on the interface, tells the current router to authenticaticate the OTHER side
  • Can use PAP (clear text), CHAP (secure) or EAP (secure)
  • EAP usually uses radius. Can tell router to use local database though using the interface command ppp eap local
Tagged with:  

CCIE R&S Frame-Relay notes

On January 14, 2012, in CCIE, CCNP, notes, by Darren

LMI:

  • LMI runs between the router and the FR switch.
  • Cisco LMI is supported by other vendors
  • 3 types, but autosensed by default
  • Router gets DLCI’s via LMI. ACTIVE is good, INACTIVE means local link to FR switch is good, but a problem further on, DELETED means the switch is trying to use a DLCI which the FR switch does not have

Interface types:

1. Physical

  • May need to disable split-horizon for EIGRP/RIP
  • Will need frame maps if inverse-arp is off

2. Point-to-pont

  • Will need DLCI configured on the subinterface
  • No frame-maps needed

3. Point-to-multipoint

  • Requires frame map or frame-relay interface-dlci
  • May need to disable split-horizon for EIGRP/RIP

Back to back frame-relay:

  • Switch off LMI by issuing the no keepalive interface command
  • DLCIs must match (i.e. if using 701 on one side, need 701 on other side)
  • Can still run subinterfaces

Frame-relay multilink (FRF.16):

  • Uses mfr interface. All layer3 config, including frame-maps will be configured on the mfr interface. Can use mfr subinterfaces as well
  • Interface mfr 1
  • ip address x.x.x.x x.x.x.x
  • Tie physical interfaces into the mfr interface
  • Interface Serial0/0
  • encapsulation frame-relay mfr 1
  • show frame-relay multilink

PPP over FR:

  • Uses virtual-template. All layer3 config will be configured on the virtual-template interface.
  • PPP is needed when you need to run multiple point-to-point links over a physical interface
  • Can be used for authentication
  • Interface virtual-template 1
  • ip address x.x.x.x x.x.x.x
  • ppp authentication (x)
  • Interface Se0/0.1 point-to-point
  • frame-relay interface-dlci 101 ppp virtual-template 1
  • Interface Se0/1
  • Frame-relay interface-dlci 102 ppp virtual-template 2

End-to-end keepalives:

  • Keepalives are from local router to FR switch only, so no end to end keepalive by default
  • Can run E2E keepalive with map-class
  • Create map-class specifying EEK, then apply map-class to interface
  • map-class frame-relay EEK
  • frame-relay end-to-end keepalive mode (x)
  • Interface Se0/0
  • frame-relay class EEK
  • show frame pvc will show you if the EEK is up or not

Misc:

  • frame-relay maps (xxx) (xxx) ietf – The ietf option is the industry-standard option
  • Can mix and match. So on a single interface you can use the physical interface, P2P subinterface and a P2MP subinterface at the same time
  • To bridge over frame-relay, you need the frame-relay map bridge (dlci) broadcast command, as well as the regular bridging commands
  • sh frame PVC | include ACT
  • sh frame map
Tagged with:  

CCIE R&S BGP notes

On January 9, 2012, in CCIE, CCIP, notes, by Darren

EBGP:

  • BGP neighbour addresses have to be in the local routing table. Following a default route will NOT work
  • Next-hop for eBGP routes will NOT follow a default route. i.e. if you have a BGP speaker advertising eBGP routes to it’s iBGP peers, those iBGP will not install that route into their rib if they don’t have a route to the next-hop. A default route doesn’t count!
  • When advertising a network in BGP via the network command, there has to be a match in the local RIB, otherwise it won’t be advertised – An Inject-map can be used to change this slightly
  • By default eBGP neighbours are expected to be directly connected. If not, or peering via loopbacks, there are 3 ways to change this behaviour
  1. ebgp multihop (ttl)
  2. disable-connected-check
  3. ttl-security hops
  • ebgp multihop will increase the ttl to whatever value you want it to be
  • disable-connected-check does not increase the ttl, but will allow routers to peer if the peer address is directly connected (like a loopback)
  • ttl-security hops will send BGP requests out with a ttl of 255, but the value you set has to be the value of the ttl when it comes in

Communities:

  • ip bgp-community new-format is a global config command that will show the communitys in the new x:x format
  • Communities are NOT sent to neighbours by default. You need to configure the send-community option on the nieghbour statement
  • no-export – route not sent outside AS, but will be sent to confederation peers
  • local-as - as above, but NOT advertised to confederation peers
  • no-advertise – don’t advertise to anyone
  • If you set a community via a route-map, it WILL overwrite all previous communities, unless you set the additive keyword

2 easy ways of stopping your AS becoming a transit AS:

  • Create an incoming route-map from eBGP peers that adds the no-export community
  • Create an as-path access-list matching ^$ and filter on that outbound to eBGP peers

Regular expressions:

  • show ip bgp regexp (expression) is handy to work out what your expressions will match in your current BGP table
  • ^    beginning of string
  • _    Contains (anything before or after)
  • $    End of string
  • []    Range of numbers
  • -     Used to specify range [0-9]
  • ()     Logical grouping
  • \     Special character to follow (confederations)
  • .     Single character wildcard
  • *     0 or more of the preceeding character
  • +    1 or more of the preceeding character
  • ?     0 or 1 of the preceeding character

Peer groups:

  • Peer groups are used to simplify your BGP configuration by confguring options under a group, and then assigning neighbours to a group
  • Neighbours in a single group must have the same outbound policies
  • neighbor (group name) peer-group
  • neighbor (group name) remote-as xxx
  • neighbor (group name) (options)
  • neighbor x.x.x.x peer-group (group name)

Route-reflectors:

  • If you have more than 1 route-reflector in a single AS for fault-tolerence, ensure both have matching cluster-id’s BEFORE you set up the clients.
  • If set up before, reboot the route-reflector
  • If you only have a single route-reflector, it’s unnecessary to set the cluster-id

Confederations:

  • inter-sub-as neighbours will need ebgp multihop configured if not directly connected!
  • bgp confederation peers x x x only really needs to be configured on the confederation BGP speakers that connect to different confederation AS numbers in the same confederation. It doesn’t hurt to configure it all on all of them though
  • bgp confederation identifier (external AS) needs to be configured on all confederation BGP speakers

Dampening:

  • bgp dampening is a global command that enabled dampening
  • bgp dampening (half-life) (reuse) (supress) (max-suppress) [route-map](map)
  1. Half-life – Time before penalty cut in half (15min default)
  2. Reuse – Low threshold where route reused (750 default)
  3. Supress – High threshold where route supressed (2000 default)
  4. Max-supression – Max time to be supressed (60 min default)
  • The default penalty for a flap is 1000
  • These are sliding scales. i.e. if a route flaps it’ll get 1000 points, but will start losing points 1 by 1 straight away
  • If you want to ensure certain routes are NOT dampened, create a route-map that denys the routes you don’t want dampened, and allow everything else
  • When dampening though a route-map, you need to set the dampening values in the route-map itself, even if they are the defaults!

Redistribution:

  • When reditributing from BGP into an IGP, by default no iBGP routes will be reditributed, ONLY eBGP. To ensure iBGP routes are distributed, you need to configure bgp redistribute internal under the BGP process. This can VERY easily cause loops so be careful!

Misc:

  • Supress-maps are configured under the aggregate command, while unsuprsess maps are configured under the neighbour statements (check this though, supress might also be for neighbour as well)
  • When configuring an aggregate, the AS numbers of the source addresses part of that aggregate are lost. You can keep sending them as an as-set by adding the as-set command at the end of the aggregate
  • An aggregate will inherit the community values of it’s parent routes when using as-set configured above. This includes communities like no-export. You can override this with an attribute-map at the end of an aggregate command. The attribute-map calls a route-map in which you can remove the communities, or set new ones
  • Exist and non-exist maps will match routes in the BGP table, not the RIB
  • When using an inject map, the exist map MUST have both a match route term AND a match route-source term
  • You can see the effects of a filter before applying it by doing a show ip bgp filter-list (filter); show ip bgp community-list (filter) etc etc
  • An extended ACL actually acts like a prefix list in BGP. The source bits tell what IP address/range to match, while the destination bits tell what subnet mask to match. The protocol is ignored. – permit ip 172.16.1.0 0.0.0.255 255.255.255.0 0.0.0.0 – matches 172.16.1.x/24 only – permit ip 172.16.1.50 0.0.0.0 255.255.255.0 0.0.0.255 matches 172.16.1.50/24-32 only – etc…
  • When configuring maximum prefix values to receive from a neighbour, the first variable is the amount of prefixes while the second number is the percentage to warn on, not the number received!
Tagged with:  

CCIE R&S Multicasting notes

On December 31, 2011, in CCIE, notes, by Darren

Sparse mode:

  • When user joins, connected router will have *,G entry, as it knows the group joined by the user, but not the source of that feed yet. This is the SHARED tree.
  • The RP WILL have an S,G entry. Once the router connects it will stay on the *,G shared tree at first, then switch over to the S,G source tree.
  • While on the shared tree, the RPF check will be towards the RP, NOT the source! This will change to the source once the router connects to the source tree
  • ip pim spt threshold controls when the router will switch from the *,G to the S,G tree. A value of infinity means it’ll NEVER switch to the S,G tree

Dense mode:

  • In dense mode you’ll always see S,G entries as the source has been flooded through the network. i.e. all PIM routers will already have the feed, and hence will know the source

Sparse-Dense mode:

  • Sparse-dense mode is mainly like sparse mode, but any group that cannot be registered with the RP becomes dense mode
  • This is good for Auto-RP, but it also means that mis-configurations on the RP could cause lots of groups to be dense mode instead of sparse mode

Rendezvous point:

All modes:

  • You need to run PIM on the interface that you are advertising as the RP. i.e if you’re running it on a loopback interface, run PIM on that loopback!
  • Auto assignments OVERRIDE static assignments! You can use ip pim rp-address (rp_address) (acl) override to override this default behaviour

Static RP:

  • Easiest to configure, pretty much like a static route
  • ip pim rp-address (rp_address) (acl)
  • (acl) determines what groups the router will be the RP for
  • The RP router ALSO needs to have the above configured. i.e the RP does not automatically know it is the RP, you need to tell the router that it is!

Auto-RP (Cisco proprietary):

  • Auto-RP is made up of 1 or more routers announcing themselves as candidate RPs using the command: ip pim send-rp-announce (acl) as well as a mapping agent using the command: ip pim send-rp-discovery
  • Only the mapping agent listens to the RP announcements
  • The MA then determines which RP to use for which groups and advertises that to all other PIM routers
  • The auto-rp process uses the 224.0.1.39 and 224.0.1.40 groups
  • In sparse-dense mode the 2 groups above are automatically in dense mode
  • If running sparse mode only, you need to configure ip pim auto-rp listener on transit PIM interfaces which will ensure that ONLY 224.0.1.39 and 224.0.1.40 are in dense mode
  • If the MA receives 2 announcements from candidate RPs for the same groups, the MA will choose the one with the highest IP address
  • The RP and MA can be the same device if needs be
  • Auto-RP IS supported by a number of Non Cisco devices. Confirm with proctor is question is not clear
  • When specifying an ACL with a RP announcement, the deny statements will create negative entries for groups. However a deny any at the end of the ACL will effectively make ALL groups negative, and hence dense mode, regardless of what’s configured. As an example:

ip pim send-rp-announce Loopback0 scope 15 group-list 12 interval 1
access-list 12 deny 224.110.110.110
access-list 12 permit 224.0.0.0 15.255.255.255
access-list 12 deny any

If you check the mapping agent you see this:

Group(s) (-)224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Once the deny statement at the end of the ACL is removed, you see this:

Group(s) 224.0.0.0/4
  RP 150.1.10.10 (?), v2v1
    Info source: 150.1.10.10 (?), elected via Auto-RP

Bootstrap router – BSR (Open standard)

  • BSR uses the group 224.0.0.13, but it does NOT need to be in dense mode, unlike auto-rp
  • 224.0.0.13 is the link-local ALL PIM ROUTERS address as well
  • The Bootstrap router is the Mapping Agent in auto-rp, configured using: ip pim bsr-candidate (int) (hash) (pri)
  • The RP uses the same name as in auto-rp, configured using: ip pim rp-candidate (int) (ttl) (pri) (acl)
  • The hash field will allow you to load balance groups over your RPs – A hash value of 31 ensures all even groups are with on RP and odds are with another, if you have 2 RPs
  • You can see which group is mapped to which RP with show ip pim rp-hash (group)
  • BSR has priority fields so you can choose which router does what without having to rely on the high IP taking over
  • If priority is the same, then highest IP will be chosen like auto-rp
  • ip pim bsr-border will allow you to run PIM on an edge interface, but not to share bsr messages

Multicast on Frame-Relay:

  • By default, multicast traffic is process switched over frame-relay. Multicast frames also have the pak-priority set so have the highest priority
  • If you have a hub router connected to 2 spokes over the same interface, you’ll have problem with RPF checks as you are going in and out the same interface. You can also have problem where a spoke says it no longer wants to receive a feed, this would make the hun stop sending to ALL spokes.
  • ip pim nbma-mode fixes both of the above issues. When configuring nbma mode on sparse-dense and dense mode interfaces you’ll get a warning, but it’ll still work.

Multicast Boundry:

  • int# ip multicast-boundry will stop multicast packets getting through an interface.
  • Any address ALLOWED through the acl is ALLOWED through the interface
  • The boundry is bidirectional by default. If you specify the IN option it will prevent multicast control traffic coming into the interface. If you specify the OUT option it will prevent the interface from being added to the OIL

Stub Multicast:

  • Prevent routers from fully participating in PIM. Consider the diagram:

  • R2 has users on the Fa0/0 interface that want to join the multicast feed. However you do not want R2 to fully run PIM. In order to do so, you need to have R1 configured to prevent R2 from becoming a PIM neighbour. You need then to configure R2 to forward IGMP join messages to R1. Note that dense mode is configured on R2 as it needs to flood multicast traffic over to fa0/0 when it gets an igmp join.

R1:
access-list 1 deny 192.168.1.2
!
int s0/0
ip pim sparse-mode
ip pim neighbor-filter 1

R2:
int s0/0
ip pim dense-mode
!
int fa0/0
ip pim dense-mode
ip igmp helper-address 192.168.1.1

Multicast/Broadcast conversion:

  • You can convert multicast to broadcast, and from broadcast to multicast. You can also do this multiple times backwards and forwards if you need to. Consider the following example:

  • We have a server with the IP of 172.16.1.25 that is sending out a udp broadcast to port 5000. For whatever reason we need that same frame to be broadcasted onto the 10.50.50.0/24 network.
  • To convert from broadcast to multicast you configure like so:

R1:
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
ip forward-protocol udp 5000
!
int fa0/1
ip multicast helper-map broadcast 224.10.10.10 100

  • Then back from multicast to broadcast like so:

R3:
ip forward-protocol udp 5000
!
access-list 100 permit udp host 172.16.1.25 any eq 5000
!
int fa0/0
ip multicast helper-map 224.10.10.10 10.50.50.255 100
!
int fa0/1
ip directed-broadcast

MSDP:

  • MSDP is used for inter-domain multicasting as well as to allow RPs in a single AS to share source information if running anycast RP. All you need to configure on the RPs is:

ip msdp peer (peer_unique_address) connect-source (local_unique_interface)

ip msdp originator-id (unique_address_interface)

Bidirectional PIM:

  • You need to configure ip pim bidir-enable on ALL PIM interfaces. Most RP commands will then have the bidir switch added to the end of commands.

IPv6 Multicast:

  • Sparse mode only
  • Enabled using Ipv6 multicast-routing
  • When enabled, Pim will run automatically on all ipv6 interfaces. Need to run no ipv6 pim on the interface to remove
  • Multicast listener discovery (MLD), part of ICMPv6, replaces igmp
  • Mldv1 is equivalent to IGMPv2. Same timers and so on
  • Mldv2 equivalent to IGMP3 for ssm
  • BSR and Static RP only. No auto-rp. You can also use embedded RP which encodes the RP address in the group address
  • sh ipv6 Pim range-list will show you the rp mapping
  • ipv6 mld join-group will join a group on an interface
  • IPv6 mroute is created using ipv6 route (address/prefix) (next_hop) multicast, NOT ipv6 mroute
  • Pretty much everything else is the same as ipv4

Miscellaneous:

  • PIM assert will take the Administrative Distance into account first, and then metric if that AD matches. So in order to force a router to be the PIM assert router, you may need to adjust the AD
  • ip pim accept-rp (acl) will ensure the RP only accepts *,G joins for groups defined in the ACL. In theory you only need to put this on the RP, but it’s more efficient to put it on all routers so they drop the requests before it even gets to the RP
  • int#ip igmp (acl) is used to allow only joins to certain groups through an interface. This interface is pointing towards the receivers as the control packet is igmp
  • int#ip igmp limit is used to limit the amount of igmp states on an interface. Can also configure this globally
  • When configuring source specific multicast, you are required to configure ip pim ssm default or ip pim ssm (acl) on all PIM routers to ensure they do not create *,G entries. SSM does not actually need an RP as they do not connect to shared trees, only source trees.
  • On an ethernet segment a DR will be chosen between the PIM neighbours. By default, the priority is 1. If the priority is the same, the highest IP wins. This can be changed with the int#ip pim dr-priority command. Note that not all switches support this command!
  • If your IGP is load-balancing certain paths, you can load-balanse multicast as well with the ip multicast multipath command. This is essential so that your rpf checks don’t fail.
Tagged with:  

Mock lab #3 results

On December 24, 2011, in CCIE, by Darren

So I got my report back, and I failed :(  - 52/100

I passed the troubleshooting section with a single point to spare, but screwed up on the configuration section. I can easily see where I went wrong. I need to read, and re-read these questions again as most of my points loss was down to silly mistakes! In the IPv6 section I configured an address slightly wrong (CC1E instead of CC:1E) and so lost ALL the marks for the entire IPv6 section because of it :(

Also there were a couple of questions where I could’ve verified something with the proctor, but there is no online proctor in the mock exam.

However, there were a couple of parts where I did not know how to configure it. My weak points (STILL) is multicasting and services. I think it’s time to hit the books again on those subjects and do the entire INE Vol1 chapters for those sections.

I have another exam near the end of January and so hopefully will do much better on that one :)

It’s not the end of the world. The mock has exposed weaknesses. But I’d rather air that dirty laundry now than on lab day :)

Update: This is the score report btw:

5 points gone because of this:

 

About to start INE’s mock lab 3

On December 20, 2011, in CCIE, by Darren

INE have a total of 7 mock labs. Level 7 is considered the same difficulty as the real lab, and anything above that is more difficult.

I’ve scheduled Lab3, which has a difficulty rating of 7. I’ve scheduled Lab5 (difficulty 8) at the end of January, but that might move around still.

This should give me a taste of the real lab, and also let me know how I’m doing. It doesn’t matter whether I pass or fail as it’ll just show me where I’m still struggling.

I start in 2 hours, time for a coffee and a quick breakfast!

 

Working out ACL wildcard masks

On December 14, 2011, in CCIE, by Darren

You learn to both create ACLs as well as how to subnet while you’re learning for your CCNA. You also may learn about wildcard masks and how to configure them. Wildcard masks are a lot more powerful than they lead you to believe. They are NOT simply inverted subnet masks. A wildcard mask can be used to pretty much match any value you so desire in a subnet address.

As an example take 192.168.0.0 0.0.0.20 – This matches either 192.168.0.4; 192.168.0.16 or 192.168.0.20 – How else could you match 3 non-consecutive addresses in a single line?

So, how do we actually create them? Let’s say you’re given a task which states that you have the following few address: 217.196.48.51; 200.150.3.5 and 155.135.18.11
Write them all out in binary like so:

217.196.48.50 - 11011001.11000100.00110000.00110011
200.150.3.4 - 11001000.10010110.00000011.00000101
155.135.18.10 - 10011011.10000111.00010010.00001011

Line up all the binary. You need to do a bit of logic. If all 3 values are 1, put a 1 in. If all 3 are 0, put a 0 in. If any of the digits in the 3 numbers are different, put an X in like so:

11011001.11000100.00110000.00110011
11001000.10010110.00000011.00000101
10011011.10000111.00010010.00001011
-----------------------------------
1X0X10XX.1XXX11X0.00XX00XX.00XXXXX1

We are now left with 1X0X10XX.1XXX11X0.00XX00XX.00XXXXX1 – Now convert back to binary. X’s can be anything, but to make it easier I consider them to be 0 for now.

1X0X10XX.1XXX11X0.00XX00XX.00XXXXX1 = 136.140.0.1

To now work out the wildcard mask, ensure every X is a 1, while all others are 0:

1X0X10XX.1XXX11X0.00XX00XX.00XXXXX1 = 01010011.01110010.00110011.00111110 = 83.114.51.62

So therefore, to match the 3 original addresses in a single line with minimum overlap we would use the subnet address of 136.140.0.1 with a wildcard mask of 83.114.51.62

Basically what we’re trying to do is tell the IOS that anything in the X above could be any digit. i.e. X could be a 0 or 1. The numbers we are sure of will get a 0. This tells IOS that it HAS to match the subnet address in this part of the byte.

If we take the first octet above we can break it down.
136 with a wildcard mask of 83

136 - 10001000
83  - 01010011

This tells IOS that the first bit HAS to be 1; the third bit HAS to be 0; the fifth bit HAS to be 1 and the sixth bit HAS to be 0. All the other bits can be anything at all, in any combination. So a wildcard 0 HAS to match, a wilcard 1 can mean anything.

Hence the term ‘wildcard’

It takes a little bit of time and practice to get good at it, just like regular subnetting when you started out. Once you understand what it is you’re looking at, it’s not that hard :)

 

© 2009-2012 Darren O'Connor All Rights Reserved