Cisco ICND2 – Troubleshoot WAN implementation issues

Somethings to look out for when troubleshooting WAN implementation issues:

  • Mismatched IPs
  • debug ppp authentication – Will show if any authentication issues (password mismatch)
  • Encapsulation mismatch – ppp and HDLC for example
  • show cdp neighbors detail
  • show frame-relay lmi
  • show frame-relay map
  • show frame-relay pvc
  • show running-config
  • show interface s0
  • Frame relay encapsulation mismatch
  • debug frame-relay lmi

Cisco ICND2 – Configure and verify Frame Relay on Cisco routers

  • Packet-switching protocol
  • DCLI’s are local – layer 2 addressing. Not advertised to other routers
  • Permanent virtual circuit (PVC) – Dedicated circuit always up
  • Switched virtual circuit (SVC) – Temporary circuit that is only up for example during a data transfer session
  • Three LMI types cisoc, ansi and q933a
  • Local Management Interface (LMI) – passes information about the status of the circuit. Must match on the DCE (Provider) and DTE end
  • non-broadcast multi-access (NBMA) – broadcasts are not sent over frame-relay by default
  • inverse ARP – Used to allow dynamic mapping. On by default can be turned off using no frame-relay inverse-arp
  • Split horizon – Stops rouging updates such as RIP from being sent out of the same interface it was received on. Turning off split horizon may cause routing loops
  • Sub-interfaces can overcome the split horizon by creating sub interfaces out of a serial interface. This gets around the problem of a routing update being sent and received out of the same interface. Sub-interfaces can either be point-to-point or multipoint

Show commands:

  • show frame-relay map – Table of frame maps, shows dlci and lmi information
  • show frame-relay lmi – Shows configured LMI type, if timeouts occur and increase could indiciate a lmi mis-match
  • show frame-relay pvc – Shows BECN and FECN information

Debug commands:

  • debug frame-relay lmi – myseq increments but yourseen doesn’t indicates lmi mismatch

Frame relay point-to-point

Frame_Relay_P2P

R1:

interface Serial2/0
no ip address
encapsulation frame-relay

interface Serial2/0.301 point-to-point
ip address 10.0.1.1 255.255.255.0
frame-relay interface-dlci 301

interface Serial2/0.302 point-to-point
ip address 10.0.3.1 255.255.255.0
frame-relay interface-dlci 302

router rip
network 10.0.0.0

R2:

interface Serial2/0
no ip address
encapsulation frame-relay

interface Serial2/0.102 point-to-point
ip address 10.0.2.2 255.255.255.0
frame-relay interface-dlci 102

interface Serial2/0.103 point-to-point
ip address 10.0.1.2 255.255.255.0
frame-relay interface-dlci 103

router rip
network 10.0.0.0
network 192.168.0.0

R3:

interface Serial2/0
no ip address
encapsulation frame-relay

interface Serial2/0.201 point-to-point
ip address 10.0.2.1 255.255.255.0
frame-relay interface-dlci 201

interface Serial2/0.203 point-to-point
ip address 10.0.3.2 255.255.255.0
frame-relay interface-dlci 203

router rip
network 10.0.0.0
network 172.16.0.0

Frame relay multipoint

Frame_Relay_Multipoint

R1:

interface Serial2/0
ip address 10.0.1.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.0.1.2 301 broadcast

router rip
network 10.0.0.0

R2:

interface Serial2/0
ip address 10.0.1.2 255.255.255.0
encapsulation frame-relay

router rip
network 10.0.0.0
network 192.168.0.0

R3:

interface Serial2/0
ip address 10.0.1.2 255.255.255.0
encapsulation frame-relay

network 10.0.0.0
network 172.16.0.0

Cisco ICND2 – Troubleshoot NAT implementation issues

Here are some NAT troubleshooting tips:

  • show ip nat translations
  • show running-config
  • show ip nat statistatics
  • debug ip nat
  • clear ip nat translations *
  • Check inside and outside are placed on the correct interfaces
  • Ensure the natpool covers the correct range of IPs
  • Check the name of the pools are matched – I made a typo during testing and as a result NAT didn’t work
  • Ensure the access-list is configured correctly to allow translation

Cisco ICND2 – Configure Network Address Translation for given network requirements using CLI

Showing examples of Dynamic, Static and Nat overload.

NAT

Configuring NAT Overload on Router1:

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.224
ip nat inside

interface Serial0/1/0
ip address 62.0.0.2 255.255.255.0
ip nat outside

ip nat pool natpool 62.0.0.2 62.0.0.2 netmask 255.255.255.0
ip nat inside source list 1 pool natpool overload

access-list 1 permit 10.0.0.0 0.0.0.31

Configuring Static NAT on Router1:

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.224
ip nat inside

interface Serial0/1/0
ip address 62.0.0.2 255.255.255.0
ip nat outside

ip nat inside source static 10.0.0.2 62.0.0.2
ip nat inside source static 10.0.0.3 62.0.0.4

Configuring Dynamic NAT on Router1:

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.224
ip nat inside

interface Serial0/1/0
ip address 62.0.0.2 255.255.255.0
ip nat outside

ip nat pool natpool 62.0.0.3 62.0.0.4 netmask 255.255.255.0
ip nat inside source list 1 pool natpool

access-list 1 permit 10.0.0.0 0.0.0.31

Cisco ICND2 – Explain the basic operation of NAT

Network Address Translation allows private IPv4 addresses to be translated to an IPv4 public address to communicate over the Internet. This saves public IP addresses as not every device needs a public IP address and if we allowed that we would’ve run out of IPv4 addresses by now.

NAT allows multiple private IPv4 addresses to be translated to one public IP address, therefore saving public IP addresses.

There are three different types of NAT.

  1. Static NAT – This is a one-to-one translation, one private IP address will be translated to one public IP address
  2. Dynamic NAT – You don’t need to manually map each IP static with dynamic NAT but you do need to ensure you have enough public IPs for the private IPs to be translated to.
  3. Overloading (PAT) – This is a many-to-one translation, multiple private IP addresses will be translated to one public IP, kinda cool right? This is the reason we haven’t run out of IPv4 addresses yet.

Cisco ICND2 – Troubleshoot ACL implementation issues

Some tips when troubleshooting ACL:

  • Ensure correct IP and wildcast masks are correctly entered into the ACL
  • Ensure an access-group is applied to an interface
  • If no traffic is permitted, all traffic will be denied, there is an explicit deny.
  • Access-lists are read top to bottom, if a first match is found it will stop reading. So if a deny is specified it may block a permit statement. Order of ACL is important.
  • Remarks can be added to ACL to make reading them in future easier using the access-list <number> remark “This ACL blocks FTP”