QoS - Quality of Service - is a huge topic on both the BCMSN exam and real-world networks. QoS is so big today that Cisco's created separate specialist certifications that cover nothing but QoS! It can be an overwhelming topic at first, but master the fundamentals and you're on your way to exam and job success.
If you work with QoS at any level - and sooner or later, you will - you've got to know how to write and apply QoS policies.
Creating and applying such a policy is a three-step process.
1. Create a QoS class to identify the traffic that will be affected by the policy.
2. Create a QoS policy containing the actions to be taken by traffic identified by the class.
3. Apply the policy to the appropriate interfaces.
If the phrase "identify the traffic" sounds like it's time to write an access-list, you're right! Writing an ACL is one of two ways to classify traffic, and is the more common of the two. Before we get to the less-common method, let's take a look at how to use an ACL to classify traffic.
You can use either a standard or extended ACL with QoS policies. The ACL will be written separately, and then called from the class map.
SW1(config)#access-list 105 permit tcp any any eq 80
SW1(config)#class-map WEBTRAFFIC
SW1(config-cmap)#match access-group 105
Now that we've identified the traffic to be affected by the policy, we better get around to writing the policy! QoS policies are configured with the policy-map command, and each clause of the policy will contain an action to be taken to traffic matching that clause.
SW1(config)#policy-map LIMIT_WEBTRAFFIC_BANDWIDTH
SW1(config-pmap)#class WEBTRAFFIC
SW1(config-pmap-c)#police 5000000 exceed-action drop
SW1(config-pmap-c)#exit
This is a simple policy, but it illustrates the logic of QoS policies. The policy map LIMIT_WEBTRAFFIC_BANDWIDTH calls the map-class WEBTRAFFIC. We already know that all WWW traffic will match that map class, so any WWW traffic that exceeds the stated bandwidth limitation will be dropped.
Finally, apply the policy to the appropriate interface.
SW1(config-if)#service-policy LIMIT_WEBTRAFFIC_BANDWIDTH in
Getting your CCNP is a great way to boost your career, and learning QoS is a tremendous addition to your skill set. Like I said, learn the fundamentals, don't get overwhelmed by looking at QoS as a whole, and you're on your way to success!
Showing posts with label list. Show all posts
Showing posts with label list. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BSCI Exam Tutorial: Using Distribute Lists
To be successful on the BSCI exam and in earning your CCNP, you've got to master route redistribution. This isn't as easy as it sounds, because configuring route redistribution is only half the battle. Whether it's on an exam or in a real-world production network, you've got to identify possible points of trouble before you configure route redistribution - and you need to be able to control redistribution as well. You may have an OSPF domain with 100 routes, but only need to redistribute 10 of them into a neighboring RIPv2 domain. You've got to know how to do that, and one method is the use of a distribute-list.
A distribute-list is an access-list that is used to determine what routes can and cannot be redistributed. Distribute-lists let you specify what routes will be filtered from the process. You can use standard or extended ACLs, and you can filter routes that are coming into a routing process or being injected into another process.
In the following example, R1 is redistributing RIP routes into OSPF, but only wants to advertise network 150.1.1.0 /24 to other OSPF routers. An ACL will be written to match that particular network, and then the distribute-list will be written under the routing process. I'm going to show you the IOS Help output for the distribute-list command, and please note that routing updates can be controlled at the interface level or protocol level.
R1(config)#access-list 24 permit 150.1.1.0 0.0.0.255
R1(config)#router ospf 1
R1(config-router)#redistribute rip subnets
R1(config-router)#distribute-list 24 ?
in Filter incoming routing updates
out Filter outgoing routing updates
R1(config-router)#distribute-list 11 out ?
Async Async interface
BRI ISDN Basic Rate Interface
BVI Bridge-Group Virtual Interface
CTunnel CTunnel interface
Dialer Dialer interface
Ethernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
Multilink Multilink-group interface
Null Null interface
Serial Serial
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-Template Virtual Template interface
Virtual-TokenRing Virtual TokenRing
bgp Border Gateway Protocol (BGP)
connected Connected
egp Exterior Gateway Protocol (EGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igrp Interior Gateway Routing Protocol (IGRP)
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes
R1(config-router)#distribute-list 11 out rip
Using distribute-lists does guard against routing loops, but they have other purposes. You may have a network segment that should be kept secret from the rest of your company; a distribute-list can filter that segment's network number from the redistribution process. In this way, distribute-lists serve as a basic form of network security. (Very basic. I wouldn't sell that firewall on ebay if I were you.)
Keeping such networks out of routing updates and routing tables throughout the network has the side effect of reducing routing update overhead as well.
A distribute-list is an access-list that is used to determine what routes can and cannot be redistributed. Distribute-lists let you specify what routes will be filtered from the process. You can use standard or extended ACLs, and you can filter routes that are coming into a routing process or being injected into another process.
In the following example, R1 is redistributing RIP routes into OSPF, but only wants to advertise network 150.1.1.0 /24 to other OSPF routers. An ACL will be written to match that particular network, and then the distribute-list will be written under the routing process. I'm going to show you the IOS Help output for the distribute-list command, and please note that routing updates can be controlled at the interface level or protocol level.
R1(config)#access-list 24 permit 150.1.1.0 0.0.0.255
R1(config)#router ospf 1
R1(config-router)#redistribute rip subnets
R1(config-router)#distribute-list 24 ?
in Filter incoming routing updates
out Filter outgoing routing updates
R1(config-router)#distribute-list 11 out ?
Async Async interface
BRI ISDN Basic Rate Interface
BVI Bridge-Group Virtual Interface
CTunnel CTunnel interface
Dialer Dialer interface
Ethernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
Multilink Multilink-group interface
Null Null interface
Serial Serial
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-Template Virtual Template interface
Virtual-TokenRing Virtual TokenRing
bgp Border Gateway Protocol (BGP)
connected Connected
egp Exterior Gateway Protocol (EGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igrp Interior Gateway Routing Protocol (IGRP)
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes
R1(config-router)#distribute-list 11 out rip
Using distribute-lists does guard against routing loops, but they have other purposes. You may have a network segment that should be kept secret from the rest of your company; a distribute-list can filter that segment's network number from the redistribution process. In this way, distribute-lists serve as a basic form of network security. (Very basic. I wouldn't sell that firewall on ebay if I were you.)
Keeping such networks out of routing updates and routing tables throughout the network has the side effect of reducing routing update overhead as well.
Cisco CCNP / BSCI Exam Tutorial: Filtering BGP Updates With Prefix
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
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 21.0.0.0 10.2.2.4 0 0 4 I
*> 22.0.0.0 10.2.2.4 0 0 4 I
*> 23.0.0.0 10.2.2.4 0 0 4 I
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 next-hop-self
R3(config-router)#neighbor 172.12.123.2 next-hop-self
In turn, both R1 and R2 have these three routes in their respective BGP tables.
R2#show ip bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
*>i22.0.0.0 172.12.123.3 0 100 0 4 I
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
R1#show ip bgp
BGP table version is 4, local router ID is 19.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
*>i22.0.0.0 172.12.123.3 0 100 0 4 I
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
If we wanted R3 to receive all three of these routes from R4 but not advertise all of them to R2 and R1, we've got a couple of options on how to block these routes. Cisco's recommendation is the use of prefix-lists, and once you get used to the syntax (which you should do before taking and passing the BSCI), you'll see they are actually easier to use than access-lists.
In this case, we're going to configure R3 to send only the route to 21.0.0.0 to R1 and 23.0.0.0 to R2. However, we do want these two routers to get any future routes that R4 advertises into BGP.
Since R1 and R2 will learn about these routes from an iBGP neighbor, they will not advertise the routes to each other.
On R3, we'll write a prefix-list that denies 22.0.0.0/8 and 23.0.0.0/8, but permits all other routes. After applying the prefix list as shown, R1 sees only the 21.0.0.0 /8 route.
R3(config)#ip prefix-list FILTER_R1 deny 22.0.0.0/8
R3(config)#ip prefix-list FILTER_R1 deny 23.0.0.0/8
R3(config)#ip prefix-list FILTER_R1 permit 0.0.0.0/0 le 32
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 prefix-list FILTER_R1 out
R3#clear ip bgp * soft
R1#show ip bgp
BGP table version is 6, local router ID is 19.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
The paths to 22.0.0.0/8 and 23.0.0.0/8 have been successfully filtered.
We'll do the same for R2, except the route not being expressly blocked is 23.0.0.0/8. The line "ip prefix-list permit 0.0.0.0/0 le 32" is the prefix list equivalent of a "permit any" statement in an ACL.
R3(config)#ip prefix-list FILTER_R2 deny 21.0.0.0/8
R3(config)#ip prefix-list FILTER_R2 deny 22.0.0.0/8
R3(config)#ip prefix-list FILTER_R2 permit 0.0.0.0/0 le 32
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.2 prefix-list FILTER_R2 out
R3#clear ip bgp * soft
R2#show ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
The paths to 21.0.0.0/8 and 22.0.0.0/8 have been successfully filtered.
To see the prefix lists configured on a route as well as the order of the statements in each list, run show ip prefix-list.
R3#show ip prefix-list
ip prefix-list FILTER_R1: 3 entries
seq 5 deny 22.0.0.0/8
seq 10 deny 23.0.0.0/8
seq 15 permit 0.0.0.0/0 le 32
ip prefix-list FILTER_R2: 3 entries
seq 5 deny 21.0.0.0/8
seq 10 deny 22.0.0.0/8
seq 15 permit 0.0.0.0/0 le 32
Get some hands-on practice with prefix lists and you'll quickly master them. Prefix lists are an important part of working with BGP in the exam room and production networks, so it's vital that you are comfortable working with them.
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
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 21.0.0.0 10.2.2.4 0 0 4 I
*> 22.0.0.0 10.2.2.4 0 0 4 I
*> 23.0.0.0 10.2.2.4 0 0 4 I
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 next-hop-self
R3(config-router)#neighbor 172.12.123.2 next-hop-self
In turn, both R1 and R2 have these three routes in their respective BGP tables.
R2#show ip bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
*>i22.0.0.0 172.12.123.3 0 100 0 4 I
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
R1#show ip bgp
BGP table version is 4, local router ID is 19.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
*>i22.0.0.0 172.12.123.3 0 100 0 4 I
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
If we wanted R3 to receive all three of these routes from R4 but not advertise all of them to R2 and R1, we've got a couple of options on how to block these routes. Cisco's recommendation is the use of prefix-lists, and once you get used to the syntax (which you should do before taking and passing the BSCI), you'll see they are actually easier to use than access-lists.
In this case, we're going to configure R3 to send only the route to 21.0.0.0 to R1 and 23.0.0.0 to R2. However, we do want these two routers to get any future routes that R4 advertises into BGP.
Since R1 and R2 will learn about these routes from an iBGP neighbor, they will not advertise the routes to each other.
On R3, we'll write a prefix-list that denies 22.0.0.0/8 and 23.0.0.0/8, but permits all other routes. After applying the prefix list as shown, R1 sees only the 21.0.0.0 /8 route.
R3(config)#ip prefix-list FILTER_R1 deny 22.0.0.0/8
R3(config)#ip prefix-list FILTER_R1 deny 23.0.0.0/8
R3(config)#ip prefix-list FILTER_R1 permit 0.0.0.0/0 le 32
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 prefix-list FILTER_R1 out
R3#clear ip bgp * soft
R1#show ip bgp
BGP table version is 6, local router ID is 19.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i21.0.0.0 172.12.123.3 0 100 0 4 I
The paths to 22.0.0.0/8 and 23.0.0.0/8 have been successfully filtered.
We'll do the same for R2, except the route not being expressly blocked is 23.0.0.0/8. The line "ip prefix-list permit 0.0.0.0/0 le 32" is the prefix list equivalent of a "permit any" statement in an ACL.
R3(config)#ip prefix-list FILTER_R2 deny 21.0.0.0/8
R3(config)#ip prefix-list FILTER_R2 deny 22.0.0.0/8
R3(config)#ip prefix-list FILTER_R2 permit 0.0.0.0/0 le 32
R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.2 prefix-list FILTER_R2 out
R3#clear ip bgp * soft
R2#show ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal
Origin codes: i - IGP, e - EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*>i23.0.0.0 172.12.123.3 0 100 0 4 I
The paths to 21.0.0.0/8 and 22.0.0.0/8 have been successfully filtered.
To see the prefix lists configured on a route as well as the order of the statements in each list, run show ip prefix-list.
R3#show ip prefix-list
ip prefix-list FILTER_R1: 3 entries
seq 5 deny 22.0.0.0/8
seq 10 deny 23.0.0.0/8
seq 15 permit 0.0.0.0/0 le 32
ip prefix-list FILTER_R2: 3 entries
seq 5 deny 21.0.0.0/8
seq 10 deny 22.0.0.0/8
seq 15 permit 0.0.0.0/0 le 32
Get some hands-on practice with prefix lists and you'll quickly master them. Prefix lists are an important part of working with BGP in the exam room and production networks, so it's vital that you are comfortable working with them.
Cisco CCNA Exam Tutorial: Configuring Standard Access Lists
Access Control Lists (ACLs) allow a router to permit or deny packets based on a variety of criteria. The ACL is configured in global mode, but is applied at the interface level. An ACL does not take effect until it is expressly applied to an interface with the ip access-group command. Packets can be filtered as they enter or exit an interface.
If a packet enters or exits an interface with an ACL applied, the packet is compared against the criteria of the ACL. If the packet matches the first line of the ACL, the appropriate “permit” or “deny” action is taken. If there is no match, the second line’s criterion is examined. Again, if there is a match, the appropriate action is taken; if there is no match, the third line of the ACL is compared to the packet.
This process continues until a match is found, at which time the ACL stops running. If no match is found, a default “deny” takes place, and the packet will not be processed. When an ACL is configured, if a packet is not expressly permitted, it will be subject to the implicit deny at the end of every ACL. This is the default behavior of an ACL and cannot be changed.
A standard ACL is concerned with only one factor, the source IP address of the packet. The destination is not considered. Extended ACLs consider both the source and destination of the packet, and can consider the port number as well. The numerical range used for each is different: standard ACLs use the ranges 1-99 and 1300-1399; extended lists use 100-199 and 2000 to 2699.
There are several points worth repeating before beginning to configure standard ACLs.
Standard ACLs consider only the source IP address for matches.
The ACL lines are run from top to bottom. If there is no match on the first line, the second is run; if no match on the second, the third is run, and so on until there is a match, or the end of the ACL is reached. This top-to-bottom process places special importance on the order of the lines.
There is an implicit deny at the end of every ACL. If packets are not expressly permitted, they are implicitly denied.
If Router 3’s Ethernet interface should only accept packets with a source network of 172.12.12.0, the ACL will be configured like this:
R3#conf t
R3(config)#access-list 5 permit 172.12.12.0 0.0.0.255
The ACL consists of only one explicit line, one that permits packets from source IP address 172.12.12.0 /24. The implicit deny, which is not configured or seen in the running configuration, will deny all packets not matching the first line.
The ACL is then applied to the Ethernet0 interface:
R3#conf t
R3(config)#interface e0
R3(config-if)#ip access-group 5 in
But before you write any ACLs, it's a really good idea to see what other ACLs are already running on the router! To see the ACLs running on the router, use the command show access-list.
R1#show access-list
Standard IP access list 1
permit 0.0.0.0
Standard IP access list 5
permit 172.1.1.1
Standard IP access list 7
permit 23.3.3.3
Extended IP access list 100
permit tcp any any lt www (26 matches)
permit tcp any any neq telnet (12 matches)
deny ip any any
Extended IP access list 105
deny tcp any any eq www
deny tcp any any eq telnet
You're going to use ACLs all the way up the Cisco certification ladder, and throughout your career. The importance of knowing how to write and apply ACLs is paramount, and it all starts with mastering the fundamentals!
If a packet enters or exits an interface with an ACL applied, the packet is compared against the criteria of the ACL. If the packet matches the first line of the ACL, the appropriate “permit” or “deny” action is taken. If there is no match, the second line’s criterion is examined. Again, if there is a match, the appropriate action is taken; if there is no match, the third line of the ACL is compared to the packet.
This process continues until a match is found, at which time the ACL stops running. If no match is found, a default “deny” takes place, and the packet will not be processed. When an ACL is configured, if a packet is not expressly permitted, it will be subject to the implicit deny at the end of every ACL. This is the default behavior of an ACL and cannot be changed.
A standard ACL is concerned with only one factor, the source IP address of the packet. The destination is not considered. Extended ACLs consider both the source and destination of the packet, and can consider the port number as well. The numerical range used for each is different: standard ACLs use the ranges 1-99 and 1300-1399; extended lists use 100-199 and 2000 to 2699.
There are several points worth repeating before beginning to configure standard ACLs.
Standard ACLs consider only the source IP address for matches.
The ACL lines are run from top to bottom. If there is no match on the first line, the second is run; if no match on the second, the third is run, and so on until there is a match, or the end of the ACL is reached. This top-to-bottom process places special importance on the order of the lines.
There is an implicit deny at the end of every ACL. If packets are not expressly permitted, they are implicitly denied.
If Router 3’s Ethernet interface should only accept packets with a source network of 172.12.12.0, the ACL will be configured like this:
R3#conf t
R3(config)#access-list 5 permit 172.12.12.0 0.0.0.255
The ACL consists of only one explicit line, one that permits packets from source IP address 172.12.12.0 /24. The implicit deny, which is not configured or seen in the running configuration, will deny all packets not matching the first line.
The ACL is then applied to the Ethernet0 interface:
R3#conf t
R3(config)#interface e0
R3(config-if)#ip access-group 5 in
But before you write any ACLs, it's a really good idea to see what other ACLs are already running on the router! To see the ACLs running on the router, use the command show access-list.
R1#show access-list
Standard IP access list 1
permit 0.0.0.0
Standard IP access list 5
permit 172.1.1.1
Standard IP access list 7
permit 23.3.3.3
Extended IP access list 100
permit tcp any any lt www (26 matches)
permit tcp any any neq telnet (12 matches)
deny ip any any
Extended IP access list 105
deny tcp any any eq www
deny tcp any any eq telnet
You're going to use ACLs all the way up the Cisco certification ladder, and throughout your career. The importance of knowing how to write and apply ACLs is paramount, and it all starts with mastering the fundamentals!
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: ISDN Details You Must Know
CCNA exam success depends partially on knowing the details of ISDN, and there are plenty of them! To help you review for your CCNA exam, here are a few ISDN details that you must know on exam day. (They help in the real world, too – and there are still plenty of ISDN networks out there!
The Cisco-proprietary version of HDLC is the default encapsulation type for serial and ISDN interfaces.
R2#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
While there’s only one D-channel in BRI, PRI (US) and PRI (EU), the bandwidth of that D-channel does vary from BRI to PRI. It’s 16 kbps in BRI and 64 kbps in both PRI versions.
The global command isdn switch-type must be configured before you can even begin to have ISDN work. show isdn status will tell you whether or not you’ve done this correctly.
R2#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = none
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
PAP allows passwords to be different; CHAP requires that they be the same.
PAP requires the “ppp pap sent-username” interface-level command. CHAP has no equivalent command.
Define interesting traffic with dialer-list and link that list to the interface with dialer-group.
R2#conf t
R2(config)#dialer-list 1 proto ip permit
R2(config)#int bri0
R2(config-if)#dialer-group 1
The dialer idle-timeout value is expressed in seconds, not minutes. (Even IOS Help isn’t totally clear on this.)
R2(config)#int bri0
R2(config-if)#dialer-group 1
R2(config-if)#dialer idle-timeout ?
<1-2147483> Idle timeout before disconnecting a call
R2(config-if)#dialer idle-timeout 120
Dialer map maps a remote IP address to a remote phone number. You never dial the local router’s phone number.
dialer load-threshold requires the ppp multilink command to be configured, and the value of dialer load-threshold is expressed as a ratio of 255, NOT 100. For example, if you want the second b-channel to come up when the first reaches 50% of capacity, the value to express with dialer load-threshold would be 50% of 255 – which equals 127.
R2(config)#int bri0
R2(config-if)#encap ppp
R2(config-if)#ppp multilink
R2(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
Success on the CCNA exam depends on knowing the details. Keep studying, keep practicing on real Cisco routers and switches, keep a positive attitude, and you're on your way to CCNA exam success!
The Cisco-proprietary version of HDLC is the default encapsulation type for serial and ISDN interfaces.
R2#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
While there’s only one D-channel in BRI, PRI (US) and PRI (EU), the bandwidth of that D-channel does vary from BRI to PRI. It’s 16 kbps in BRI and 64 kbps in both PRI versions.
The global command isdn switch-type must be configured before you can even begin to have ISDN work. show isdn status will tell you whether or not you’ve done this correctly.
R2#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = none
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
PAP allows passwords to be different; CHAP requires that they be the same.
PAP requires the “ppp pap sent-username” interface-level command. CHAP has no equivalent command.
Define interesting traffic with dialer-list and link that list to the interface with dialer-group.
R2#conf t
R2(config)#dialer-list 1 proto ip permit
R2(config)#int bri0
R2(config-if)#dialer-group 1
The dialer idle-timeout value is expressed in seconds, not minutes. (Even IOS Help isn’t totally clear on this.)
R2(config)#int bri0
R2(config-if)#dialer-group 1
R2(config-if)#dialer idle-timeout ?
<1-2147483> Idle timeout before disconnecting a call
R2(config-if)#dialer idle-timeout 120
Dialer map maps a remote IP address to a remote phone number. You never dial the local router’s phone number.
dialer load-threshold requires the ppp multilink command to be configured, and the value of dialer load-threshold is expressed as a ratio of 255, NOT 100. For example, if you want the second b-channel to come up when the first reaches 50% of capacity, the value to express with dialer load-threshold would be 50% of 255 – which equals 127.
R2(config)#int bri0
R2(config-if)#encap ppp
R2(config-if)#ppp multilink
R2(config-if)#dialer load-threshold ?
<1-255> Load threshold to place another call
Success on the CCNA exam depends on knowing the details. Keep studying, keep practicing on real Cisco routers and switches, keep a positive attitude, and you're on your way to CCNA exam success!
Cisco CCNA Certification Exam Tutorial: Access List Details You Must Know!
To pass the CCNA exam, you have to be able to write and troubleshoot access lists. As you climb the ladder toward the CCNP and CCIE, you'll see more and more uses for ACLs. Therefore, you had better know the basics!
The use of "host" and "any" confuses some newcomers to ACLs, so let's take a look at that first.
It is acceptable to configure a wildcard mask of all ones or all zeroes. A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly a wildcard mask of 255.255.255.255 means that all addresses will match the line.
Wildcard masks have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t
R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)#access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255.
R3(config)#access-list 15 permit any
Another often overlooked detail is the order of the lines in an ACL. Even in a two- or three-line ACL, the order of the lines in an ACL is vital.
Consider a situation where packets sourced from 172.18.18.0 /24 will be denied, but all others will be permitted. The following ACL would do that.
R3#conf t
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
R3(config)#access-list 15 permit any
The previous example also illustrates the importance of configuring the ACL with the lines in the correct order to get the desired results. What would be the result if the lines were reversed?
R3#conf t
R3(config)#access-list 15 permit any
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
If the lines were reversed, traffic from 172.18.18.0 /24 would be matched against the first line of the ACL. The first line is “permit any", meaning all traffic is permitted. The traffic from 172.18.18.0/24 matches that line, the traffic is permitted, and the ACL stops running. The statement denying the traffic from 172.18.18.0 is never run.
The key to writing and troubleshoot access lists is to take just an extra moment to read it over and make sure it's going to do what you intend it to do. It's better to realize your mistake on paper instead of once the ACL's been applied to an interface!
The use of "host" and "any" confuses some newcomers to ACLs, so let's take a look at that first.
It is acceptable to configure a wildcard mask of all ones or all zeroes. A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly a wildcard mask of 255.255.255.255 means that all addresses will match the line.
Wildcard masks have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t
R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)#access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255.
R3(config)#access-list 15 permit any
Another often overlooked detail is the order of the lines in an ACL. Even in a two- or three-line ACL, the order of the lines in an ACL is vital.
Consider a situation where packets sourced from 172.18.18.0 /24 will be denied, but all others will be permitted. The following ACL would do that.
R3#conf t
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
R3(config)#access-list 15 permit any
The previous example also illustrates the importance of configuring the ACL with the lines in the correct order to get the desired results. What would be the result if the lines were reversed?
R3#conf t
R3(config)#access-list 15 permit any
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
If the lines were reversed, traffic from 172.18.18.0 /24 would be matched against the first line of the ACL. The first line is “permit any", meaning all traffic is permitted. The traffic from 172.18.18.0/24 matches that line, the traffic is permitted, and the ACL stops running. The statement denying the traffic from 172.18.18.0 is never run.
The key to writing and troubleshoot access lists is to take just an extra moment to read it over and make sure it's going to do what you intend it to do. It's better to realize your mistake on paper instead of once the ACL's been applied to an interface!
Subscribe to:
Posts (Atom)
