RIPv2

1. RIP v1 &2 has a maximum datagram size (with an eight-byte UDP header) of 512 octets. So it is up to 25 route entries (each is 20 bytes).

2. RIP v2 support authentication.

Simple password authentication: it will use the first route entry. So it leaves only 24.

MD5 authentication: it will use the first and last one. So it leaves only 23.

You need to configure the authentication under interface.

3. Unicast update.

By default RIP uses broadcast(v1) or multicast(v2) to send updates. To use unicast update, you need to enable the interface to be part of the network, then mark it as passive interface and finally configure neighbor.

Passive interface just makes the interface no sending out broadcast or multicast updates. But it will still listen to the updates.

AD and EIGRP

1. When receiving a new EIGRP update, Will it compare inside the EIGRP topology firstly and then AD?

Let's look at the sample.

10.1.0.0 learn from BGP and then redistributed into EIGRP on R1.

default-metric 10000 10 1 255 1500
distance 200 0.0.0.0 255.255.255.255 10
access-list 10 permit 10.1.0.0

Then R1 receives an new update from its neighbor R2 with 10000 1200 1 255 1500.

So from the eigrp topology perspective, the one redistributed from BGP has better metrci than the one from R2. But the AD for R2 is 170, and 200 for BGP. Which one is prefer????

Answer, it prefers the AD first. So in R1's routing table, 10.1.0.0 is from EIGRP instead of R2.

ip alias

1. show ip alias

It will should all the IP address, it is better than using show ip int bri.

2. ip alias can be use for un-exist host.
Sample configuration:
R1#(config)int fa 1/0
R1#(config-inf) ip add 192.168.1.2 255.255.255.0
R1#(config)ip alias 192.168.1.10 23

when you ping 192.168.1.10, the arp will resolve from 192.168.1.2. When you telnet 192.168.1.10, it will actually telnet to 192.168.1.2.

Usually, it will be used in reverse telnet.
ip alias 172.16.1.10 2001
ip alias 172.16.1.11 2002

So you can just "telnet 172.16.1.10" than it will reverse telnet to one of the serial ports.

PVST+

Cisco switches run different types of STP protocol, depending on whether the connected port is access, ISL trunk or 802.1q trunk. Natively, a Cisco switch runs a separate STP instance for each configured and active VLAN (this is called Per-VLAN Spanning Tree or PVST) and standard IEEE compliant switches run just one instance of STP protocol shared by all VLANs. Due to that, a group of switches running IEEE compatible STP protocol is called MST (Mono Spanning Tree) region.

Access Ports. Cisco switches run classic version of IEEE STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will interoperate perfectly, joining the respective access VLAN STP instance with the IEEE STP instance (MST).

ISL Trunks. Across ISL trunks, Cisco switches run PVST (Per-VLAN Spanning Tree). (Note that PVST feature is limited to ISL trunks only). The same IEEE STP BPDUs are sent for each VLAN, encapsulated in additional ISL header (which also carries the VLAN number). The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.

802.1q Trunks. Across 802.1q trunks, Cisco switches run PVST+ (Per VLAN Spanning Tree Plus). Now this is where things are getting complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST instance BPDUs across MST region (to potentially connect to other Cisco switches across the MST region). For further consideration, we call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on MST side only one STP instance exists, contrary to many STP instances of PVST+ region. The first question is: if we want to interoperate with MST, which PVST VLAN’s STP instance should be joined with MST? Cisco chooses VLAN 1 for this purpose. The joined together instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases.

Lastly, for the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0×010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.

mac access-list extended IEEE_STP&PVST&MIST
permit any any lsap 0x4242 0x0
mac access-list extended PVST+
permit any any 0x10B 0x0

VLAN ACL

1. Tips
ARP are not IP packet, so you must be enabled it using mac ACL.
STP/PVST, PVST+ are something need to be enable too.


2. IP ACL
The CAT 3550 and 3560 switches process IP Packets in a different way than the non-IP Packets. So it is Mandatory to use IP access-list.

We cannot use a MAC access-list to allow IP Packets.

3. Sample
So, we have two different requirements there...
Forward all "non-IP" frames sourced from those two specific MAC Addresses; That requires a MAC Access-List.
Permit only ICMP, denying everyting else. That requires an IP Access-List (the one we´re all used to).

Ok, so let´s create our MAC Access-List:

mac access-list extended Allow Those
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any

That will handle the first requirement.
Now the second one IP Access-List allowing ICMP and denying everything else:
access-list 101 permit icmp any any

Ok! Now, we need to create the VACL (or VLAN Maps, which one you prefer to call it) applying those rules:
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop

Now it looks ok, right?! Time to apply it to VLAN7 ?! What do you think about?! Let´s try?!

vlan filter Filter-VL7 vlan-list 7

Now testing! See if you can ping! Not working?! Hmmm... interesting... but why?! Well... I told... The MAC Access-List would bring all the interesting issues to the table! And, in fact, it did! It´s allowing only those two MAC Address and nothing else! How about ARP?! Do we need it to make things work?! Of course we do! And that´s where we have most confusion! Just keep in mind, the end of an Access-List is always deny any any! So if there are no matching instances for ARP in the MAC Access-List, it´ll be dropped!
How to fix it?! Simple, allow it in the MAC Access-List:
permit any any 0x0806 0x0000 permit any any lsap 0xAAAA 0x0000
But wait a minute! What´s that 0x0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0x806) is ARP, and the second one (lsap 0xAAAA) is PVST+. You do not want your switch running unprotected from loops right?! So it´s better to allow it!
For the sake of simplicity, the full configuration would be this one:
mac access-list extended AllowThose
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
permit any any 0x0806 0x0000
permit any any lsap 0xAAAA 0x0000 (This is copy from Link. This matches all the snap packet. To be more specifical, use permit any any 0x010b 0x0000).
!
access-list 101 permit icmp any any
!
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
!
vlan filter Filter-VL7 vlan-list 7



The most common Ethertypes are: (and probably the ones asked in the LAB)
0x0806 = ARP
0x0800 = IP
0x010b = PVST+ (actually is inside the snap packet, lsap 0xAAAA)
0x4242 = STP and PVST
0x86DD = IPv6

Again... we need to understand all the little pieces involved in a particular task, and remember about the basics, OSI Model, ARP, and so on! It´s not difficult, but it´s a little confusing at the first time! Just go ahead, drink some watter (I did it several times) come back again, read over, and try some scenarios yourself, don´t have equipment?! Try it on Notepad, just try some, compare with the example, and you´ll see how easy it can be! The best way to learn is trying it yourself! ;)
You can also find a nice explanation about that in the wonderful Arden Packeer´s Blog, just click here and it´ll direct you to the post.

RSVP

RSVP is one way. Typically RSVP is initialize by sender.

Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.


In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.

The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.

The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.

If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.


Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although
WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and
below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled.

1. Frame Relay

You need to enable the following step

1.1 Enable WFQ

If you do not use frame-relay traffic-shaping, make sure the interface is enabld for WFQ(Default). If you do use traffic-shaping, you need to enable WFQ in the map-class.

It is better to enable traffic shaping because that will be enfore queueing on the Per-VC.

1.2 Configure bandwidth under the both interface and sub-interface.
ip rsvp bandwidth 128(interface-max) 64 (per flow max)


it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.

Example:

interface Serial3/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
ip rsvp bandwidth 500 64 //Interface-max 500=350+150, single flow max = max {subinterfaces}
!
interface Serial3/0.1 point-to-point
ip address 10.1.1.1 255.255.0.0
frame-relay interface-dlci 101
class fr-voip
ip rsvp bandwidth 350 64
!
interface Serial3/0.2 point-to-point
ip address 10.3.1.1 255.255.0.0
frame-relay interface-dlci 201
class fast-vcs
ip rsvp bandwidth 150 32
!
map-class frame-relay fr-voip
frame-relay cir 800000
frame-relay bc 8000
frame-relay mincir 128000
frame-relay fragment 280 //option
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
!
map-class frame-relay fast-vcs
frame-relay cir 200000
frame-relay bc 2000
frame-relay mincir 60000
frame-relay fragment 280
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ


Rack1R5#show frame-relay pvc 101
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.1

Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 4
Output queue size 0/max total 600/drops 0


2. How about we disable WFQ

The reservation still will be successful. But the interface won't actually provide any queue.

Do a 'show ip rsvp install detail'

Rack1R1#show ip rsvp installed detail
RSVP: Serial1/0 has the following installed reservations
RSVP Reservation. Destination is 150.1.5.5. Source is 150.1.1.1,
Protocol is UDP, Destination port is 5000, Source port is 1000
Traffic Control ID handle: 81000404
Created: 23:02:48 UTC Sun Mar 3 2002
Admitted flowspec:
Reserved bandwidth: 32K bits/sec, Maximum burst: 4K bytes, Peak rate: 32K bits/sec
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Resource provider for this flow: None
Conversation supports 1 reservations [0x1B000402]
Data given reserved service: 0 packets (0 bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 28 seconds
Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort
Policy: INSTALL. Policy source(s): Default

Here is the good one.
Rack1R1#show ip rsvp installed detail
RSVP: Serial1/0 has the following installed reservations
RSVP Reservation. Destination is 150.1.5.5. Source is 150.1.1.1,
Protocol is UDP, Destination port is 5000, Source port is 1000
Traffic Control ID handle: 81000404
Created: 23:02:48 UTC Sun Mar 3 2002
Admitted flowspec:
Reserved bandwidth: 32K bits/sec, Maximum burst: 4K bytes, Peak rate: 32K bits/sec
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Resource provider for this flow:
WFQ on hw idb Se1/0: RESERVED queue 265. Weight: 6, BW 32 kbps
Conversation supports 1 reservations [0x1B000402]
Data given reserved service: 0 packets (0 bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 28 seconds
Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort
Policy: INSTALL. Policy source(s): Default

Redistribution

1. EIGRP.
Distance command only works for internal routes, not external routes.
You can only change AD for all prefix at one.

Network-Based Application Recognition and ACLs

From Cisco.

NBAR requires ip cef.
NBAR configuration:

Router(config)#class-map match-any http-hacks
Router(config-cmap)#match protocol http url "*default.ida*"
Router(config-cmap)#match protocol http url "*cmd.exe*"
Router(config-cmap)#match protocol http url "*root.exe*"



Notes:
To block a traffic using NBAR, you have three choise:

1. Using ACL
Build a policy and use the set command to mark inbound "Code Red" hacks with a policy map. This document uses a DSCP value of 1 (in decimal) since it is unlikely that any other network traffic is carrying this value.

Router(config)#policy-map mark-inbound-http-hacks
Router(config-pmap)#class http-hacks
Router(config-pmap-c)#set ip dscp 1
Router(config)#interface serial 0/0 //ingress interface
Router(config-if)#service-policy input mark-inbound-http-hacks

Configure an ACL that matches on the DSCP value of 1, as set by the service policy.
Router(config)#access-list 105 deny ip any any dscp 1
Router(config)#access-list 105 permit ip any any
Router(config)#interface ethernet 0/1 //egress interface
Router(config-if)#ip access-group 105 out



2. Using Police-Based routing to route the traffic to Null0.

Use the service-policy command to apply the policy as an inbound policy on the input interface to mark arriving "Code Red" packets. See method 1.

Create an extended IP ACL that matches on the marked "Code Red" packets.
Router(config)#access-list 106 permit ip any any dscp 1

Use the route-map command to build a routing policy.
Router(config)#route-map null_policy_route 10
Router(config-route-map)#match ip address 106
Router(config-route-map)#set interface Null0

Apply the route-map to the input interface.
Router(config)#interface serial 0/0 //ingress interface.
Router(config-if)#ip policy route-map null_policy_route

We are able to make the discard decision at the ingress interface of the router, rather than needing an output ACL on every egress interface. Again, we recommend disabling the sending IP unreachable messages with the command no ip unreachables command.


3. Using Class-based Policy.

Router(config)#policy-map drop-inbound-http-hacks
Router(config-pmap)#class http-hacks
Router(config-pmap-c)#police 1000000 31250 31250 conform-action drop exceed-action drop violate-action drop
or new IOS supoort
Router(config-pmap-c)#drop

This will be the best solution of all.

RTP classification

Quote from Cisco.

Why nBAR RTP Payload Classification

While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.

1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Notes: To match udp range from 16374 - 16574, use command "match ip rtp 16374 200"

2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.

3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
Notes: To match udp range from 16374 - 16574, use command "ip access-list 110 permit udp any any range 16374 16574".

4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.

BGP tips

1. Timer
When a connection is started, BGP will negotiate the hold time (only) with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time/3 and the configured keepalive time, which one is lower.

By default, keepalive is 60 sec and hold time is 180 sec.

R1(Confg)# neighbor R2 timer 10 40
On R1, when you do a show ip bgp R2, it will show keepalive 10 sec and hold time 40 sec.
On R2, when you do a show ip bgp R1, it will show that the keepalive is 13 sec(40/3) and hold time is 40 sec.

R1(Confg)# neighbor R2 timer 80 180
On R1, when you do a show ip bgp R2, it will show keepalive 60 sec(180/3) and hold time 180 sec.

OSPF

1. VL and area 0 range.

If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing
information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone’s configured ranges should be ignored when originating summary-LSAs into transit areas.

To show if the area is transitCapability, do
R1# show ip ospf
=================
Area 1
Number of interfaces in this area is 1
This area has transit capability: Virtual Link Endpoint
Area has no authentication
SPF algorithm last executed 01:29:49.932 ago
SPF algorithm executed 13 times
Area ranges are
Number of LSA 12. Checksum Sum 0x052BF3
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
========================================

After you enable the virtual link, the "area 0 range" won't works (only for backbone area0).

To fix it, do not use virtual link, instead you can create a GRE tunnel and set it to area 0.

2. VL and GRE Tunnel
Virtual-link:
-It is considered part of (Area 0) by default, without any additional configuration.
-It dose not require any kind of addressing.
-Configuration is only needed under the OSPF routing process.
-Only routing updates are tunneled into the virtual-link, but data traffic is not.
-Transit area can not be a stub area.
GRE tunnel:
-Tunnel interfaces must be created and addressing is required. (can be unnumbered).
-Tunnel Address must be advertised into (Area 0) using a network command.
-Both routing updates and data traffic are tunneled; this introduces more overhead.
-Transit area can be any type; this means its your only option if the transit is a stub area.

3. Default route. Link.
You can not redistribute default route into ospf. It can be inserted into the OSPF domain only as an external or inter-area (summary) route. There are only two ways to generator default-route into ospf by:
a. default-information originate
b. summary only in stub or nssa. (you cannot do 'area 0 range 0.0.0.0 0.0.0.0)

RIP

1. RIP summary
RIP dose not support super net summary.

2. RIP default route
You can specific which interface should the default route sending out using "default-route originate route-map Interface".

route-map Interface
match ip address 1 //only when there is a route match access-list 10 will it create 0.0.0.0/0
set interface e0/0 //it will only send update 0.0.0.0/0 out e0/0

3. Filter routes
distribute-list 1 in e0/0

distribute-list prefix-list allow-nets in e0/0

distribute-list gateway all0w-source in e0/0 (Gateway is the ip address of the neighbor whom you receive a routing update).
The following prefix-list works with distribute-list gateway to only allow updates from 150.1.1.2.
ip prefix-list allow-source deny 150.1.1.1/32
ip prefix-list allow-source permit 150.1.1.2/32

4. Redistribute need to manually set the metric.

5. Troubleshooting tool
debug ip rip
will show you all the update sent and received.

PPP Authentication

1. PAP
Password Authentication Protocol (PAP) sends the username and password over the ISDN link in clear-text. Sending any passwords over any WAN link in clear-text is generally a bad idea, but it's important to know you have this option.
Regarding both PAP and CHAP, it's a common misunderstanding that each side must authenticate the other. PAP and CHAP both support bidirectional and unidirectional authentication; that is, R1 can authenticate R2 without R2 necessarily authenticating R1. It's more common to use unidirectional authentication in a lab environment than a production network, but keep in mind that bidirectional authentication is an option, not a requirement.
The configurations of PAP and CHAP do have their similarities. For both, you'll configure a username/password combination in global configuration mode. Newcomers to ISDN sometimes put the local router name in for the username; remember that the remote router name is the username.
The only real advantage of PAP over CHAP comes in the password configuration. Since PAP actually sends the password as a whole over the link, the two routers can send different passwords during authentication. The operation of CHAP requires that both routers use the same password, and we'll see why in tomorrow's article.

R1:
username R2 password CISCO
Int bri0
encapsulation ppp
ppp authentication pap

PAP requires an extra command at this point. The ppp pap sent-username command is required under the interface, indicating the username and password this router will be sending to the remote router.
R2:
Int bri0
encapsulation ppp
ppp pap sent-username R2 password CISCO




2. Chap
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.

Here is the basic configuration for CHAP. This is one way authentication.
R1:
username Router2 password CISCO
int ser 1/0
encap ppp
ppp authentication chap

R2:
username R1 password CISCO
int ser 1/0
encap ppp
ppp chap hostname Router2 // match the user database in R1

NTP Authentication

1. NTP Peers don't need to be at the same stratum.

2. Without "ntp authentication"
NTP_client:
ntp authentication-key 1 md5 cisco
ntp server 101.1.1.1 key 1
NTP_server:
ntp master 3
ntp authentication-key 1 md5 cisco
2.1 the debug you can see both server and client send out packet with key 1. The time will be synch.
2.2 "show ntp assossiate detail" on client, it shows that server is authenticated.

3. With "ntp authentication"
Only change will be in client
NTP_client:
ntp authenticate
ntp authentication-key 1 md5 cisco
ntp server 101.1.1.1 key 1
3.1 The time won't sync because it does not trust any key.
3.2 The server is authenticated.

4. You need both 'ntp authenticate' and 'ntp trust-key 1' to enable the time sync.

5. Time information will also be accepted from an unauthenticated peer or server if the peer/server has no key identifier associated with it via the 'ntp peer server key' global configuration command.

6. This configuration is working too. The peers configure with different key number but as long as the other side configured with the right authentication-key it will accept the time information.
For ntp server, if it receives a request with key and key is valid, it will reply with time information with same key.

Router2(151.1.2.2)#
ntp authentication-key 1 md5 cisco
ntp authentication-key 2 md5 ibm
ntp authentication-key 3 md5 google
ntp authenticate
ntp trusted-key 1 #trust the time information from server 45.1.200.29
ntp trusted-key 2 #trust the time information from peer 150.1.3.3 using key 2. See note on R3)
ntp peer 150.1.3.3 key 3 source Loopback0
ntp server 45.1.200.29 key 1

Router3(151.1.3.3)#
ntp authentication-key 1 md5 cisco
ntp authentication-key 2 md5 ibm
ntp authentication-key 3 md5 google
ntp authenticate
ntp trusted-key 1 #trust the time information from server 216.16.234.10
ntp trusted-key 3 #trust the time information from peer 150.1.2.2 using key 3. (diff from the line below but match the configuration in Router2.
ntp peer 150.1.2.2 key 2 source Loopback0
ntp server 216.16.234.10 key 1

So basically when router receives a ntp packet from x.x.x.x with key number y, it will verify it with the configuration of 'ntp authentication-key y md5' regardless what the key number configured under 'ntp peer x.x.x.x key z'.

'ntp peer x.x.x.x key z' means the router will send a packet to x.x.x.x with key z. But for inbound packet from x.x.x.x it dose not need to use the same key.

What about only change Router3 to "ntp peer 150.1.2.2 source loopback0"(without key)? In this case, Router2 will not accept time information from Router3 because at Router2 we configure that Router3 should have key included. But Router3 will still trust Router2 as peer ntp. Please refer to point 5. To make this works, either change it back or change Router2 to 'ntp peer 150.1.3.3 source loopback 0'.

7. Reference: http://www.nil.com/ipcorner/SecTimeManagement/