Tuesday 9 March 2010

Layer 2 Technologies - Implement Ethernet

So far all of the Layer 2 technologies have been related to Ethernet and it's implementation of some kind (well I guess things like IRB and CRB can use alternate technologies)

1.40    Implement Ethernet technologies

(a) Speed and duplex

(b) Ethernet, Fast Ethernet, and Gigabit Ethernet

(c) PPP over Ethernet  (PPPoE)


Speed and Duplex

I guess this goes back to CSMA/CD roots with garden hose size coaxial cable (ThickNet) and vampire taps towards the more typical full-duplex things we see today.

The bus based network had everyone sitting on the same transmission medium (the MA part is multiple access).  When a station wanted to talk it needed to be sure no one else was talking before it tried to talk (CS as in carrier sense) since it is possible that someone started talking at the same time as you, you needed to listen and be sure you didn't hear something on the wire that was different to what you were transmitting (the something different was a collision - the CD is collision detect) if you detected that a collision occured, you would send out a Jam signal to ensure that the other transmitting station knew that there was a problem and you would both wait a random amount of time before trying to transmit again.  It wasnt the most efficient means, I think peak efficiency is somewhere around 50% of the link bandwidth but it was relatively cheap and allowed you to "easily" add hosts onto the network.  This kind of duplexing (capability for both transmit and recieving) is called half-duplex since only one station can talk at a time.

A full-duplex connection is a dedicated point-to-point connection with a dedicated line for transmission and reception meaning that collisions don't occur and you could potentially max the link in the transmit and receive directions.

Ethernet, Fast Ethernet, and Gigabit Ethernet

"Ethernet" interfaces can support 10Mbps and usually support full-duplex (some really old interfaces only do half-duplex)

"FastEthernet" interfaces can be configured to be 10Mbps or 100Mbps with either half or full duplex.

"GigabitEthernet" interfaces can be usually configured to be 10, 100 or 1000Mbps with either half or full duplex (however some GBIC or SFPs are capable of a single speed only)

Autonegotiation

The IEEE 802.3u standard which introduced FastEthernet allowed automatic negotiation of speed and duplex between endpoints.  If one side was hard set, with the other set for auto negotiate, it is possible to get a duplex mismatch if the hard set side was set for full-duplex (although auto negotiate can correctly select the speed for a hard set interface, it will assume half-duplex on the auto negotiate side)

Common practice used to be to not to use autonegotiation and hard set interface options, however recommendations these days are to have both sides be auto negotiate as items such as flow control can be appropriately negotiated and other keep alive mechanisms be used that would not otherwise be available.

PPPoE

A PPPoE configuration is relatively common in a situation where you have an Ethernet WAN device that is connected to an ADSL modem that is in a bridge configuration (the DSL mode bridges Ethernet Frames on to an ATM PVC which terminates on a BRAS/BNG of the ISP)

PPPoE has an 8 byte overhead so a typical 1500 Byte MTU interface will actually be 1492 bytes when using PPPoE (this may need to be considered if using a protocol such as OSPF)


PPPoE Client configuration example (CHAP Authentication of client, Obtain IP address from Server)

interface FastEthernet0/0
 description Ethernet WAN to PPPoE Server Fa0/0
 pppoe enable
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address negotiated previous
 encapsulation ppp
 dialer pool 1
 dialer persistent
 ppp chap hostname client ppp chap password 0 pppoe
!

PPPoE Server configuration (CHAP Authentication of Client against the local database and address allocation using IPCP) Note: PPPoE no longer uses VPDN configuration, and while IOS will convert to PPPoE VPDN config to a bba-group config once, it's best to know how to do it correctly.

aaa new-model
aaa authentication ppp default local

username client password 0 pppoe

ip dhcp excluded-address 192.168.200.254
ip dhcp pool PPPoE
 network 192.168.200.0 255.255.255.0
!
bba-group pppoe global
 virtual-template 1
!
interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 peer default ip address dhcp-pool PPPoE
 ppp authentication chap
!
interface FastEthernet0/0
 description Ethernet WAN to PPPoE Client Fa0/0
 ip address 192.168.200.254 255.255.255.0
 pppoe enable
!

Below is a debug ppp negotation and debug ppp authentication on the PPPoEServer as the client connects (interestingly, we see that CDP is not enabled across the connection)

*Mar  1 00:54:37.103: ppp7 PPP: Send Message[Dynamic Bind Response]
*Mar  1 00:54:37.103: ppp7 PPP: Using vpn set call direction
*Mar  1 00:54:37.107: ppp7 PPP: Treating connection as a callin
*Mar  1 00:54:37.107: ppp7 PPP: Session handle[3A000009] Session id[7]
*Mar  1 00:54:37.107: ppp7 PPP: Phase is ESTABLISHING, Passive Open
*Mar  1 00:54:37.107: ppp7 LCP: State is Listen
*Mar  1 00:54:37.187: ppp7 LCP: I CONFREQ [Listen] id 1 len 10
*Mar  1 00:54:37.191: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.191: ppp7 PPP: Authorization NOT required
*Mar  1 00:54:37.195: ppp7 LCP: O CONFREQ [Listen] id 1 len 19
*Mar  1 00:54:37.199: ppp7 LCP:    MRU 1492 (0x010405D4)
*Mar  1 00:54:37.199: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.199: ppp7 LCP: O CONFACK [Listen] id 1 len 10
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.211: ppp7 LCP: I CONFNAK [ACKsent] id 1 len 8
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP: O CONFREQ [ACKsent] id 2 len 19
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.215: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: I CONFACK [ACKsent] id 2 len 19
*Mar  1 00:54:37.227: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.227: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.227: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: State is Open
*Mar  1 00:54:37.227: ppp7 PPP: Phase is AUTHENTICATING, by this end
*Mar  1 00:54:37.231: ppp7 CHAP: O CHALLENGE id 1 len 23 from "R1"
*Mar  1 00:54:37.239: ppp7 CHAP: I RESPONSE id 1 len 27 from "client"
*Mar  1 00:54:37.243: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.247: ppp7 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar  1 00:54:37.251: ppp7 PPP: Sent CHAP LOGIN Request
*Mar  1 00:54:37.255: ppp7 PPP: Received LOGIN Response PASS
*Mar  1 00:54:37.255: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.259: ppp7 PPP: Send Message[Connect Local]
*Mar  1 00:54:37.279: ppp7 PPP: Bind to [Virtual-Access1.1]
*Mar  1 00:54:37.283: Vi1.1 PPP: Send Message[Static Bind Response]
*Mar  1 00:54:37.299: Vi1.1 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar  1 00:54:37.299: Vi1.1 CHAP: O SUCCESS id 1 len 4
*Mar  1 00:54:37.307: Vi1.1 PPP: Phase is UP
*Mar  1 00:54:37.311: Vi1.1 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 00:54:37.315: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:37.319: Vi1.1 PPP: Process pending ncp packets
*Mar  1 00:54:37.371: Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 00:54:37.371: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:37.383: Vi1.1 CDPCP: I CONFREQ [Not negotiated] id 1 len 4
*Mar  1 00:54:37.383: Vi1.1 LCP: O PROTREJ [Open] id 3 len 10 protocol CDPCP (0x820701010004)
*Mar  1 00:54:39.275: Vi1.1 IPCP: Timeout: State REQsent
*Mar  1 00:54:39.279: Vi1.1 IPCP: O CONFREQ [REQsent] id 2 len 10
*Mar  1 00:54:39.283: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.375: Vi1.1 IPCP: Pool returned 192.168.200.20
*Mar  1 00:54:39.379: Vi1.1 IPCP: O CONFNAK [REQsent] id 1 len 10
*Mar  1 00:54:39.379: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.383: Vi1.1 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 00:54:39.387: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.387: Vi1.1 IPCP: ID 1 didn't match 2, discarding packet
*Mar  1 00:54:39.391: Vi1.1 IPCP: I CONFACK [REQsent] id 2 len 10
*Mar  1 00:54:39.395: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.399: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:39.399: Vi1.1 IPCP: O CONFNAK [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: O CONFACK [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.411: Vi1.1 IPCP: State is Open
*Mar  1 00:54:39.431: Vi1.1 IPCP: Install route to 192.168.200.20


On the server, if we execute a show users, we can see the client is connected based on the CHAP user name, the VirtualAccess Interface it is terminated on and the assigned IP address

Server#sh users
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface    User               Mode         Idle     Peer Address
  Vi1.1        client             PPPoE        -        192.168.200.20

Client# sh ip route connected
C    192.168.10.0/24 is directly connected, FastEthernet0/1
     192.168.200.0/32 is subnetted, 2 subnets
C       192.168.200.254 is directly connected, Dialer1
C       192.168.200.20 is directly connected, Dialer1

No comments:

Post a Comment