Tài liệu CCIE notes from experience pdf

The
summary-only
keyword only appears to suppress more specific routes
that are within the natural class defined by the aggregate address and
mask. That is, you can specify an address/mask that is larger than its
natural mask. The exact
address/mask you specified will get propagated
via BGP, however it will only suppress more specific routes within its own
natural address class.
Bridging
For bridging over Frame-Relay, there are no special requirements if all
interfaces are point-to-point. However for Frame Relay (or ATM) physical
or multipoint interfaces, you need one
frame-relay map bridge dlci
broadcast
command for each DLCI that’s part of physical or multipoint
interfaces. However, note that for physical and multipoint interfaces, the
router will not forward packets out the same physical or multipoint
interface that bridge packets were received on (regardless of all else,
including Spanning Tree)!

Spanning Tree
The root bridge is determined by the lowest bridge priority – set by the
global
bridge priority
command.

On each subnet a designated bridge is elected. This is the bridge that will
have the forwarding path to the root. The bridge with the lowest cost path
to the root will be the designated bridge (and thus will be forwarding). In
the case where two or more bridges have the same path cost to the root,
the bridge with the lowest priority becomes the designated bridge.

The path cost is calculated by adding the “outbound” path costs of all
paths to the root
. That is, path costs are added as you are leaving each
router on the way to the root (the path cost as you enter a router is
irrelevant).

All non-root bridges will have exactly one root port. These listen for
BPDUs from the root bridge. Non-root bridges will send BPDUs out all
their designated ports. For all non-root bridges, if a port is not a root port
and not a designated port, it is a blocked port.

Port priority is almost never used. The only time this might be used is if
two non-root bridges had redundant links between them. One of the four
ports for those two links would have to block – port priority would allow
you to control which one it was. If you don’t set this on any of the four, the
IOS will select one to block (but how? Who cares?).

IRB/CRB
5

With CRB for a given protocol (IP or IPX), there will be a group of routed
interfaces and a group of bridged interfaces. The routed interfaces each
get an IP (and IPX) address and can route to any other routed
interface –
but not to the group of bridged interfaces. The bridged interfaces can
bridge between each other, but not route to the routed interfaces (the
bridged interfaces don’t even get an IP or IPX address). CRB is not terribly
useful.

With IRB you may have the same set of routed and/or bridged interfaces,
but you can easily establish connectivity between them.

When you configure IRB or CRB you have four choices for each protocol:
1. bridge 1 route ip
bridge 1 bridge ip
Use this to bridge the protocol among interfaces within the bridge
group, but route it to all other interfaces. (Very common). For
interfaces within the IRB bridge-group 1, configure the protocol
information on
int bvi1
, not on the “real” interfaces.
2. no bridge 1 route ip
bridge 1 bridge ip
Use this to bridge the protocol among interfaces within the bridge
group, but not route it to any interfaces outside of the bridge group.
Do not configure protocol information on
int bvi1
or on the “real”
interfaces within the bridge group.
3. bridge 1 route ip
no bridge 1 bridge ip
Use this to route the protocol among all interfaces – within the
bridge group and outside the bridge group. Configure the protocol
information on all the “real” interfaces (within and outside the bridge
group) but not on
int bvi1
. This is common when you want to
route one protocol (like IP) but bridge another (like IPX).
4. no bridge 1 route ip
no bridge 1 bridge ip
You would probably never use this. This would ‘turn off’ the protocol
for the entire bridge group – you would not bridge it between
interfaces in the bridge group, nor would you route it to any
interfaces outside the bridge group.
Debug
If you need to use
debug ip packet [detail] [access-list]
, remember
that only packets that are processed switched will get debugged. To
disable fast switching (and force process switching) use
no ip route-
cache
on each interface (especially the incoming interface for the packets
in question).
Dial
My dial strategy is going to be to use the simplest (most dependable)
solution unless directed otherwise. My order of preference for IP will be:
6

1. Floating Static Routes
2. IP OSPF Demand Circuit
3. Dialer Watch
4. Snapshot routing
5. Dial Backup

My order of preference for IPX will be:
1. Floating Static Routes
2. Tunnel IPX through IP (especially effective if using 1, 2 or 3 above)
3. Snapshot routing
4. Dial Backup

The 2503’s and 2504’s typically have an S/T ISDN interface. A 2524 often
will have a U.

Floating Static Routes
For IPX to use a static, default route, the WAN (i.e., ISDN) must use
IPXWAN! IPXWAN needs an internal-network number first!

SnapShot Routing

Remember, snapshot routing only works with RIP (IP), IGRP (IP), RIP and
SAP (IPX).
Even with Snapshot routing you still need the same old dialer map
statements that you always have (typically)…plus one or more for
snapshot.

PPP Authentication
You want to indicate
ppp authentication chap
under the physical
interface (dialer maps) or the physical and logical interface (dialer
profiles). If you don’t want one side to use chap (if you don’t want that
router to challenge the other) omit the ppp authentication chap
. However
if the opposite router has ppp authentication chap, you must have the
other router’s name & password in your database.

For PAP authentication, you need the same config as with CHAP, yet also
the receiving router seems to also need a
ppp pap username r4 password
0 cisco
, where r4 is that router’s own hostname and cisco is the
password.
Distribute Lists

* Try adding the word log at the end of an access-list statement to log
what is happening with the access list.

7

Distribute lists “in” block routes from the routing table, but not the (OSPF
or other) database. This will block the routes from appearing in that router,
but not in other routers that run (OSPF or other) and get the same Link
State Database.

Distribute lists “out” are typically much more effective from blocking a
route from a large portion of the network. However with OSPF
distribute-list out
only works on External Type 1 or 2 routes – not with
internal OSPF routes.

Distribution lists may not take effect immediately. You may have to bounce
the interface or do a clear ip route *
to activate them.

The distribute-list list# out process
is very tricky. For example:
2501b(config)# router ospf 103
2501b(config-router)#distribute-list 16 out eigrp 1

It would appear that this would regulate what ospf sends out to eigrp 1.
But instead it controls what OSPF receives in from EIGRP 1 (or, more
aptly, what EIGRP sends out
to OSPF).

DLSw
Here is a brief overview of the types of DLSw transports:

DLSw also uses noncanonical (T.R.) format for mac addresses.

DLSw will automatically convert between Ethernet and Token Ring
stations if
they are located on different routers. In order to get Ethernet
and Token Ring stations to communicate on the same router, SR-
Translational bridging must be enabled.

TCP
– probably the most robust DLSw implementation – recommended.
FST
– does not perform local acknowledgement, supports Token Ring
only, fewer queuing options.
Direct
– supports HDLC and Frame-Relay only, fewer queuing options (No
IP encapsulation).
LLC2 (lite)
– less overhead but also less rerouting, Frame-Relay only.

DLSw chooses 1 path by default, but can be configured to use multiple
paths.

DLSw can choose paths based on cost. Cost in a local-peer statement is
what is advertised out to all remote peers. Cost in a remote-peer
statement sets the cost to connect to that peer.

8

DLSw can limit the MTU size (handy going from TR to Eth) using the
lf
1500
keyword and value on the
remote-peer
statement.
Filtering
With
dlsw prom-peer-defaults
and
dlsw peer-on-demand-defaults
all
filters (dmac-output-list, host-netbios-out, lsap-output-list, etc.) are
outbound to other peers (not outbound to the LAN interface).

With
dlsw remote-peer
statements all filters (dmac-output-list, host-
netbios-out, lsap-output-list, etc.) are outbound to other peers (not
outbound to the LAN interface).

A local DLSw peer can specify dlsw remote-peer 1 tcp 10.10.10.10
.
This command refers to list 1. It can be port list 1, ring list 1 and/or bgroup
list 1. This command limits what the remote peer (in this case 10.10.10.10)
can access locally (on the peer on which it is defined).

Border Peers/Peer Groups
By default for DLSw to have “full mesh” connectivity, you need a full mesh
of DLSw connections. The exception is peer groups. With peer groups you
can group DLSw routers into groups. Within a group each router only
needs a connection to the bordrer peer(s). The border peer forwards
broadcasts to all other peers within the group as well as any other border
peers (from different groups) that are configured (basically acting like a
BGP route reflector). Once the explorer finds its destination, a connection
is setup router ÅÆ router (listed in the routers as peer-on-demand, or
simply pod), even if the routers are in different groups.

Usually in this case use promiscuous peering. That is, all routers will likely
need to be configured to accept any connection (promiscuous) since they
could be getting connections from many routers.

Note:
in the above scenario you will get promiscuous peers and pod (peer
on demand) peers. To filter these use dlsw prom-peer-defaults
and
dlsw
peer-on-demand-defaults
to filter! Remember – these filters are
outbound to other peers!

TCP connections
DLSw sets up connection on TCP ports 2065 and 2067. DLSw allows for a
TCP connection to be built using one of these ports (likely 2065) in each
direction. However if the DLSw routers can accommodate only one bi-
directional connection (this will almost always be the case for Cisco
routers), one TCP connection gets torn down. The router with the higher
DLSw peer IP Address tears down the connection. Watch this if you have
to NAT a DLSw peer address! Also its best to allow TCP 2065/2067 both

ways through an access-list, even if the “steady state” DLSw coinnection
will only require it in one direction.
9

EIGRP
If you have to run EIGRP over a dial interface, I recommend using
dialer
watch-group
.

For NBMA topologies (Frame-Relay, ATM) EIGRP can have split-horizon
disabled for spoke-spoke reachability (true for both IP and IPX).
Frame Relay
If you see a PVC with the status of “deleted,” it probably means you typed
in an interface-dlci 100
command, but the frame switch is not
announcing (and doesn’t know about) that DLCI – check DLCI.

If you see a PVC with the status of “inactive,” it probably means the local
router’s connection to the frame switch is fine, but there is a problem with
the ‘far’ end of the PVC. Check the router that is supposed to terminate
the PVC.

If you use a
frame-relay map
statements, you don’t need
frame-relay
interface-dlci
command(s) (unless you need to do traffic shaping). It
may be a good idea to only use the map statements.

In Frame Relay you may want to place a map statement for your own IP
address so that you can ping it (or ask the proctor if this is necessary).

Inverse Arp and Mapping

Frame Relay needs a way to connect, or map, a Layer 3 address (IP or
IPX address) with a particular Frame Relay DLCI. That is, when a router
attempts to forward packets to an IP or IPX address it needs to know out
which virtual circuit – specified by a Frame Relay DLCI – the packet
should be forwarded.

In some cases (such as where two routers are connected by a single
virtual circuit, i.e., a single DLCI) the routers can use inverse-arp to
determine the Layer 3 (IP or IPX) address at the opposite end of the
virtual circuit. However in other cases, such as two “spoke” Frame Relay
sites connected by one “hub” Frame Relay site, the two spoke can not use
inverse-arp to learn each other’s Layer 3 addresses. This is because
inverse-arp packets are never forwarded (in this example, they are not
forwarded by the “hub” router).

In these cases it is common to manually map (define) each Layer 3
address the router can reach to a specific DLCI (virtual circuit). Using sub-
interfaces is an easy way to avoid doing this, but when does the CCIE
exam ever take the easy way?

10

Also, if you perform mapping on a router, it is best to map every router,
including the hub router. Even if connectivity exists between that router
and the hub router, if you are mapping other remotes make a habit of
mapping the hub router as well. In some version of IOS inverse-arp is
disabled once a Frame Relay mapping occurs, however the problem this
poses is often not apparent until the next reboot.

The way this can occur is as follows: suppose router A is a “spoke” router
connecting to router B. Router C is also a spoke router that connects to
router B. Router A uses inverse-arp to map router B’s IP address to a
particular DLCI. However router A can not inverse-arp for router C’s IP
address as discussed. A map statement is placed in router A for router C.
Everything works great since you router A has the two mappings it needs:
a dynamically learned one for router B (via inverse-arp) and a manually
learned one (via a map statement) for router C.

However with some versions of code the map statement disables inverse-
arp. Thus once the router is rebooted is loses its dynamically learned
mapping for router B. Since the map statement has disabled inverse-arp,
connectivity is lost. Thus, to be safe if you are performing map statements.
add one for each router in the Frame cloud.
11


Central Site Frame Relay
router
Remote Site Frame Relay router
Interface Issues Interface Issues
No
subinterfaces
May need to disable IP/IPX
split horizon.
No subinterfaces Need a frame-relay map statement
for
all
neighbors. Need ip ospf
priority 0 on all remotes. Need to
enable IP, IPX split horizon.
No
subinterfaces
OSPF network type mismatch
– probably have to use ip ospf
network point-to-multipoint to
make it work. May need to
disable IP/IPX split horizon.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch – probably have to use ip
ospf network point-to-multipoint to
make it work.
No
subinterfaces

Very unlikely configuration.
May need to disable IP/IPX
split horizon.
Multipoint
subinterfaces
Need frame-relay interface-dlci
command. Need either:
• On remotes: a frame-relay map
statement for
all
neighbors
and ip ospf priority 0, or
• ip ospf network point-to-
multipoint everywhere.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch.
No subinterfaces OSPF network type mismatch – set
remotes to ip ospf network point-to-
point. Remotes will be on different
subnets. Need to enable IP, IPX
split horizon.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch.
Very unlikely configuration.

Multipoint
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch – set remotes to ip ospf
network point-to-point.
Multipoint
subinterfaces
Need frame-relay interface-dlci
command. Need to disable IP,
IPX split horizon.
No subinterfaces Need a frame-relay map statement
for
all
neighbors. Need ip ospf
priority 0 on all remotes. On 11.3
and lower, need ip ospf network
point-to-multipoint or statically
defined OSPF neighbors. Need to
enable IP, IPX split horizon.
Multipoint
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch – probably have to
use ip ospf network point-to-
multipoint to make it work.
Need to disable IP, IPX split
horizon.
Point-Point
subinterfaces
Need frame-relay interface-dlci
command. OSPF network type
mismatch – probably have to use ip
ospf network point-to-multipoint to
make it work.
Multipoint
subinterfaces
Need frame-relay interface-dlci
command. Need to disable IP,
IPX split horizon.

Very unlikely configuration.

Multipoint
subinterfaces
Need frame-relay interface-dlci
command. Need either:
• On remotes: a frame-relay map
statement for
all
neighbors
and ip ospf priority 0, or
• ip ospf network point-to-
multipoint everywhere.

When configuring your
frame-relay map statements, don’t forget the
broadcast at the end! For bridging, have the “hub” frame relay router be
the root of the spanning tree! For ISIS, add a frame-relay map clns dlci
broadcast
command!

12

OSPF
A Frame Relay interface (not a subinterface) defaults to OSPF network
type of nonbroadcast
(NBMA). If using the default non-broadcast network
type, be sure to set ip ospf priority 0
on all remotes.


A Frame Relay point-to-point subinterface
defaults to OSPF network type
of point_to_point
.

A Frame Relay multipoint subinterface defaults to OSPF network type of
nonbroadcast
(NBMA).

If you use point-to-point subinterfaces at one end of a PVC and no
subinterfaces at the end, you must account for the type mismatch. For
example, use
ip ospf network point-to-point at the end not using
subinterfaces. If you use a combination of physical and multipoint
subinterfaces, use
ip ospf network point-to-multipoint.


If you can’t use broadcasts (as with the frame relay map statements or if
you must use ip ospf network point-to-multipoint non-broadcast
, for
example) you must manually define OSPF neighbors with the neighbor
statement.
Getting Started Checklist
It is easy to gather enough information about the lab to be able to prepare
a “getting started” checklist. This is a list of the first steps to take on the
morning of the first day of the lab. Here is my list, in order:
1. Read the lab exam twice. Yes, twice. Don’t skim it and read it –
read it
twice. Make a list of:
a. Hidden issues and pitfalls
b. Your strong and weak areas
2. In between the first and second readings, configure the terminal
server to connect to every router and switch in your rack. Make r1
the first connection, r2 the second connection, etc. Make the
switches the last connections.
3. Check and record the IOS version, IOS image (name – feature set)
and interfaces on each router.
4. Unless they are in the initial configuration script, write erase &
reload each router. This will assure a clean start. It will also verify
that they will reload properly – you don’t want to discover they have
a problem rebooting at 3:30! If you do this in between readings, the
routers will have plenty of time to reload.
5. Create an IP address matrix. Don’t waste time making something
that can be hung at the Museum of Fine Arts when you’re through.
Just make a very simple line for each major network. Create major
13

divisions – 64, 128, 192, etc. Write down each address that is
required and each one that you select.
6. Begin cabling the routers per the lab.
7. In notepad enter all commands that will be entered into every
router.
8. Configure the routers with the above commands as well as all
“layer 2” commands. Verify:
a. Show isdn status yields
“MULTIPLE_FRAME_ESTABLISHED”

b. Verify all interfaces are up, up
c. Verify all Frame-Relay PVCs are
LOCAL and ACTIVE
IGRP
When changing the distance on IGRP you should perform a
clear ip
route
. Otherwise IGRP seems to wait until the routes clear naturally
(holddown, etc.) before they are reinstalled with the new distance.

IGRP does not exchange the default route (0.0.0.0) as most of the other
protocols do. If you must have a default route with a router running IGRP,
use:

ip default-network 172.16.0.0

where 172.16.0.0 is a classful
network. This classful network (not a
subnet) must be in your routing table. It also must be part of the IGRP
process (either via the network statement or redistribution). This will cause
this router to generate a candidate default route via IGRP.

Remember, IGRP has a lower admin distance than OSPF. That’s probably
not what you want!!
IKE
IKE is the Internet Key Exchange standard and is usually performed using
the ISAKMP protocol. IKE is often used with IPSec because it automates
key management and controls the security associations that are formed,
though IKE is not required for IPSec. IKE policies define five things:
• encryption algorithm (such as des)
• hash algorithm (such as sha or md5)
• authentication method (such as rsa-sig, rsa-encr or pre-share)
• Diffe-Hellman group (such as group-1 (768-bit) or group-2 (1024
bit))
• security association lifetime (in seconds)
All of these have defaults (and the defaults can be used) except
authentication – that must be specified. Pre-share is by far the easiest
authentication method. Rsa-sig authentication requires a certificate
authority (and thus is very unlikely to be on the CCIE Lab). These
parameters affect the data that flows between hosts during the IKE
14

Xem chi tiết: Tài liệu CCIE notes from experience pdf