Subnetting Made Easy And Other Cisco Tidbits

CCIE - Warm-Up Phase - OSPF
Wednesday, 20 April 2011

This is in relation to INE Workbook 1 and their 48 week program to get up to speed with passing the CCIE exam.

What have I learned?

6.1 - A network statement of "network 0.0.0.0 0.0.0.0 area 0" gets changed to "network 0.0.0.0 255.255.255.255 area 0" which is basically a single network statement that covers all interfaces.

6.2 - By default Frame Relay defaults to an OSPF network type of non-broadcast. This means that a DR/BDR is elected, however, hellos are sent as UNICASTS therefore you must configure static neighbor commands. This needs to be done only on one end of the link but it may be best practice to configure it at both ends for clarity. In addition, as a DR is elected it does not change the next-hop value when it sends out Type 2 LSAs hence spoke routers need a path to the next-hop value via the PVC to the hub (e.g. frame-relay map ip 155.1.0.4 105 -- this will send traffic to 155.1.0.4 via DLCI 105 which is the PVC to R5 which is the hub for this network).

6.4 - Point-to-point uses multicast hellos and no need for DR/BDR election or neighbor statements.

6.5 - Point-to-multipoint. As this is over Frame Relay and the initial Frame Relay maps did not include the "broadcast" keyword no adjacencies formed. Point-to-multipoint uses multicast hellos so you have to specify the "broadcast" keyword. There are also no DR/BDR elections so the hub (R5 in this case) changes the next-hop to itself (155.1.0.5). As each router (R1 to R4) has a Frame Relay map to R5 full-reachability is made.

6.6 - Point-to-multipoint non-broadcast. The only difference here is that it sends hellos as unicast and requires a neighbor statement.

6.7 - Changing the network type on Loopback interfaces to point-to-point advertises the network with its correct mask (in this example /24) rather than the default Loopback type which advertises them as a stub with a /32 even if they are not configured as /32.

6.8 - The reference bandwidth is configured in Mbps.

6.10 - OSPF Path selection with Bandwidth - Change the bandwidth on an interface that RECEIVES the LSA and that is downstream from the device you wish to be affected (e.g. this example requires R6 to route via R1 so change the bandwidth value on R1 Se0/0 to a greater value to affect the overall cost. Note that R1, R4, and R6 share an Ethernet segment)

6.11 - Changing the cost per neighbor. To find out what cost OSPF would assign a bandwidth value change the bandwidth on an interface and use "show ip ospf interface | inc Cost" to find out that value. Assign that value to the neighbor using "neighbor cost ". Don't forget to change the bandwidth back to the correct value!

6.12 - If a router connects two areas together and neither of those areas are Area 0 then the ABR will not act as an ordinary ABR and will not forward Inter-Area routes as all Inter_Area routes must be advertised via Area 0. Therefore you need to use a Virtual Link.

6.13 - OSPF Path Selection with Non-Backbone Transit Areas. After the virtual link was formed and I adjusted some costs on R4, routes to SW2 were being routed via Area 1 (specifically, via R4) and not to R1 even though that link is effectively Area 0 as it is a virtual link. To allow the use of the virtual link you must use "no capability transit" command at BOTH ends of the virtual link.

6.14 - OSPF virtual links will not come up if the cost used to reach the other end of the virtual link is 65535 which is the maximum cost associated with an interface. You must therefore change the OSPF cost at BOTH ENDS of the virtual link.

Posted byChris Bloomfield at 16:58 0 comments  

Labels: CCIE, ine, ine workbook 1, ospf, virtual link

RIP - Adjusting default timers
Saturday, 9 April 2011

In my last post about RIP I mentioned quite a few different bits of RIP. Here I just want to focus on changing the timers and how to override the timers.

You can adjust your timers using the timers basic update invalid holddown flush under the routing process:

router rip
version 2
timers basic 30 90 120 120

This will set the update to 30 secs, invalid to 90 secs, holddown to 120 secs, and flush to 120 secs.

What would happen if you need to change that behaviour on just one link? Well, we can configure the update timer under the interface:

interface fa0/0
ip rip advertise 30

This then changes the advertise time to 30 seconds but note that this doesn't change the other timers, only the advertise time!

Posted byChris Bloomfield at 07:56 0 comments  

Labels: RIP, RIPv1, RIPv2

PPP Authentication - Using AAA
Monday, 21 March 2011

Here we'll try to authenticate a session between two routers. One side of the router will use RADIUS while the other will use TACACS+. The side using RADIUS will be configured using a AAA server group. The TACACS+ server will be globally configured. Both RADIUS and TACACS+ use "cisco" as the password.

Router 1

1. Configure a new AAA model

aaa new-model

2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".

aaa authentication login CONSOLE none
!
line vty 0 4
login authentication CONSOLE

3. Configure a RADIUS server group called MY_RADIUS_GROUP and ensure that the RADIUS server at 192.168.1.1 only applies to this group.

aaa group server radius MY_RADIUS_GROUP
server-private 192.168.1.1 key cisco

4. Configure AAA to authenticate PPP sessions against the RADIUS server group and if that fails it should try the local database.

aaa authentication ppp PPP_AUTH group MY_RADIUS_GROUP local

5. Configure the phyiscal interface to use the AAA authentication session

interface s0/0
ppp authentication PPP_AUTH

Router 2

1. Configure a new AAA model

aaa new-model

2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".

aaa authentication login CONSOLE none
!
line vty 0 4
login authentication CONSOLE

3. Configure a TACACS+ server group globally at 192.168.1.2

tacacs-server host 192.168.1.2 key cisco

4. Configure AAA to authenticate PPP sessions against the TACACS+ server and if that fails it should try the local database.

aaa authentication ppp default group tacacs local

5. Configure the phyiscal interface to use the AAA authentication session

interface s0/0
ppp authentication PPP_AUTH

Posted byChris Bloomfield at 14:17 1 comments  

Labels: aaa, ppp

When to use access-lists or prefix-lists
Sunday, 20 March 2011

Here's a great a bit of info that I pulled from INE's own Brian McGahan that is is worth remembering. Thanks Brian!

Some applications you can use both access-lists and prefix-lists. In general, anytime you are matching a route, like with a route-map for redistribution, a route-map for BGP, or a distribute-list, you should use a prefix-list. This is what they were designed for. An access-list should be used any time you’re trying to match traffic, or with other non-routing related applications.

Source: http://ieoc.com/forums/t/15006.aspx

Posted byChris Bloomfield at 08:31 0 comments  

Labels: access-lists, ine, prefix-lists

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