Subnetting Made Easy And Other Cisco Tidbits

PPPoE Server and Client
Saturday, 19 March 2011

I've done a load of Cisco 877 configurations in the past on ADSL lines and wondered how all of the virtual template stuff works so here's a lesson as to how to configure PPPoE Server and Client with the Server providing the Client with an IP address using DHCP.

We will also get the Server to authenticate the Client using CHAP and the Server will rate-limit the Client to a maximum of 10 sessions per minute over a period of 5 minutes.

Let's start with the Client as it is the least amount of work.

Client Tasks

1. Configure a Dialer interface
a. It should receive the IP address from the Server
b. Have PPP configured
c. Be part of a Dialer Pool
d. Set the CHAP hostname
e. Set the CHAP password

interface Dialer1
ip address dhcp
encapsulation ppp
dialer pool 1
ppp chap hostname Router1
ppp chap password cisco

2. Tie the Dialer to a physical interface
a. Remove any IP address from the interface
b. Enable PPPoE
c. Configure PPPoE to match the Dialer Pool

interface FastEthernet0/1
no ip address
pppoe enable
pppoe-client dial-pool-number 1

Server Tasks

1. Configure a Virtual Template interface
a. Apply an IP address
b. Apply PPP encapsulation
c. Enable CHAP authentication

interface Virtual-Template1
ip address 192.168.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap

2. Create a Broadband Aggregation Group
a. Give the group a name
b. Tie the Virtual-Template to the group
c. Throttle the client to 10 sessions per minute over a period of 5 minutes.

bba-group pppoe MY_BBA_GROUP
virtual-template 1
sessions per-mac throttle 10 60 300

3. Configure the physical interface connected to the client
a. Tie the physical interface to the BBA group

interface FastEthernet0/1
pppoe enable group MY_BBA_GROUP

4. Create a DHCP pool for the client
a. Exclude the IP address assigned to the Virtual Template interface

ip dhcp excluded-address 192.168.1.1
ip dhcp pool MY_PPPoE_POOL
network 192.168.1.0

5. Create a username/password pair for Router1 for authentication

username Router1 password cisco

That's it. It takes a little while for it to kick in but worth trying to lab.

Cheers,

Chris

Posted byChris Bloomfield at 14:34 1 comments  

Labels: ppp, pppoe, pppoe client, pppoe server

PPP Authentication - PAP and CHAP
Friday, 18 March 2011

I don't really use serial interfaces in my day-to-day job so when it comes to lab questions regarding PPP, HDLC, and Frame Relay I am immediately horrified.

Here's the question given:

1. Enable PPP encapsulation for the Serial link connecting R4 and R5 and use the IP subnet 155.1.45.0/24 for this link.

2. R4 should attempt to authenticate R5 using PAP and then CHAP. R5 should refuse PAP authentication and use CHAP.

3. Make sure R4 uses an alternate CHAP hostname R4CHAP.

4. Use the name R5CHAP and the password of CISCO to accomplish this.

5. R5 should authenticate R4 using PAP only. R4 should use the name R4PPP and the password of CISCO.

Let's say that s0/0 is the interface at either end and R4 is the DCE.

Step 1:

Apply PPP, clock rate on R4, and IP address.

R4:

interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0

R5:

interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0

Step 2:

R4 needs to authenticate R5 using PAP, and if it is refused, should use CHAP. R5 will be configured to refuse PAP authentication from R4.

R4:

interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap

R5:

interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse

Step 3:

R4 needs to specify a CHAP hostname of R4CHAP. If this wasn't specified then the CHAP hostname would be set as the hostname of the router (in this case, R4).

R4:

interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP

R5:

interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse

Step 4:

R5 should respond with a CHAP hostname of R5CHAP and a CHAP password of CISCO. Therefore on R4 we must configure a username/password pair for R5's details. What isn't obvious is that R5 needs a username/password pair for R4's details. In this case the R4 CHAP hostname is R4CHAP and the password must match R5's CHAP password which is CISCO.

R4:

username R5CHAP password CISCO
!
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP

R5:

username R4CHAP password CISCO
!
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
ppp chap hostname R5CHAP

Step 5:

R5 wants to authenticate R4 using PAP and R4 responds with a PAP username of R4PPP and a PAP password of CISCO.

R4:

username R5CHAP password CISCO
!
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP
ppp pap sent-username R4PPP password CISCO

R5:

username R4CHAP password CISCO
!
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
ppp chap hostname R5CHAP
ppp authentication pap

That's it. Not too bad but worth working through to see how it all fits together.

Posted byChris Bloomfield at 13:16 0 comments  

Labels: authentication, chap, pap, ppp

Multicast RPF
Wednesday, 16 March 2011

Right then, I'm happy with RPF as a principle and that the router checks the interface on which it receives multicast traffic and consults its routing table to see if that interface would be used to reach the multicast source.

What I didn't know (or at least I hadn't remembered) until now is that when there are equal-cost paths to the multicast source (e.g. OSPF, EIGRP etc) the router must pick one of them for Multicast RPF. Which one does it pick? It picks the one with highest neighbouring router ID.

For example, let's say that the multicast RP is located on 192.168.1.0/24 network. You downstream router receives two equal-cost routes for that subnet, one from R1 with a router-id of 1.1.1.1 and the other from R2 with a router-id of 2.2.2.2. The router will pick the interface connected to R2 as it has the highest router-id.

You can frig this by using tunnelling but that is a whole new ball game and one I'm not going into right now.

Posted byChris Bloomfield at 11:06 0 comments  

CCIE Study - Written v4 Chapters 1 to 3 - 22/02/10
Tuesday, 22 February 2011

Well I've learned lots actually, or more accurately put, I remembered lots of stuff that I had forgotten. Stupid stuff that I should have known right off the bat but slipped the mind.

Etherchannel
Cisco recommends for PAgP that both ends of the link be configured as Desirable.

Ethernet Basics
802.3ab defines GigabitEthernet over UTP whereas 802.3z defines GigabitEthernet over Fibre. 802.3u defines FastEthernet.

MAC addresses are in canonical format which means that the most significant bit is on the right. Take the first two hexidecimal values from a MAC address and convert them to binary to give you an 8-bit string. The Individual/Group bit (I/G) is the right-most bit (i.e. the most signficant bit). If that is set to 0 then the MAC address is a unicast. If it is set to 1 then the MAC address is a broadcast or multicast. The second right-most bit is the Universal/Local bit (U/L). If this is set to 0 then the MAC address has been assigned by the vendor. If it is set to 1 then the MAC address has been administratively assigned.

Q-in-Q
VPLS and EoMPLS offer alternatives to Q-in-Q.

Spanning Tree
If a switch does not have any trunks configured at boot time but has the "spanning-tree root primary" command issued the priority of the switch will go to 24576 which is 8192 less than the default priority of 32768. If a trunk link is then formed and a switch has a higher priority then it will become the root and not the one with the root primary macro.

If you want to configure BPDUGuard at interface level you must take off any interface-level PortFast configuration first.

If running 802.1D and the root port does not receive any BPDUs the switch will wait for the Max Age timer to expire (default 20 seconds) before using another port.

Port priority and port number when used as a tiebreaker are those on the advertising switch and not on the switch that receives the BPDU.

If a root port fails then switchover to an alternative port is almost immediate.

SPAN/RSPAN
Destination ports do not forward Layer 2 protocols such as CDP, DTP, VTP, and STP.

Up to 64 destination ports may be configured.

The monitor session number can range between 1 and 66.

VLANs
The only VLANs that can be pruned are VLANs 2-1001. VLANs 1, and 1002-1005 are not prune eligible and can never be deleted.

Posted byChris Bloomfield at 18:37 0 comments  

Labels: CCIE

Frame Relay - BECN/FECN
Saturday, 19 February 2011

BECN - Backward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the destination and sent BACK to the originator indicating congestion in the path and to slow down transmission of data.

FECN - Forward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the sender and is FORWARDED to the destination to indicate congestion in the path and to slow down requests for data.

Note that these are set by a Frame Relay switch in general so are received by a router rather than sent by a router.

Posted byChris Bloomfield at 14:27 0 comments  

Labels: becn, fecn, frame relay

How to calculate multicast MAC address
Thursday, 17 February 2011

Hi,

It's been a while but here's a quick post on how to calculate a multicast MAC address from an IP address.

The first half of a multicast MAC address is 01-00-5E so we need to work out the second half.

To do this we need to convert the last 23 bits of the IP address in question. If you think about this we are not using the high order bit in the second octet which carries a value of 128. Therefore it must follow that a value of 6 in the second octet must be the same as 134 in the second octet as the high-order bit (i.e. a value of 128) is ignored.

So this leads to a simple method. Let us try and convert 192.168.35.1 to a multicast MAC address

1. Start with a half-filled multicast MAC address of 01-00-5E-XX-YY-ZZ

2. To calculate the value of XX take the second octet. If the value of the second octet is greater than 128 then subtract 128 from the second octet. In this example, the value of 168 is greater than 128 so we subtract 128 from 168 to give us a value of 40. Convert this value to hexadecimal. Decimal 40 = 0x28. Our multicast MAC address is now 01-00-5E-28-YY-ZZ

3. To calculate the value of YY take the third octet and convert it to hex. In this example the value is 35 which equals 0x23. Our multicast MAC address is now 01-00-5E-28-23-ZZ

4. To calculate the value of ZZ take the fourth octet and convert it to hex. In this example the value is 1 which equals 0x01. Our multicast MAC address is now 01-00-5E-28-23-01

So 192.168.35.1 has a multicast MAC address of 01-00-5E-28-23-01.

Can you spot an issue here? Hopefully you can. Basically any IP address with 40.35.1 or 168.35.1 as the last three octets carry the same multicast MAC address so you have potentially 32 addresses with the same multicast MAC address!

Back to the books for me!

Good luck with your studies.

Posted byChris Bloomfield at 20:48 2 comments  

Labels: 01-00-5E, calculate multicast MAC, machine, multicast, multicast MAC address

CCNP Training in the UK with Networks Inc
Sunday, 21 November 2010

Guys,

Posted byChris Bloomfield at 13:11 0 comments  

Labels: best ccnp training, ccnp, ccnp training uk, training, uk