Cisco Network part 88 pdf

From: Question 56
Subject: What does Frame-relay LMI and Encapsulation really do/mean?
I think there is some confusion here about frame relay "encapsulation" and frame
relay "lmi" (heartbeat/keepalives). Frame relay encapsulation is indeed significant
end-to-end through the "cloud" between communicating DTE (router) equipment.
Cisco encapsulation inserts an ethernet "type field" immediately after the 2 byte
frame header which contains the DLCI, FECN, BECN, and DE fields. IETF (RFC
1490) encapsulation does not use ethernet type fields to identify the payload of the
frame. Instead, IETF calls for the use of NLPID codes (Network Layer Protocol
Identifiers) which are common in the OSI environment.
NLPIDs are to be used when the payload has an NLPID assigned to it.(like IP) The
NLPID (CC, in the case of IP) will follow an Unnumbered Information UI control
field, 03. If the payload does not have an NLPID assigned to it, (like IPX) then
IETF suggests that an OUI field (organizationally unique identifier) followed by an
ethernet type code (8137 for example, if IPX) will be used. Much like an 802.3
frame with SNAP, the type code of 8137 will be offset further into the frame, and
not found immediately after the 2 byte frame header.
This encapsulation must be understood by the communicating routers at either
edge of the 'cloud.' The cloud itself does not care what type of "encapsulation" is
being used. It is strictly a DTE-DTE issue.
LMI is a link intergrity and PVC status verification protocol that IS locally
significant between the router and the network interface. This protocol comes in 3
flavors: the 'original' Stratacom' (aka cisco) version, ANSI's T1.617 Annex D, and
CCITT/ITU Q.933 Annex A. These protocols are often collectively referred to as
"LMI." It is possible to run one version of LMI on the East User-Network
Interface (UNI) and another version on the West UNI, as these protocols simply
identify the status of the UNI link and the PVCs found on that link. Encapsulation,
however, must match between the DTEs. It is interesting to note, however, that
Cisco routers are smart enough to interpret the 'encapsulation' type being used on
incoming frames. If both DTEs are Cisco routers, one router 'can' use Cisco
encapsulation while the other router uses "IETF." The ability to communicate with

Cisco routers using different encapsulation schemes gives the "appearance" that the
encapsulation is locally significant. In fact, this (cisco) ability to
communicate is made possible by the smarts cisco builds into its implementation.
When any other vendor's DTE is involved, communications will fail if the
"encapsulation" on both DTEs is not identical. Even if one of the routers is a cisco.
(Unless, of course, the other vendor saw fit to build in the smarts that cisco has
done. But I am not aware of any vendor that has this capability other than cisco )
Hex protocol traces are available if any one would like to see
******************************************************************
********
From: Question 58
Subject: How do I make a T1 Cross-over cable?
For *T1* I've used the following pinouts for crossovers:
T1/E1 crossover (for PRI and CAS back-to-back connection):
RJ-45 RJ-45
1 4
2 5
4 1
5 2
RJ-45 DB-15
1 1
2 9
4 3
5 11
DB-15 DB-15
1 3
3 1
9 11
11 9
For E1 (assuming RJ-48 aka RJ-45), the pinouts would be the same as for T1,

except that I guess you need to have pins 3 and 6 (shield/ground) connected.
I don't suppose I should be pointing people to Juniper's web site, but anyway
/>picinstall/html/pinout5.html
******************************************************************
********
From: Question 59
Subject: Can I use a router to simulate BRI switch?
In current IOS (12.1(3)T and above, I think), you can configure PRIs back-to-back
between routers: configure one side to be network side (isdn protocol-emulate
network) and the other to be user side (default; isdn protocol-emulate user). The
supported switchtypes are primary-net5
and primary-ni.
As the original posting had alluded, we have SOME support for network-side BRI
- but this is only on certain VIC cards due to hardware restrictions -

/121limit/121x/121xi/121xi_3/dt_brint.htm
******************************************************************
********
From: Question 60
Subject: How do I use Policy Based Routing?
Keep in mind that Policy routing works on the INBOUND interface. If you think
about it, it makes sense. The decision to hand off the packet has to be made as it's
coming into the router and not on the egress interface.
Determine who's eligible to be policy routed
access-list 1 permit 10.1.1.0 0.0.0.255
Figure out where you want to send the pkts based on the source IP
route-map RouteMeBaby permit 10
To whom shoud this policy apply to?
match ip address 1
Where should you redirect it to? Should use both. If one is

omitted, the value will be retrived from the routing table -
which may or may not be what you wanted
set ip next-hop ROUTER_2's_SERIAL_IP
set interface s0
interface E0
ip addr blah blah blah
ip policy route-map RouteMeBaby
If your IOS supports it, enable fast switching for PBR
ip route-cache policy
*IF* fast switching is supported (may be 11.3 an up or it could be 12.0
and up do a
sho ip cache policy
if not, do a
sho ip policy
******************************************************************
********
From: Question 61
Subject: How do I setup a VPN tunnel using pre-shared keys?
Dror-John is right. There is a LOT to know about when you get into encryption,
and like any other branch of this industry knowing the hows & whys will help your
configs and troubleshooting enormously. The CCO IPSec Product Support page
has a wealth of useful info and examples. www.cisco.com/pcgi-
bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
RFCs 2401-2412 are not too taxing either. I've added below a very basic example
using pre-shared keys, DES encryption and SHA-1 hashing algorithm. Site 1 is
10.0.1.0/24, site 2 10.0.2.0/24 and the serial i/fs 10.0.4.0/30 (& assumes you have
sub-i/fs). Names and things in capitals.
Router1(config)#
crypto isakmp policy 1
Define your ISAKMP policy settings

group 2
'group' defines the modulus for Diffie-Hellman calculation.
Default is group 1, less CPU work, but less secure.
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.2
Your shared key, and what peer i/f it's used for.
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
Define what happens to the traffic. AH & ESP are two IPSec protocols.
crypto map TO_SITE_2 10 ipsec-isakmp
Define crypto-map
set peer 10.0.4.2
The other side
set transform-set TS1
Which transform-set to use
match address 150
What traffic to include
interface Serial1/0.0
ip address 10.0.4.1 255.255.255.252
crypto map TO_SITE_2
Apply the crypto-map to the i/f
access-list 150 permit ip 10.0.1.0 0.0.0.255 any
Include traffic coming from here. I've said anything going out, for
there may be places beyond Site 2, but Cisco says this can cause
problems for multicast traffic. This also assumes no traffic will be
going to Site 2 from somewhere else _through_ Site 1. Perhaps
best to err on the more specific side. However it is a good idea
to not include your serial i/fs, so you can still get at the far router
if there's a problem.
Router2(config)#
crypto isakmp policy 1

group 2
authentication pre-share
crypto isakmp key SHARED_KEY_HERE address 10.0.4.1
crypto ipsec transform-set TS1 ah-sha-hmac esp-des
crypto map TO_SITE_1 10 ipsec-isakmp
set peer 10.0.4.1
set transform-set TS1
match address 150
interface Serial1/0.0
ip address 10.0.4.2 255.255.255.252
crypto map TO_SITE_1
access-list 150 permit ip 10.0.2.0 0.0.0.255 any
******************************************************************
********
From: Question 62
Subject: Why does one packet always get dropped on the last hop of traceroute?
And the winner is Max. Inspired by (I think) sec. 4.3.2.8 in RFC-1812, we rate-
limit our ICMP message generation to 1/sec/destination. This can be adjusted by
the "ip icmp rate-limit unreachable" command. More interesting than simply
causing an oddity for traceroute, ICMP rate-limiting can cause intermittent
PMTUD blackholes (or I should say perhaps "PMTUD brownholes".) If you're
doing PMTUD (as alas anyone running Windows defaults to), then you might want
to ease the rate limit on DF unreachables.
******************************************************************
********
From: Question 63
Subject: How to setup NATing based on outgoing interface to two different ISPs.
> ISP1 CableModem
> \ /
> \ /

>
> Cisco 2621
> |

> | |
> Firewall Mail Server
> |
>
> Company LAN
> > We just installed a T1 to the Internet to co-exist with our Cablemodem. I
> am looking at ways to implement this. We currently have a Cisco 2621 with
> the T1 connection and a Linux Box Masqing cablemodem Internet access now.
> My question is, what would be the best way to implement this?
>
> I proposed we connect the Cablemodem into the 2621 (FEthernet interface)
> next to the T1 connection (separate ISP's btw) and NAT.
That will work. But you need to use route-maps to match the outgoing interface
(or next-hop) when you define your NAT pool. In a nutshell