Posts Tagged ‘tutorial’

The BSCI exam and CCNP certification requires that you be well versed in the basics of IP Version 6, or IPv6. If you’re new to IPv6, you’ll quickly learn that it’s not exactly just two more octets slapped onto an IPv4 address! IPv6 addresses are quite long, but there are two ways to acceptably shorten IPv6 address expression. To pass the BSCI exam, become a CCNP, and get that all-important understanding of IPv6, you’ve got to understand these different methods of expressing an IPv6 address. My last IPv6 tutorial discussed zero compression; today we’ll take a look at leading zero compression.

Leading zero compression allows us to drop the leading zeroes from every field in the address. Where we could only use zero compression once in an IPv6 address expression, leading zero compression can be used as often as is appropriate. The key with leading zero compression is that there must be at least one number left in each field, even if that remaining number is a zero.

You sometimes see books or websites refer to leading zero compression as “dropping zeroes and replacing them with a colon”, but that explanation can be a little confusing, since the blocks are separated with a colon to begin with. You’re not really replacing the leading zeroes, you’re dropping them.

Let’s look at an example of leading zero compression. Taking the address 1234:0000:1234:0000:1234:0000:1234:0123, we have four different fields that have leading zeroes. The address could be written out as it is, or drop the leading zeroes.

Read the rest of this entry »

Policy routing is a major topic on your BSCI exam, and you’ll find quite a bit of policy routing going on in today’s production networks. But what exactly is policy routing?

Policy-based routing, generally referred to as “policy routing”, is the use of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to the CCIE (or to a Cisco Quality Of Service certification), you’ll find that traffic can be “marked” by policy routing in order to give different levels of service to various classes of traffic. (This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give some traffic higher priority for transmission.)

There are some basic policy routing rules you should know:

Policy routing doesn’t affect the destination of the packet, but does affect the path that is taken to get there.

Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).

Policy routing can be configured at the interface level, or globally.

Applying policy routing on an interface affects only packets arriving on that interface:

R2(config)#int s0

R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.

Whether you’re running policy routing at the interface level, on packets created locally, or both, always run the command show ip policy to make sure you’ve got the right route maps on the proper interfaces.

R2#show ip policy

Interface Route map

local CHANGE_NEXT_HOP

Serial0 CHANGE_NEXT_HOP

And here’s the big rule to remember….

If a packet doesn’t match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally. If you don’t want to route packets that do not meet any route map criteria, the set command must be used to send those packets to the null0 interface. This set command should be the final set command in the route map.
Read the rest of this entry »

A major part of your BSCI and CCNP exam success is mastering BGP, and that includes filtering BGP routing updates. In this tutorial, we’ll take a look at how to filter BGP updates with prefix lists.

R4 is advertising three networks via BGP. The downstream router R3 sees these routes and places them into its BGP table as shown below. R3 has two downstream BGP peers, R1 and R2, and is advertising itself as the next-hop IP address for all BGP routes sent to those two routers.

R4(config)#router bgp 4

R4(config-router)#network 21.0.0.0 mask 255.0.0.0

R4(config-router)#network 22.0.0.0 mask 255.0.0.0

R4(config-router)#network 23.0.0.0 mask 255.0.0.0

R3#show ip bgp

BGP table version is 4, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Read the rest of this entry »

CCNA exam success depends on mastering many technologies that are new to you, and few exam topics have more details than ISDN. ISDN isn’t just for your CCNA exam studies, though. While ISDN is dismissed by many, the fact is that there are many small and mid-size networks out there that use ISDN as their backup to frame relay. Some of these companies have spoke networks that use ISDN to connect to their hub as well, so it’s a great idea to know ISDN configuration and troubleshooting for your real-world career as well as passing the CCNA. With that in mind, let’s take a look at five common ISDN errors and how to avoid them.

With dialer map statements, remember that the phone number you put in the dialer map is the phone number of the remote router, not the local one. Look at it this way – if you want to call a friend on your cell, you don’t pick up your cell and dial your own number!

Speaking of dialer map statements, don’t forget the all-important broadcast option at the end of the command:

R1(config-if)#dialer map ip 172.12.21.1 name R2 broadcast 5555555

The router will accept that command without the “broadcast” option, but routing protocol updates and hellos would not be able to travel across the line. (This command is also needed in frame relay map statements to allow broadcasts and multicasts to be transmitted.)

PAP is PPP’s clear-text authentication scheme, and clear text is a really bad idea. But if you do have to configure it, don’t forget that PAP requires additional configuration -the ppp pap sent-username command.

R1(config-if)#ppp pap sent-username R1 password CISCO

Must set encapsulation to PPP before using PPP subcommands

R1(config-if)#

The error message we got while configuring the sent-username command is another important reminder – by default, a BRI line is running HDLC, not PPP. Since HDLC doesn’t allow us to use either PAP or CHAP, we’ll need to set the link to PPP with the encapsulation ppp command.

R1(config-if)#encapsulation ppp

R1(config-if)#ppp authentication pap

R1(config-if)#ppp pap sent-username R1 password CISCO

But before we configure any of this information, we should configure the ISDN switch-type. Why? Because without the switch-type configuration, it doesn’t matter that we avoid the other four errors – the line will not come up. Configure the switch-type with the “isdn switch-type” command, and then verify it with “show isdn status”.

R1(config)#isdn switch-type basic-ni
Read the rest of this entry »