CCNA review update and roadmap

I have my test scheduled and I'm pushing toward the goal now.  My plan for the next few weeks is to:

1. Lab exercises daily on GNS3 for routers and within my switching lab for L2 topics
2. Daily review and update of my blog reviews to solidify those areas of study
3. Extra concentration on areas where I lacked, including but not limited to:
1. Switching:  STP, RSTP+
2. Switching:  VTP
3. Routing protocols
1. OSPF
2. EIGRP
4. IPv6
5. WAN protocols
6. NAT
7. WiFi
4. Test-taking process and review

It will be somewhat challenging to keep focused, but I'm up for the challenge. I have several other technologies that are requiring my attention at work that I need to spend some serious concentration on currently that I'm intending to blog about in the coming weeks following my exam, also.

I have been working with EMC VNX SANs for about 6 months now.  This is a topic that will likely garner much of my attention and study in the coming months as deployments become more complex and the requirements grow in scope.  As these deployments grow from simple, direct-attached Fibre Channel installations to FCoE deployments with varying methods of replication and file/block services, I have much in which to be competent.  Since I'll be studying the technology, I will likely map that to a certification.  Stay tuned...

I am needing to certify on Fortigate firewalls, since I am going to be serving as a product specialist in that line for my company.  Stay tuned for Forti-stuff...

No rest for the network engineer, apparently.

Frame Relay - Address Mapping

Address Mapping in Frame Relay Circuits

A router needs a method to map a DLCI to an IP address, similar to the way ARP maps a MAC address to an IP address.  This is accomplished in two ways:

1. Inverse ARP - 
• Default config for Frame Relay
• provider uses LMI to send a list of DLCIs to the local router, and the local router sends Inverse ARP requests to all other DLCIs, asking for their IP address.  All DLCIs respond with IP address.  
• If you have multiple DLCIs, your interface becomes a multipoint interface, however - Inverse ARP does not work with subinterfaces
2. Static Mapping
• Complete control, but more config
• Assign IP addresses to DLCIs
• R1(config-if)#frame-relay map ip 192.168.5.2 503 broadcast 

Frame Relay - NBMA, Split-horizon and Subinterfaces

A little more info regarding frame relay circuits:

Frame Relay is a NBMA (Non-broadcast Multi Access) network, meaning that it does not allow broadcast traffic between devices.  This will cause a problem if you use distance-vector routing protocols such as RIP, because the split-horizon loop avoidance mechanism will prevent updates from going back out the interface on which they came.  In a hub-and-spoke configuration, the spoke offices will not get updates about each other.

To avoid the split-horizon issues created in this instance, one could disable split-horizon and rely on the other loop-avoidance mechanisms (not recommended) or use subinterfaces.

Subinterfaces are logical interfaces attached to a single physical interface.  The router sees and treats them as separate interfaces, however.

Multipoint subinterfaces do not solve the split-horizon issues and are essentially useless in Fream Relay circuits.  They simply add multipoint interfaces to a logical interface, recreating all the same issues as a physical subinterface.  Meh...

Point-to-point subinterfaces allow a single, physical interface to hold multiple ports.  They are created using a "dot" - instead of Serial 0/0 we now have Serial 0/0.10.  Each subinterface can connect a PVC of its own, and the router treats each like a different port.

Frame Relay 101

It does seem to be a little silly to be reviewing Frame Relay in such depth for the 640-802 CCNA exam, but I suppose that's one of the reasons Cisco is retiring the exam and old guys like me are cramming to get this taken.  Anyhow...

Frame Relay is a technology that is packet-switched instead of cell-switched like ATM.  The fundamentals are that each router on either end of the Frame Relay circuit connects to the provider network, and there is a virtual circuit inside the provider network that makes those routers think they are directly connected.  Doing a traceroute from one end of the virtual circuit to another shows only one hop, even though there are undoubtedly several devices within the provider network the packet traverses.

The 3 Major Designs are:

1. Hub and Spoke - all branch offices connect to a central site.  The main benefit is cost savings, while the main sacrifices are redundancy and tandem switching (routing all traffic through the main hub)
2. Partial Mesh - key sites have multiple virtual circuit connections
3. Full Mesh - all sites connected to every other site, which is expensive.

 PVC (permanent virtual circuit) is an always-on virtual circuit, no set up time

SVC (switched virtual circuit) is an on-demand virtual circuit

LMI (Local Management Interface) is the language used for the provider to send status info about the state of the virtual circuit to the router

DLCI - because serial interfaces have no MAC address, they use a Data Link Connection Identifier to determine which interface with which to communicate.  DLCI numbers are locally significant in that, when traffic is destined for a remote IP address, it goes out a local DLCI instead of heading to a destination DLCI like in the case of using a MAC address. 

CIR (Committed Information Rate) is the minimum speed the provider promises to you at all times.  Each PVC has its own CIR, and anything over that minimum rate is marked "De" or discard eligible - which means it can be dropped if there is not sufficient bandwidth.

BECN (Backward Explicit Congestion Notice) alerts the sending device that it should slow down.  BECN goes away from the congested resource to the sending resources

FECN (Forward Explicit Congestion Notice) is data used to generate traffic back to the sender to tell it to slow down, and is sent to the receiving device by the FR provider.

PPP authentication and compression

PPP is a simple encapsulation to configure on Cisco routers, with the ability to add multiple features once enabled.  TO start, the only configuration necessary is to enter into the interface configuration mode and type:

R1(config-if)#encapsulation ppp

Do that on both sides of your WAN link and you're good to go.

The CCNA exam requires feature configuration for PPP links, however, and mainly CHAP authentication.  CHAP is an authentication method that sends MD5 hashes of a shared password between configured peers.  The configuration steps are:

1. Configure a hostname for both routers
2. Create a user on each router with the hostname of the peer, being certain the hostname is case-correct.  Also be certain that the password is identical for both peers.  As stated above, username and password are both case sensitive
3. Enable ppp encapsulation on the interfaces of both peers
4. Enable CHAP authentication on both peers

Voila, that's it.  Before you enable authentication on both sides, a debug will show:

 R2(config)#
*Mar  1 00:09:57.055: Se0/0 PPP: Authorization required
*Mar  1 00:09:57.075: Se0/0 PPP: No authorization without authentication
*Mar  1 00:09:57.075: Se0/0 CHAP: I CHALLENGE id 1 len 23 from "R1"
*Mar  1 00:09:57.091: Se0/0 CHAP: Unable to authenticate for peer
*Mar  1 00:09:58.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down

And the other troubleshooting step would be to show the brief interface statistics:

R2#sho ip int brie
Interface       IP-Address   OK? Method Status      Protocol
FastEthernet0/0 10.2.1.1        YES manual up       up 
Serial0/0       192.168.2.2     YES manual up       down
FastEthernet0/1 10.20.1.1       YES manual up       up 
Serial0/1       192.168.3.1     YES manual up       up 

Here you see on Serial0/0 that we have a status "up" and Protocol "down" which is the classic case of layer 1 being satisfactory but layer 2 is the problem.  This is always an issue with the L2 protocol, whether it is a mis-matched encapsulation type or misconfigured authentication or compression.

Compression

Configuring compression on a PPP connection is quite simple, also.  The caveat is that you need to do it on both ends or the link will once again fail (you will see this with an up/down status on the connected interfaces).  

Random thoughts on WAN connectivity

Reviewing WAN connectivity this morning.  Here are some items of interest to me...

T1 interfaces use an RJ-48 connector.  While looking like an RJ-45, the RJ-48 uses STP cabling, a different pinout and voltages.  Don't be fooled!


PPP replaced SLIP and offers encrypted authentication and support for protocols other than TCP/IP.

ATM is cell switched while Frame Relay is packet switched.

PPP Sub-layers:

1. ISO HDLC:  common ground for devices using PPP, enables base features of PPP
2. LCP (Link Control Protocol):  Where all PPP features are enabled.  These are:
• Authentication - PAP or CHAP
• Compression
• Stacker - replace continuous streams with codes
• Predicter - replace data with indexed codes
• Multilink - bundle multiple lines into a single management, load-balanced line
• Callback - security method to dial remote users back at a predefined number
3. NCP (Network Control Protocol):  common interface for L3 protocols

Random items of review regarding Access Control Lists

Just a few things I picked up yesterday that I wanted to jot down before I forget again:

1. Fast path switching in NAT/PAT is indicated by an asterisk when running a show ip nat translations command.  This has nothing to do with NAT, but indicates that the switching was done based on the initial packet asks for a port and subsequent packets use that same port.
2. access-group is used in applying ACLs to an interface, access-class is used in applying ACLs to lines
3. Dynamic Access lists allow a router to create an ACL based on user credentials.
4. Limit the number of telnet sessions in the line command, such as line vty 1 to limit to a single session
5. Static NAT allows connections from the outside and are always in the NAT table
6. Always pay attention to the source and destination in an ACL, especially where ports are concerned - do not limit based on source port, but rather on destination.
7. Extended ACLs should be placed on the interface nearest the source, whereas standard ACLs should be placed nearest the destination.

More thoughts as they arrive...

Random ACL thoughts and things I want to remember

Some thoughts on ACLs, as well as some commands to review:

distribute-list <#> [ in | out] - permit or deny routing protocols from adding a network into the routes propagated

Standard ACLs:  1-99, 1300-1999
Extended ACLs:  100-199, 2000-2699

A Cisco router removes the host inverse mask (0.0.0.0) from an ACL when doing a show running-config, because anything without a mask is assumed to be a host.

Apply standard ACLs on the interface closest to the destination.

An empty ACL allows all traffic.

When working on a router or firewall remotely, start with the reload in command to reload the device  autmatically in case an error is made and everyone is locked out.  Then cancel the reload to remove the reload command before the timer is up if everything is working correctly:

reload in 5
reload cancel


When configuring extended ACLs, be cautious about the source port and its placement.  Entering port numbers after the source IP, you only filter that source port.  Leaving source port information off the ACL means to assume all source ports

Best practice is to apply extended ACLs on the interface closest to the source.  This is directly contrary to the best practice for standard ACLs.

(Standard near destination, Extended near source)

Use the established keyword to allow any packets with an ACK or RST through.  This is commonly applied on the Internet interface inbound to allow any sessions initiated from the LAN back through the router.

A named ACL can have a single line deleted without removing the entire ACL.  One major difference is that the named list must be prepended with the ip keyword.

A Cisco router creates entries in a named ACL starting at line number 10 and incrementing by 10.

resequence allows you to move an ACL line from one number to another.

More thoughts as they come to me...

Show commands for ACLs

Some "show" commands for quick reference:

show ip interface  -  IP settings, ACLs applied, NAT configuration

show int - Interface config, stats, encapsulation, errors at L2

show access-lists, show ip access-lists - simply list ACLs, these are the same

Static NAT Cheat-sheet

Static NAT - Port Translation

1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Define NAT using static keyword and assign port only

Example:

R2#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int ser 0/0
R2(config-if)#ip nat outside
R2(config-if)#int fa 0/0
R2(config-if)#ip nat inside

R2(config)#ip nat inside source static tcp 10.2.1.10 80 192.168.2.2  80


Verify:

R2#sho ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.2.2:80     10.2.1.10:80       ---                ---

R2#debug ip nat
IP NAT debugging is on
*Mar  1 00:39:46.131: ipnat_add_static_cfg: id 3, flag 6
*Mar  1 00:39:46.135: id 3, flags 0, domain 0, lookup 0, from_addr A02010A, from_mask FFFFFFFF, from_port 50, to_addr C0A80202, to_port 50 to_mask FFFFFFFF, proto 6
*Mar  1 00:40:20.575: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39818]
*Mar  1 00:40:20.623: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar  1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39819]
*Mar  1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39820]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20303]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20304]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20305]
*Mar  1 00:40:20.655: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39821]
*Mar  1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20306]
*Mar  1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20307]
*Mar  1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39822]
*Mar  1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13399]
*Mar  1 00:40:20.703: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39823]
*Mar  1 00:40:20.723: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar  1 00:40:20.723: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39824]
*Mar  1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13400]
*Mar  1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13401]
*Mar  1 00:40:20.743: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20308]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50985]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50986]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50987]
*Mar  1 00:40:20.771: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13402]
*Mar  1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50988]
*Mar  1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50989]
*Mar  1 00:40:20.791: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13403]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50990]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50991]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50992]
*Mar  1 00:40:20.803: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13404]
*Mar  1 00:40:20.815: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13405]
*Mar  1 00:40:20.823: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13406]
*Mar  1 00:40:20.835: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13407]
*Mar  1 00:40:20.843: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13408]
*Mar  1 00:40:20.851: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50993]
exit
R2#no debug all
All possible debugging has been turned off
R2#

Dynamic NAT cheat-sheet

Dynamic NAT - translate one subnet to a pool of addresses, often used when combining two networks with overlapping subnets.

1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Create pool of addresses to use for NAT
4)  Create standard ACL for inside subnet
5)  NAT statement using ACL and pool as source and destination

Example:

R1(config)#int fa 0/0
R1(config-if)#ip nat inside
R1(config-if)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#exit

R1(config)#ip nat pool POOL2 192.168.2.200 192.168.2.225 prefix-length 24

R1(config)#access-list 1 permit 10.1.1.0 0.0.0.255

R1(config)#ip nat inside source list 1 pool POOL2
R1(config)#end


Verify:

R1#debug ip nat
IP NAT debugging is on
R1#
*Mar  1 00:16:55.147: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:55.163: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:55.647: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52471]
*Mar  1 00:16:55.667: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52471]
*Mar  1 00:16:56.155: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:56.167: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:56.655: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52472]
*Mar  1 00:16:56.679: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52472]
*Mar  1 00:16:57.131: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:57.159: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:57.699: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52473]
*Mar  1 00:16:57.699: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52473]


sho ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.2.200:6659 10.1.1.10:6659    192.168.2.2:6659   192.168.2.2:6659
--- 192.168.2.200      10.1.1.10          ---                ---
icmp 192.168.2.201:63436 10.1.1.100:63436 192.168.2.2:63436  192.168.2.2:63436
icmp 192.168.2.201:63692 10.1.1.100:63692 192.168.2.2:63692  192.168.2.2:63692
icmp 192.168.2.201:63948 10.1.1.100:63948 192.168.2.2:63948  192.168.2.2:63948
icmp 192.168.2.201:64204 10.1.1.100:64204 192.168.2.2:64204  192.168.2.2:64204
icmp 192.168.2.201:64460 10.1.1.100:64460 192.168.2.2:64460  192.168.2.2:64460
--- 192.168.2.201      10.1.1.100         ---                ---

NAT Overload cheat-sheet

NAT Overload:
1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Create standard ACL to permit inside (LAN) subnet
4)  NAT statement with overload keyword

Example:

R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#int f
*Mar  1 00:02:51.727: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to upa 0/0
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#ip access
R1(config)#ip access-list standard INSIDE_VLAN1
R1(config-std-nacl)#permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)#exit
R1(config)#ip nat inside source list INSIDE_VLAN1 int ser 0/1 overload

Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar  1 00:05:47.823: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar  1 00:05:47.835: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
*Mar  1 00:05:48.807: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar  1 00:05:48.819: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]

Multicast addresses

Because a quick reference is always good for review:

224.0.0.2 - all routers on this subnet
224.0.0.5 - OSPF all routers
224.0.0.6 - OSPF DR/BDR
224.0.0.9 - RIPv2 all routers
224.0.0.10 - EIGRP all routers