Lessons learned:
PPP (point-to-point
protocol)
Media independent encapsulation – also very lightweight
-serial, Ethernet, Frame Relay, ATM.
-encapsulation PPP
Adds features that
other layer 2 medias don’t natively support.
-authentication
-Multilink
-fragmentation
-reliability
Note: Ethernet doesn’t
support authentication, fragmentation or multilink of other interfaces together
outside if etherchannel features on switches.
With PPP, you could take an Ethernet interface, a Multilink
interface or ATM interface and multilink all them together by basically using
the layer 2 ½ features that ride between the physical framing and the upper
layer protocols.
PPP Negotiation:
Once enabled on the interface – the interface will go
through the LCP (link control protocol) to negotiate higher layer protocols as
well as authentication. MTU, etc.
-internet protocol control protocol (IPCP)
-IPv6CP
-CDPCP, etc.
Can be used to
negotiate
-address assignment – in IPV4
-routing information – if both ends are not on the same
subnet. This is a feature also known as the PPP Peer neighbor route.
Verification
-debug ppp negotiation
Will tell if they’re any Authentication issues, MTU errors
or IP address assignments
Config PPP:
R1 -------------------------R2
Both routers have Serial 0/0 connected together.
R1:
interface Serial0/0
ip address 13.0.0.1
255.255.255.0
encapsulation ppp
end
R2:
interface Serial0/0
ip address 13.0.0.2
255.255.255.0
encapsulation ppp
clock rate 64000
end
---------------------------
Note: PPP by default will learn the address assigned to the neighbor
and put an exact match host route pointing to the neighbor interface.
Gateway of last resort is not set
13.0.0.0/8 is
variably subnetted, 2 subnets, 2 masks
C 13.0.0.1/32 is directly connected, Serial0/0
C 13.0.0.0/24 is
directly connected, Serial0/0
R2#
Verify via debug PPP
negotiation
Then shut down the serial
0/0 interface.
%LINK-5-CHANGED: Interface Serial0/0, changed state to
administratively down
R2(config-if)#
*Mar 1 00:11:41.959:
Se0/0 PPP: Sending Acct Event[Down] id[4]
*Mar 1 00:11:41.959:
Se0/0 CDPCP: State is Closed
*Mar 1 00:11:41.963:
Se0/0 IPCP: State is Closed
*Mar 1 00:11:41.963:
Se0/0 PPP: Phase is TERMINATING
*Mar 1 00:11:41.967:
Se0/0 LCP: State is Closed
*Mar 1 00:11:41.967:
Se0/0 PPP: Phase is DOWN
*Mar 1 00:11:41.967:
Se0/0 IPCP: Remove route to 13.0.0.1
Then no shut the
interface:
This shows the individual
process the neighbors go through the negotiation.
R2(config-if)#no shutdown
R2(config-if)#
*Mar 1 00:12:10.159:
Se0/0 PPP: Outbound cdp packet dropped
R2(config-if)#
*Mar 1 00:12:12.151:
%LINK-3-UPDOWN: Interface Serial0/0, changed state to up
R2(config-if)#
*Mar 1 00:12:12.155:
Se0/0 PPP: Using default call direction (
This says this is a dedicated line, no call direction)
*Mar 1 00:12:12.155:
Se0/0 PPP: Treating connection as a dedicated
line
Note: PPP doesn’t care about this as much as an analog
call would.
*Mar 1 00:12:12.155:
Se0/0 PPP: Session handle[D4000003] Session id[3]
*Mar 1 00:12:12.159: Se0/0 PPP: Phase is
ESTABLISHING, Active Open – The next stage is OPEN, you can see the next lines
start the LCP negotiations.
*Mar 1 00:12:12.159:
Se0/0 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 00:12:12.159:
Se0/0 LCP: MagicNumber 0x01388022
(0x050601388022)
Next – is the PPP MagicNumbe which is a sequence number.
*Mar 1 00:12:12.255:
Se0/0 LCP: I CONFREQ [REQsent] id 19 len 10
*Mar 1 00:12:12.255:
R2(config-if)# Se0/0 LCP:
MagicNumber 0x0038860A (0x05060038860A)
*Mar 1 00:12:12.259:
Se0/0 LCP: O CONFACK [REQsent] id 19 len 10
Here router 2 sends
an outbound request -
*Mar 1 00:12:12.259:
Se0/0 LCP: MagicNumber 0x0038860A
(0x05060038860A)
*Mar 1 00:12:12.259:
Se0/0 LCP: I CONFACK [ACKsent] id 3 len 10
Here router 1
responds with a ACK response. And ok to use the sequence numner.
*Mar 1 00:12:12.259:
Se0/0 LCP: MagicNumber 0x01388022
(0x050601388022)
*Mar 1 00:12:12.263:
Se0/0 LCP: State is Open
*Mar 1 00:12:12.263:
Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:12:12.267:
Se0/0 PPP: Phase is ESTA
You would also see
any AUTH protocol types negotiated here, the devices would not proceed to the next
phase if the cant agree.
R2(config-if)#BLISHING, Finish LCP
Here the devices have
finished the negotiation and are moving on to the upper layer protocols.
*Mar 1 00:12:12.267:
Se0/0 PPP: Phase is UP
*Mar 1 00:12:12.271:
Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 1 00:12:12.271:
Se0/0 IPCP: Address 13.0.0.2
(0x03060D000002)
Here router 2 says I’m
running IP and here’s my address.
*Mar 1 00:12:12.271:
Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar 1 00:12:12.275:
Se0/0 PPP: Process pending ncp packets
*Mar 1 00:12:12.303:
Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 1 00:12:12.303:
Se0/0 IPCP: Address 13.0.0.1
(0x03060D000001)
Here router 1 says I’m
also running IP and here is my IP
*Mar 1 00:12:12.307:
Se0/0 IPCP: O CO
R2(config-if)#NFACK [REQsent] id 1 len 10
*Mar 1 00:12:12.307:
Se0/0 IPCP: Address 13.0.0.1
(0x03060D000001)
*Mar 1 00:12:12.307:
Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 1 00:12:12.307:
Se0/0 IPCP: Address 13.0.0.2
(0x03060D000002)
*Mar 1 00:12:12.311:
Se0/0 IPCP: State is Open
*Mar 1 00:12:12.311:
Se0/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar 1 00:12:12.311:
Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar 1 00:12:12.319: Se0/0 IPCP: Install route
to 13.0.0.1
They have
successfully negotiated IPV4 and will now install a host route. PPP is now done
and the line protocol comes up.
*Mar 1 00:12:13.267:
%LINE
R2(config-if)#PROTO-5-UPDOWN: Line protocol on Interface
Serial0/0, changed state to up
*Mar 1 00:12:14.259:
Se0/0 CDPCP: Timeout: State ACKsent
*Mar 1 00:12:14.259:
Se0/0 CDPCP: O CONFREQ [ACKsent] id 2 len 4
*Mar 1 00:12:14.263:
Se0/0 CDPCP: I CONFACK [ACKsent] id 2 len 4
*Mar 1 00:12:14.263:
Se0/0 CDPCP: State is Open
R2(config-if)#
Note: you can also send the logging to the buffer instead of
the console and increase the buffer size. Then just issue the sh log command to
view the logs.
So what if router 1 and router 2 are not on the same subnet?
I now remove the IP off router 2 and create a loopback with the
IP 3.3.3.3 / 32
Now under the PPP interface, I need to unnumber the interface
to the loopback interface:
R2(config)#interface serial 0/0
R2(config-if)#ip unnumbered loopback 0
R2(config-if)#
*Mar 1 00:36:20.011:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R2(config-if)#
The idea is that if I have a bunch of serial interfaces that
are running PPP I don’t have to assign them separate addresses.
Now the PPP host route will tell how to get to particular destinations.
I will now do the
same on router 1.
interface Serial0/0
ip unnumbered
Loopback0
encapsulation ppp
clock rate 2000000
end
--------------------------
I have also added router 3 with a Loopback IP of 4.4.4.4
Also encap PPP and unnumbered.
Now I’ll turn on my debug again – this time on router 3:
R3(config)#logging console 7
R3(config)#do term mon
R3#debug ppp negotiation
PPP protocol negotiation debugging is on
Then shut and no shut the other routers links….
Now the routing table has routes to all 3 routers but the
traffic will be generated from the loopback.
This is because of the IPCP negotiation.
1.0.0.0/32 is
subnetted, 1 subnets
C 1.1.1.1 is
directly connected, Serial0/0
3.0.0.0/32 is
subnetted, 1 subnets
C 3.3.3.3 is
directly connected, Loopback1
4.0.0.0/32 is
subnetted, 1 subnets
C 4.4.4.4 is
directly connected, Serial0/1
R2#
=================================================
PPP Authentication:
Password authentication protocol (PAP)
-clear text username
-clear test password
Challenge handshake authentication protocol (CHAP)
-clear text username
-MD5 hashed password
MSCHAP / MCHAPv2 / EAP/ etc….
------------------------------------------------
PPP PAP AUTH:
Note: Both
username and pass are sent in clear text, which means the other ends can be completely
independent of what I’m using.
PPP Auth is a three step process:
Auth request
# ppp authnticaiotn pap
Auth response:
#no ppp pap refuse
# ppp pap sent-username password
Note: by default the router will have these two commands configured.
Auth acceptance
Verificaiton
#debug ppp negotiation
#debug ppp auth
Basically:
Router 1 want to auth with router 2:
Router one configures its interface for:
#PPP auth pap
R1 – then sends its request.
R2: will then sends a response –
It will send – PPP PAP sent -username and password.
Once R1 get the response it needs to validate this against something,
local DB, AD, Etc…
If the username and pass matches – R1 will respond with Auth
is fine and then can proceed with higher level protocols.
Note: If PPP auth PAP cmd on R1 is independent of the same
cmd on R2: You don’t need to configure this on both sides. As long as the auth
is successful one way – that’s all we’re looking for.
R2(config)#interface serial 0/0
R2(config-if)#ppp authentication p
R2(config-if)#ppp authentication pap
Router 1
Need to configure PPP sent username.
PPP protocol negotiation debugging is on
R1#
*Mar 1 01:13:51.539:
Se0/0 LCP: Timeout: State Listen
*Mar 1 01:13:51.539:
Se0/0 LCP: O CONFREQ [Listen] id 241 len 10
*Mar 1 01:13:51.543:
Se0/0 LCP: MagicNumber 0x0070F2EE
(0x05060070F2EE)
R1#
*Mar 1 01:13:53.555:
Se0/0 LCP: Timeout: State REQsent
*Mar 1 01:13:53.555:
Se0/0 LCP: O CONFREQ [REQsent] id 242 len 10
*Mar 1 01:13:53.559:
Se0/0 LCP: MagicNumber 0x0070F2EE
(0x05060070F2EE)
R1#
*Mar 1 01:13:55.571:
Se0/0 LCP: Timeout: State REQsent
*Mar 1 01:13:55.571:
Se0/0 LCP: O CONFREQ [REQsent] id 243 len 10
*Mar 1 01:13:55.571:
Se0/0 LCP: MagicNumber 0x0070F2EE
(0x05060070F2EE)
R1#
Configure PPP sent-username
If using local DB there must be a username match in the
local DB
R1(config)#interface serial 0/0
R1(config-if)#ppp pap sent-username ?
R1(config-if)#ppp pap sent-username mike password cisco
PPP CHAP Auth:
Authentication request
-ppp auth chap
Auth response
-No ppp chap refuse
Usernames & Passwords
-Global vs interface
Verification:
-debug ppp negotiation
-debug ppp authentication
No comments:
Post a Comment