The lab requirement states that the maximum output usage on fa0/1 should not exceed 75 percent of the maximum line rate.
This can be achieved by making use of the srr-queue bandwidth limit command. For the above requirement to be met configure the following:-
config#interface fa0/1
config-if#srr-queue bandwitdh limit 75
For verification use the
show mls qos int fa0/1 queueing command
N.B. A pre-requisite command is the global config command mls qos.
Saturday, May 9, 2009
Thursday, May 7, 2009
OSPF routing part XII - filter-list

Consider the above scenraio where router 2 is an ABR between areas 0,1 and 2. All adjacencies are up and full exchange of routes has taken place.
A new requirement is that area 2 is deemed confidential. Area 1 must not have access to any routes originating from Area 2.
This can be achieved by making using of the ospf filter-list functionality. First a prefix-list must be defined that indicates routes that must be filtered (and allowed!).
R2
ip prefix-list AREA2 deny 150.1.24.0/24
ip prefix-list AREA2 deny 150.1.40.40/32
ip prefix-list AREA2 permit 0.0.0.0/0 le 32
N.B. the last entry in the prefix list is essential to ensure all routes other than the previously denoted denied routes are allowed through.
On router 2 the filter-list can then be applied
R2
router ospf 1
area 1 filter-list prefix AREA2 in
When the routing table on R1 is subsequently examined the 150.1.24.0/24 and 150.1.40.40/32 routes are no longer present. Nice.
Tuesday, May 5, 2009
OSPF routing part XI - preferred neighbor
A hub router in an OSPF topology has two neighbors connected over a single serial interface. The hub router is learning the same routes from both neighbors. How can the hub router be configured to prefer routers from a particular neighbor?
The solution to this problem brought to light a configuration parameter that had previously missed my attention. When using the ospf 'neighbor' command a cost can also be applied to routes learned from that neighbor.
Hence to achieve the requirement laid out simply required this parameter to be set accordingly
i.e. below i set a lower cost for neighbor 2. This could be usefull in the scenario where neighbor 2 has a connection with greater bandwidth or reliability.
router ospf 1
neighbor {ip address 1} cost 200
neighbir (ip address 2} cost 100
The solution to this problem brought to light a configuration parameter that had previously missed my attention. When using the ospf 'neighbor' command a cost can also be applied to routes learned from that neighbor.
Hence to achieve the requirement laid out simply required this parameter to be set accordingly
i.e. below i set a lower cost for neighbor 2. This could be usefull in the scenario where neighbor 2 has a connection with greater bandwidth or reliability.
router ospf 1
neighbor {ip address 1} cost 200
neighbir (ip address 2} cost 100
OSPF routing part X - non broadcast FR
I recently came across a scenario where the requirement was to run OSPF over a frame-relay network. Normally this would represent a straightforward routing configuration. As ever with the CCIE the interesting part was that no broadcast keywords had been placed on the frame-relay map statements, and none were allowed.
If there are no broadcast capabilities on the underlying network this is not necessarily a problem for OSPF as long as a suitable OSPF non-broadcast network type is chosen.
I set the ospf network type to 'non-broadcast' and then 'point-to-multipoint non-broadcast' and these worked fine as long as the required neighbor statement was configured on the hub router.
If there are no broadcast capabilities on the underlying network this is not necessarily a problem for OSPF as long as a suitable OSPF non-broadcast network type is chosen.
I set the ospf network type to 'non-broadcast' and then 'point-to-multipoint non-broadcast' and these worked fine as long as the required neighbor statement was configured on the hub router.
Monday, April 27, 2009
Frame Relay Bridging

VLAN 16 and 22 are broadcast capable segments only. The requirement here is that these two networks are bridged together.
R1
int fa0/0
bridge-group 1
int s2/0
bridge-group 1
int BVI1
ip address 192.10.1.1 255.255.255.0
bridge irb
bridge 1 protocol ieee
bridge 1 route ip
int s2/0
frame-relay map bridge 102 br
R2
int fa0/0
bridge-group 1
int s2/0
bridge-group 1
int BVI1
ip address 192.10.1.2 255.255.255.0
bridge irb
bridge 1 protocol ieee
bridge 1 route ip
int s2/0
frame-relay map bridge 201 br
R1#s frame map
Serial2/0 (up): bridge dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
R1#p 192.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#p 192.10.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/44/68 ms
In the above config i also connect the bridge group to the router via the BVI router interface. Since the bridged segment is logically one segment i put the routable protocol information on the BVI, and its ip address applies to all interfaces in the bridge group. The IOS treats the BVI as any other interface and so enables routing between the bridge group and the routed interfaces in the router.
cisco doc
http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_transprnt_brdg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1004971
Saturday, April 25, 2009
Spanning Tree - portfast, bpduguard, bpdufilter

I use the above diagram to illustrate the interaction between the spanning tree features: portfast, bpdufilter and bpduguard.
For a long time whilst i understood the purpose of these features i did not understand how in particular bpdufilter and bpduguard interacted with each other.
I have at last resolved this confusion by running a wire capture to see for myself exactly what is going on.
First the basics
portfast - moves a port immediately to the forwarding state
bpdufilter - stops a port sending bpdus
bpduguard - error disables a port if bpdus are received
1)
config-if#spanning-tree portfast
Enabling portfast the port moves to forwarding state and from the capture i can see BPDUs still being sent.
2)
config-if#spanning-tree portfast
config-if#spanning-tree bpdufilter
I enable bpdufilter and BPDUS are no longer sent.
3)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard
I enable bpduguard and can see bpdus being sent. I was somewhat surprised by this as i had always treated bpduguard as a more severe version of bpdufilter. i.e. no bpdus sent with the guard feature set - Wrong!!
The enlightening moment for me was the realisation that to enforce no bpdus are sent and bpduguard is on perhaps requires bpdufilter to be enabled alongside bpduguard.
4)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard
config-if#spanning-tree bpdufilter
With the above commands i observed no bpdus being sent. I had previously assumed these features were mutually exclusive. They are not, they perform different functions and can be used alongside each other.
To observe bpdu guard in action i connected the port to another switchport that was sending bpdus.
I then observed the following...
01:03:26: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/24 with BPDU Guard enabled. Disabling port.
01:03:26: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/24, putting Fa0/24in err-disable state
01:03:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down
01:03:28: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down
Examining the port status
show int status err-disabled
Port Name Status Reason
Fa0/24 err-disabled bpduguard
To ensure auto recovery i entered the following commands
config#errdisable recovery cause bpduguard
config#errdisable recovery interval 30
I then applied bpdufilter to the neighboring switch port sending bpdus and the local port was automatically restored to normal service.
Friday, April 24, 2009
DHCP Snooping

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It differentiates between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.
To enable on a switch.
config#ip dhcp snooping
config#ip dhcp snooping vlan {n}
All DHCP servers must be connected to the switch through trusted interfaces. Hence the above config goes hand and hand with
config-if#ip dhcp snooping trust
Once dhcp snooping is enabled on a vlan enabled all ports are treated as untrusted by default.
During the process where a user port acquires an ip address via DHCP the switch builds a database of mac addresses and associated IP. Henceforth when a switch receives a packet on an untrusted interface the switch compares the source MAC address and the address in the DHCP binding database. Normally the addresses match and the switch forwards the packet. Conversely if they dont the switch drops the packet.
N.B. By default a switch inserts and removes DHCP relay information (option-82 field) in forwarded DHCP request messages to the DHCP server. Consequently it is necessary to enter the following command on the router
config-if#ip dhcp relay information trusted
Subscribe to:
Posts (Atom)