Archive for December, 2007

Dec
29

Hi Brian,

How do I switch between devices when using a Cisco access server?

There are two ways to connect to devices attached to an access server, you can terminate your exec session on the access server itself (one terminal window for all sessions), or you can terminate your exec session on the device connected to the access server (one terminal window for each session). In the CCIE Lab Exam you will have the option to do either, so pick whichever method works best for you and stick with it during your preparation.

When you terminate your exec session on the access server you then “reverse telnet” to the individual devices connected to the access server. Normally to do this you first login to the access server and then issue the “show hosts” command to see the host mappings. Next, reverse telnet to them by typing the hostname and pressing enter. To get back to the access server issue the escape sequence CTRL-SHIFT-6-X. To do so hold ctrl and shift, hit 6, release all keys, then hit X. From the access server you can then open new connections or resume connections that you already have open.

When you terminate your exec session on the device connected to the access server, i.e. by telnetting to the access server at port 2001, you cannot issue the escape sequence to reconnect to the access server. In this situation you would open multiple terminal windows if you wanted to connect to multiple devices.

For more information watch this class-on-demand video on using an access server.

Dec
29

OSPF point-to-multipoint non-broadcast was designed to allow for the assignment of the cost on a per neighbor basis as opposed to using the interface’s cost. This
is useful on a multipoint Frame Relay interface where there are two neighbors advertising the same route but the CIRs for the DLCIs to reach each neighbor is different or these two neighbors that are advertising the same route have different port speeds to the Frame Relay network. Remember that the cost is based on your “incoming” interface’s bandwidth and not the bandwidth of the neighbor’s interface that connects to you.

As an example say we have two remote routers over Frame Relay and the remote routers are both connected to and advertising the same Ethernet segment. Our router is connected to these two routers via Frame Relay. One of the remote routers has a T1 Frame Relay connection and the other has a 64k Frame Relay connection. Since our cost to the Ethernet segment advertised by these two routers will be calculated based on the cost of the Ethernet segment plus the cost of our incoming interface, both routes appear to be equal cost. Obviously this is not what we would want. We would want to prefer the route from the router with the T1 connection over the 64k connection.

Here is an example with two remote routers advertising the same network (loopback interfaces):

Rack2R4#show ip ospf interface s0/0 | include Cost
  Process ID 1, Router ID 150.1.4.4, Network Type POINT_TO_MULTIPOINT, Cost: 64

Rack1R4#sho run int s0/0
interface Serial0/0
 ip address 154.1.0.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 154.1.0.3 403 broadcast
 frame-relay map ip 154.1.0.5 405 broadcast
 no frame-relay inverse-arp
end

Rack2R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 154.1.0.3 on Serial0/0, 00:00:30 ago
  Routing Descriptor Blocks:
  * 154.1.0.3, from 150.1.3.3, 00:00:30 ago, via Serial0/0
      Route metric is 65, traffic share count is 1
    154.1.0.5, from 150.1.5.5, 00:00:30 ago, via Serial0/0
      Route metric is 65, traffic share count is 1

As you can see both 154.1.0.3 (router-ID 150.1.3.3) and 154.1.0.5 (router-ID 150.1.5.5) are advertising the 150.1.0.0/24 network with an OSPF cost of 1 (total cost minus our interface’s cost, 65-64=1). If both of these routers have the same port speed to the Frame Relay network then this is what we would want to see, two equal cost paths. But if they have different port speeds, then we would want to prefer the route from the router with the higher port speed, theoretically. The problem is that OSPF does not take into account the cost of the remote router’s interface to us. We only take into account the cost of the loopback and our interface’s cost to reach the remote neighbor.

To prefer the route from the router with the higher port speed, we are going to use OSPF point-to-multipoint non-broadcast to specify the cost on a per neighbor basis. In this example we are going to add a cost of 25 to the routes from 154.1.0.5 and 50 to the routes from 154.1.0.3.

Rack1R4#sho run | be router ospf
router ospf 1
 network 154.1.0.0 0.0.255.255 area 0
 neighbor 154.1.0.5 cost 25
 neighbor 154.1.0.3 cost 50

Rack1R4#sho run int s0/0
interface Serial0/0
 ip address 154.1.0.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint non-broadcast
 frame-relay map ip 154.1.0.3 403 broadcast
 frame-relay map ip 154.1.0.5 405 broadcast
 no frame-relay inverse-arp
end

Rack1R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24
  Known via "ospf 1", distance 110, metric 26, type intra area
  Last update from 154.1.0.5 on Serial0/0, 00:06:13 ago
  Routing Descriptor Blocks:
  * 154.1.0.5, from 150.1.5.5, 00:06:13 ago, via Serial0/0
      Route metric is 26, traffic share count is 1
      ^^^^^^^^^^^^^^^^^^^

Now we can see that we prefer the route from 154.1.0.5 (router-ID 150.1.5.5).

Dec
28

First off we need to understand that traceroute is a technique to have the routers between the source and destination reveal themselves and finally have the destination reveal itself. Traceroute can be implemented using ICMP, UDP, and even TCP so as a CCIE when someone asks you to filter “traceroute” you should get a little background as to the traceroute application/OS’s being used to trigger the reply from the destination. Example: Windows uses ICMP echoes by default, most Linux OS’s use UDP by default but can use ICMP echoes (-I option), and the IOS uses UDP. There are also implementations that use TCP.

The goal of traceroute is to have the routers between the source and destination reveal themselves and finally have the destination reply so that you know you have reached it. The routers reveal themselves by sending Time Exceeded (aka TTL-Exceeded) ICMP packets back to the source when the TTL is decremented to zero. The traceroute implementation can determine its reached the destination by having it reply to an ICMP echo request, send an ICMP port unreachable to a packet sent to an unused UDP port, or completing the TCP three-way handshake.

************************************************************************

ICMP based traceroute:

In this example we are sending ICMP echo requests to www.cisco.com and looking for the ICMP echo reply to know that we have reached the final destination.

[root@digdug root]# traceroute -I www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte
packets
1 198.132.102.1 (198.132.102.1) 1.658 ms 1.975 ms 1.968 ms
2 foo.hostrack.net (202.101.143.254) 5.394 ms 22.382 ms 2.966 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 20.132 ms 20.494 ms 20.195 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 19.749 ms 25.827 ms 26.814 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 29.108 ms 19.864 ms 20.066 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 26.338 ms 26.232 ms 26.821 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 46.424 ms 45.996 ms 45.675 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.653 ms 46.513 ms 46.803 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 46.693 ms 46.619 ms 46.446 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 46.556 ms 46.954 ms 46.944 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 30.818 ms 31.769 ms 32.685 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 30.589 ms 30.626 ms 30.448 ms
13 * * *
14 www.cisco.com (198.133.219.25) 28.916 ms 28.994 ms 28.944 ms
************************************************************************

UDP based traceroute:
In this example we are sending UDP packets with a starting port number of 33434 to www.cisco.com. Note that we don’t ever get a reply from www.cisco.com because their firewall will not allow our UDP packets to arbitrary high ports in.

[root@digdug root]# man traceroute | grep “UDP port number”
-p Set the base UDP port number used in probes (default is 33434).
[root@digdug root]#
[root@digdug root]# traceroute www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets
1 198.132.102.1 (198.132.102.1) 1.725 ms 1.866 ms 1.841 ms
2 foo.hostrack.net (202.101.143.254) 4.887 ms 4.281 ms 4.482 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.266 ms 21.152 ms 20.826 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 58.829 ms 42.033 ms 24.007 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.448 ms 23.277 ms 21.446 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.816 ms 27.259 ms 27.210 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.540 ms 46.954 ms 47.198 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.072 ms 47.247 ms 46.667 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 51.728 ms 51.437 ms 48.304 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.563 ms 48.878 ms 47.807 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.562 ms 32.653 ms 31.318 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.327 ms 31.831 ms 31.516 ms
13 * * *
14 * * *

************************************************************************
TCP based traceroute:

In this example we are sending TCP SYN packets to port 80 looking for the destination to complete the three-way-handshake. Once the handshake
is complete we know that we have reached the destination. Obviously Cisco’s firewall is going to allow packets to TCP port 80 destined for it’s web server.

[root@digdug root]# tcptraceroute www.cisco.com
tcptraceroute: Symbol `pcap_version’ has different size in shared object, consider re-linking
Selected device eth3, address 198.132.102.93, port 41440 for outgoing packets
Tracing the path to www.cisco.com (198.133.219.25) on TCP port 80, 30 hops max
1 198.132.102.1 (198.132.102.1) 1.575 ms 1.507 ms 1.469 ms
2 foo.hostrack.net (202.101.143.254) 4.840 ms 5.090 ms 4.596 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.205 ms 20.895 ms 21.430 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 21.682 ms 21.012 ms 21.059 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.185 ms 21.304 ms 20.939 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.176 ms 28.615 ms 27.644 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.659 ms 48.220 ms 47.667 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 47.534 ms 48.483 ms 47.183 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 64.413 ms 51.058 ms 49.007 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.156 ms 49.197 ms 47.534 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.685 ms 32.633 ms32.895 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.291 ms 33.900 ms35.461 ms
13 www.cisco.com (198.133.219.25) [open] 31.041 ms 31.667 ms 32.775 ms
[root@digdug root]#

Tags: , , , ,

Dec
28

Hi Brian,

I am using dialer profiles for ISDN and I want protocol broadcasts such as RIP to be sent out accross the ISDN link. I tried to find the command that allows me to configure broadcast but the dialer interfaces do not accept the dialer map command. How do I accomplish this?

When using dialer profiles, dialer interfaces are point-to-point, therefore there is no need for protocol mappings. IP broadcasts should not have any trouble being sent across the interface as long as you have an IP address configured on the interface. Dialer maps are only used on dialer interfaces when using rotary groups. Dialer profiles are for when you have a single physical interface, but multiple destinations to dial. Rotary groups are for when you have multiple physical interfaces, but one destination to dial.

Dec
28

Hi Brian,I configured NTP on 2 Routers back-to-back with authentication (md5). So far everything works fine. I removed authentication on one of the Routers (no ntp authenticate) and they continue to sync. I even rebooted the router on which I had removed the authentication and they still sync. Any ideas why?

A common misconception about NTP authentication is the direction in which authentication occurs, however it makes perfect sense if you ask yourself this question: what is the purpose of using NTP authentication?

One clear answer is that authentication is used to prevent tampering with the timestamps on the logs generated by devices. To implement an attack on NTP, a hacker would make their rogue host appear to be a valid NTP server. NTP authentication is therefore used to authenticate the time source, not the client.

Take the following scenario:

R1–12.0.0.0/8–R2

R1 and R2 share the segment 12.0.0.0/8. R1 is the NTP master, and R2 is the client. To get a better understanding of how NTP authentication works, try the following possible configurations and see which of them work and which of them do not.

Case 1: No authentication

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp server
ntp server 12.0.0.1

R2#sh ntp status | in synch
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#show ntp associations detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 2: Authentication on server, no authentication on client

R1#sh run | in ntp
ntp authentication-key 1 md5 121A0C041104 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp clock-period 17179863
ntp server 12.0.0.1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 3: No authentication on server, authentication on client

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 08701E1F28492647465A5D547E 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179863
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is unsynchronized, stratum 16, no reference clock

R2#sh ntp assoc detail
12.0.0.1 configured, insane, invalid, unsynced, stratum 16

Case 4: Authentication on server and client

R1#sh run | in ntp
ntp authentication-key 1 md5 0822455D0A16 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 060506324F41 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179865
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1

As shown by the above configuration, NTP authentication is used to authenticate the NTP source, not any associated clients.

Dec
27

Hi Brian,

I have a router with two interfaces running both RIP and EIGRP as follows:

Interface  IP-Address      OK? Method Status  Prot
Serial0    172.16.5.5      YES manual up      up
Serial1    172.16.1.5      YES manual up      up

router rip
 network 172.16.0.0
!
router eigrp 2001
 network 172.16.0.0

S0 should be RIP only, and S1 should be EIGRP only. RIP should not listen to broadcasts on S1
and EIGRP should not listen to multicasts on S0. How do I do that?

Since EIGRP uses periodic hellos to establish adjacency, passive-interface is sufficient in this case. Since passive-interface in EIGRP suppresses the generation of hellos out an interface, adjacency cannot be established, and therefore there can be no exchange of routes.

An even easier method of choosing which specific interfaces are running EIGRP is to use a wildcard mask when you use the network statement. The ‘network’ statement in IGP does not actually mean what networks you are advertising, it means what interfaces you are running the protocol on. If you only want to run EIGRP on your Serial 1 interface with an address of 172.16.1.5, use the following syntax:

router eigrp 2001
 network 172.16.1.5 0.0.0.0

This means that only the interface 172.16.1.5 is running EIGRP. The opposite of this most specific syntax would be:

router eigrp 2001
 network 0.0.0.0 255.255.255.255

This means that all interfaces are running EIGRP.

With RIP, the case is different than EIGRP. Since RIP does not use periodic hellos like EIGRP, OSPF, or IS-IS, passive-interface simply means that you will not send any routing updates out an interface. This does not mean that you will not receive routing updates in that interface. To prevent learning routes in an interface using RIP, you could use a distribute-list that denies everything (which would also work for EIGRP), or use an access-list that denies RIP altogether. Take the following examples:

access-list 1 deny any
!
router rip
 network 172.16.0.0
 distribute-list 1 in serial 1

or

access-list 100 deny udp any eq rip any eq rip
access-list 100 permit ip any any
!
interface serial 1
 ip access-group 100 in

Both would accomplish the same goal.

Dec
26

Unlike PAP, CHAP does not actually send a password over the line. Instead, a hash value made up of the password and magic number is sent. Unless the hash matches from both authenticating parties, authentication is not successful.


By default, the router sends it’s hostname for authentication when using chap. The router on the other side does a lookup in its local database, radius server, or tacacs server, and finds the password that is paired with that username. If there is no matching username in the database, the password specified with the interface level command ‘ppp chap password’ is used as the default password.


Suppose you have a central office that has many remote clients dialing into it. If you don’t want to create an entry in the user database for each remote client, you can just specify a default password with ‘ppp chap password’. As long as the remote clients have an entry for the central site in their user database, authentication will be successful.

Dec
26

“async mode dedicated” is strictly for PPP and SLIP connections. “async mode interactive”, on the other hand, can be used for PPP, SLIP, ARAP, along with EXEC access to the router. Suppose you’re dialing into the router’s AUX port to access the CLI. In this case you want interactive mode. If you’re dialing into the router strictly for a PPP connection, use dedicated mode.

When using interactive mode, you can also use the command “autoselect” on the line to have the router automatically determine whether you want a PPP connection or an EXEC connection.

“async default routing” enables routing on an async interface by default. This means when you dial into the interface, routing is already set up. “async dynamic routing” means that the user must manually initiate the PPP session from the EXEC mode. “async dynamic routing” would be used if you have an “async mode interactive” for which you want EXEC access, and then want to call a PPP session.

Under normal use, you would pair “async mode dedicated” along with “async default routing” when running PPP over a dial-in connection. “async mode interactive” will be used to get remote access to the router via a modem attached to the AUX port. You most likely would not use “async dynamic routing”, since you can just say “autoselect PPP” if you want interactive EXEC and PPP access.

Dec
26

Prefix-lists are used to match on prefix and prefix-length pairs. Normal prefix-list syntax is as follows:

ip prefix-list LIST permit w.x.y.z/len

Where w.x.y.z is your exact prefix
And where len is your exact prefix-length

“ip prefix-list LIST permit 1.2.3.0/24″ would be an exact match for the prefix 1.2.3.0 with a subnet mask of 255.255.255.0. This does not match 1.2.0.0/24, nor does it match 1.2.3.4/32, nor anything in between.

When you add the keywords “GE” and “LE” to the prefix-list, the “len” value changes its meaning. When using GE and LE, the len value specifies how many bits of the prefix you are checking, starting with the most significant bit.

ip prefix-list LIST permit 1.2.3.0/24 le 32

This means:
Check the first 24 bits of the prefix 1.2.3.0
The subnet mask must be less than or equal to 32

This equates to the access-list syntax:

access-list 1 permit 1.2.3.0 0.0.0.255
ip prefix-list LIST permit 0.0.0.0/0 le 32

This means:
Check the first 0 bits of the prefix 0.0.0.0
The subnet mask must be less than or equal to 32
This equates to anything

ip prefix-list LIST permit 0.0.0.0/0

This means:
The exact prefix 0.0.0.0, with the exact prefix-length 0.
This is matching a default route.

ip prefix-list LIST permit 10.0.0.0/8 ge 21 le 29

This means:
Check the first 8 bits of the prefix 10.0.0.0
The subnet mask must be greater than or equal to 21, and less than or
equal to 29.

ip prefix-list CLASS_A permit 0.0.0.0/1 ge 8 le 8

This matches all class A addresses with classful masks. It means:
Check the first bit of the prefix, it must be a 0.
The subnet mask must be greater than or equal to 8, and less than or equal to 8. ( It is exactly 8 )

When using the GE and LE values, you must satisfy the condition:

Len < GE <= LE

Therefore “ip prefix-list LIST permit 1.2.3.0/24 ge 8″ is not a valid list.

What you can not do with the prefix-list is match on arbitrary bits like you can in an access-list. Prefix-lists cannot be used to check if a number is even or odd, nor check if a number is divisible by 15, etc… Bit checking in a prefix-list is sequential, starting with the most significant (leftmost) bit.

Dec
26

Suppose we have the following scenario:

R1—R2–R3–R4—R5

R1 is AS 100
R2, R3, R4 are AS 200
R5 is AS 300

R2, R3, R4 are confederated, with sub as’s 65002, 65003, and 65004 respectively. They are also originating prefixes A, B, & C respectively. If AS 200 does not want to be transit, we must only advertise out prefixes originated in these three sub AS’s.

From R2′s perspective, we see the following prefixes, and the following AS-Path’s:

A – EMPTY
B – (65003)
C – (65003,65004)

From R4′s perspective, we see the following prefixes, and the following AS-Path’s:

A – (65002,65003)
B – (65003)
C – EMPTY

Now we must consider how to match all of these cases in a single line. Remember that parentheses are special characters within the as-path list.

Our minimum case to match would be:

^$

This is our empty AS-PATH, which is prefixes locally originated in our sub-as.

Our maximum case to match would be:

\(X\)

where X is any number of AS’s, or a comma. Remember that we need to escape the parens.

To satisfy our condition of X, we should be matching 1 or more instance of any character, which equates to:

.+

Therefore our maximum case is now:

^\(.+\)$

However, we must match the minimum case at the same time. Therefore, our current expression \(.+\) is either true or false. True or false (0 or 1 instance) is covered by the expression ?.

Therefore, our final regular expression will read:

^(\(.+\))?$

Tada!

Advertise only prefixes which match this expression outbound on your border routers, and your confederated AS’s will not be transit.

Categories

CCIE Bloggers