If there is a requirement to apply the same traffic shaping policy to a number of DLCI’s under the same interface this can be achieved by simply defining under each individual DLCI as follows
int s2/0
frame-relay traffic-shaping
frame-relay interface-dlci x
class generic
frame-relay interface-dlci y
class generic
frame-relay interface-dlci z
class generic
However this can also be achieved by simplying applying the class under the main physical interface.
Int s2/0
Frame-relay class generic
Tuesday, September 30, 2008
Frame Relay Traffic Shaping - Part I
Traffic shaping is designed to delay excess traffic whereas policing is designed to drop excess traffic.
A mock lab question stated apply a CIR of 128000 to an interface, ensure the minumum tc value is used and ensure no bursting above this rate is allowed.
The initial solution I applied was as follows…
I) create a frame-relay map class and apply the necessary parameters
map-class frame-relay 204
frame-relay tc 10
frame-relay cir 128000
frame-relay be 0
II) turn on traffic shaping and apply to the interface
Int s2/0
Frame-relay traffic-shaping
Frame-relay interface-dlcI 204
Class 204
To verify my solution I used the show traffic-shape command
Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active
204 128000 2000 128000 0 125 2000 -
I noticed from the above that despite explicitly setting the tc in the map-class statement it was NOT in use, instead the default 125 ms tc was still in effect!
In fact the correct method to manipulate the tc is by indirectly setting the bc (committed burst). Remembering the formula Bc = CIR * tc…
Now adjusting my solution accordingly I achieved the required result.
#map-class frame-relay 204
#no frame-relay tc 10
#frame-relay bc 1280
Show traffic-shape Interface Se2/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
204 128000 160 1280 0 10 160 -
A mock lab question stated apply a CIR of 128000 to an interface, ensure the minumum tc value is used and ensure no bursting above this rate is allowed.
The initial solution I applied was as follows…
I) create a frame-relay map class and apply the necessary parameters
map-class frame-relay 204
frame-relay tc 10
frame-relay cir 128000
frame-relay be 0
II) turn on traffic shaping and apply to the interface
Int s2/0
Frame-relay traffic-shaping
Frame-relay interface-dlcI 204
Class 204
To verify my solution I used the show traffic-shape command
Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active
204 128000 2000 128000 0 125 2000 -
I noticed from the above that despite explicitly setting the tc in the map-class statement it was NOT in use, instead the default 125 ms tc was still in effect!
In fact the correct method to manipulate the tc is by indirectly setting the bc (committed burst). Remembering the formula Bc = CIR * tc…
Now adjusting my solution accordingly I achieved the required result.
#map-class frame-relay 204
#no frame-relay tc 10
#frame-relay bc 1280
Show traffic-shape Interface Se2/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
204 128000 160 1280 0 10 160 -
Monday, September 29, 2008
Dot1x Authentication
The DOC cd is pretty good at providing the basic configuration that is necessary to achieve this.
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/sw8021x.html#wp1025133
Following the doc cd the config would be as follows:-
configure terminal
aaa new-model
aaa authentication dot1x default group radius
dot1x system-auth-control
radius-server host 1.2.3.4
radius-server key CISCO
int fa0/8
switchport mode access
dot1x port-control auto
One item of concern here is to not inadvertently lock yourself out of the switch. Once dot1x is enabled this will be used for all interfaces, console and vty, and unless an alternative method is specified username and password will be prompted for, even if not configured! Hence this needs to be addressed in the solution. I show a couple of workarounds here:-
The sledgehammer approach:
aaa authentication login default none
A more granular approach:
aaa authentication login myvty none
aaa authentication login mycon none
line vty 0 4
login authentication myvty
line con 0
login authentication mycon
One further point to err on the side of caution. Before logging out of the switch do NOT save the config and issue the reload in 5 command. This way if there is an error in your script at least you will be able to get back in if you wait 5 minutes! Of course if all is OK and access is granted simply cancel the reload (reload cancel) and save the config. A useful backdoor when changing access configuration to any device.
N.B.
Once dot1x is globally enabled access ports are NOT entered into dot1x control by default. The default is NO dot1x - this can be seen by executing the 'show dot1x' command. To enable dot1x do so as specified above i.e. dot1x port-control auto. Any attached device will NOT get any access until the radius credentials have been satisfied. Two other dot1x states that can be set are 'force-authorised' and 'force-unauthorised'.
N.B.B
An alternative to
aaa authentication login myvty none
is
aaa authentication login myvty line
the later then requires standard vty password to be set.
i.e.
config-line#password cisco
and
config#enable password cisco
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/sw8021x.html#wp1025133
Following the doc cd the config would be as follows:-
configure terminal
aaa new-model
aaa authentication dot1x default group radius
dot1x system-auth-control
radius-server host 1.2.3.4
radius-server key CISCO
int fa0/8
switchport mode access
dot1x port-control auto
One item of concern here is to not inadvertently lock yourself out of the switch. Once dot1x is enabled this will be used for all interfaces, console and vty, and unless an alternative method is specified username and password will be prompted for, even if not configured! Hence this needs to be addressed in the solution. I show a couple of workarounds here:-
The sledgehammer approach:
aaa authentication login default none
A more granular approach:
aaa authentication login myvty none
aaa authentication login mycon none
line vty 0 4
login authentication myvty
line con 0
login authentication mycon
One further point to err on the side of caution. Before logging out of the switch do NOT save the config and issue the reload in 5 command. This way if there is an error in your script at least you will be able to get back in if you wait 5 minutes! Of course if all is OK and access is granted simply cancel the reload (reload cancel) and save the config. A useful backdoor when changing access configuration to any device.
N.B.
Once dot1x is globally enabled access ports are NOT entered into dot1x control by default. The default is NO dot1x - this can be seen by executing the 'show dot1x' command. To enable dot1x do so as specified above i.e. dot1x port-control auto. Any attached device will NOT get any access until the radius credentials have been satisfied. Two other dot1x states that can be set are 'force-authorised' and 'force-unauthorised'.
N.B.B
An alternative to
aaa authentication login myvty none
is
aaa authentication login myvty line
the later then requires standard vty password to be set.
i.e.
config-line#password cisco
and
config#enable password cisco
Sunday, September 28, 2008
Link Aggregation Control Protocol (LACP) and Priorities
The IEEE standard (802.3ad) for etherchannel, as opposed to Port Aggregation Protocol which is the Cisco proprietary method.
Ports can be configured as active or passive, determining if they will actively negotiate to become an ether channel or simply respond to incoming requests.
Alongside this LACP utilises the concept of system and port priorities. Both system priority and port priorities are configured dynamically by the switch and hence why they may go unnoticed during standard ether channel config.
The LACP system priority and port priorities are 2 byte values and by default are assigned value 32768. The system priority determines which switch makes the decisions on ports that will be bundled into the ether channel. The lowest value determines who is in change and is set in global configuration using
#lacp system-priority 100
The port priority determines the pecking order in terms of which ports are assigned to the etherchannel. LACP supports up to 16 member ports per group but will only allow 8 to be active at once. The ports with the lowest port priority will join the ether channel first (assuming all ports are eligible).
Config-if#lacp port-priority 100
Verification commands include
Show lacp sys-id
Show lacp neighbor
Show lacp internal
Ports can be configured as active or passive, determining if they will actively negotiate to become an ether channel or simply respond to incoming requests.
Alongside this LACP utilises the concept of system and port priorities. Both system priority and port priorities are configured dynamically by the switch and hence why they may go unnoticed during standard ether channel config.
The LACP system priority and port priorities are 2 byte values and by default are assigned value 32768. The system priority determines which switch makes the decisions on ports that will be bundled into the ether channel. The lowest value determines who is in change and is set in global configuration using
#lacp system-priority 100
The port priority determines the pecking order in terms of which ports are assigned to the etherchannel. LACP supports up to 16 member ports per group but will only allow 8 to be active at once. The ports with the lowest port priority will join the ether channel first (assuming all ports are eligible).
Config-if#lacp port-priority 100
Verification commands include
Show lacp sys-id
Show lacp neighbor
Show lacp internal
Saturday, September 27, 2008
Gateway Load Balancing Protocol (GLBP)
GLBP or Gateway Load Balancing Protocol
A cisco proprietary protocol that is another default gateway router redundancy protocol that sits alongside HSRP and VRRP. With the later protocols one router is active within the group. This can reduce the upstream forwarding capabilities. GLBP removes this potential limitation by enabling more than 1 router to be active at the same time.
This extra forwarding capability is achieved by the GLBP protocol responding with multiple MAC addresses when it receives ARP requests. As such the algorithm used to load balance is NOT true ‘load balancing’ in the manner that this word is often used to describe. In reality it will distribute load based on the source of the traffic.
One router in the GLBP group is defined as the AVG (Active Virtual Gateway) and it farms out the virtual mac addresses. Other routers in the group act as AVF (Active Virtual Forwarders) and are each assigned their own vmac. N.B. The AVG is also defined as an AVF member of the group. If a router in the group fails the vmac assigned to the failed router is re-assigned to another member in the group to ensure default gateway availability is maintained. Within a GLBP group there are up to 4 vmacs shared among up to 1024 possible member routers.
Router 2
interface fasthernet 0/0
glbp 1 ip 10.0.0.254
Router 3
interface fasthernet 0/0
glbp 1 ip 10.0.0.254
From R1 and R7 in the example i ping the default gateway address of 10.0.0.254 and then examine the router arp tables:
Router_1#s arp inc 10.0.0.254
Internet 10.0.0.254 2 0007.b400.0101 ARPA FastEthernet0/0
Router_7#s arp inc 10.0.0.254
Internet 10.0.0.254 1 0007.b400.0102 ARPA FastEthernet0/0
As displayed they each have a different mac address for the default gateway. We can examine the GLBP status on router 2 and determine the vmac address of each router
Router_2#s glbp brief
Interface Grp Fwd Pri State Address Active router Standby route
Fa0/0 1 - 100 Active 10.0.0.254 local 10.0.0.3
Fa0/0 1 1 7 Active 0007.b400.0101 local -
Fa0/0 1 2 7 Listen 0007.b400.0102 10.0.0.3 -
It can be seen from the output that R2 owns 0007.b400.0101 and R3 owns 0007.b400.0102. GLBP is working!
GLBP can then be tweeked to optimise the load balancing capabilities. The commands glbp {group} load-balancing [host-dependent round-robin weighted ] can be used.
GLBP weighting can even be used to decide when a router can become eligible to become an AVF within a group.
Here i introduce glbp weighting to R3. With the applied config r3 will be an AVF as long as its weighting remains above the lower threshold of 96.
Router 3
track 10 interface fastehernet 1/0 ip routing
interface fasethernet 1/0
glbp 1 weighting 100 lower 96 upper 99
glbp 1 weighting track 10 decrement 50
When i applied the config upstream interface fa1/0 was fully operational. I then proceeded to take down the interface, and consequently the glbp weight was decremented by 50 and the router was no longer eligible to be an AVF.
This can be seen from the output of the show glbp command on R2:
Router_2#s glbp brief
Interface Grp Fwd Pri State Address Active router Standby route
Fa0/0 1 - 100 Active 10.0.0.254 local 10.0.0.3
Fa0/0 1 1 7 Active 0007.b400.0101 local -
Fa0/0 1 2 7 Active 0007.b400.0102 local -
The active virtual forwarder for both VMACS is now router 2 (10.0.0.2).
Friday, September 26, 2008
Cisco IOS privilege levels
The Cisco IOS supports 16 levels of privilege. By default user exec mode has privilege level 1 and privilege exec has privilege level 15. Upon initial access with a default configuration you are in exec mode with privilege level 1. This allows access to the basic commands show as ‘show ip route’ or ‘show ip interface’.
To access the complete command set users enter privilege exec mode by typing ‘enable’ and by default this moves the user to privilege level 15. As such this represents an ‘all or nothing’ approach to providing access within the IOS.
Within the IOS command set it is possible to configure further privilege levels that furnish access to pre-defined commands only. Thus providing a more graded approach to access.
First to view the default privilege level of commands this can be done by making use of the show parser dump command. For example
R3#show parser dump exec inc show ip interface brief
1 show ip interface brief
R3#show parser dump exec inc debug ip packet detail
15 debug ip packet detail
15 no debug ip packet detail
15 undebug ip packet detail
In the above show ip interface brief can be seen as available at privilege level 1, whereas debug ip packet detail is available at privilege level 15.
As an example I make the debug ip packet detail command available at level 7. There are 2 steps involved: create the enable password for level 7 and then redefine the privilege level of the required command.
R3(config)#enable password level 7 RICH
R3(config)#privilege exec level 7 debug ip packet detail
R3(config)#privilege exec level 7 undebug ip packet detail
I then validate my solution….
R3>show privilege
Current privilege level is 1
Indicates current privilege level as 1
R3>debug ip packet detail
^
% Invalid input detected at '^' marker.
Indicates command is not available at privilege level 1
R3>enable 7
Password:
R3#debug ip packet detail
IP packet debugging is on (detailed)
I log into privilege level 7 and I am now able to execute said command!
It is possible to assign users to specific privilege levels by default at login time. This can be achieved in either at the user level (see below)
R3(config)#username rich privilege 7 password rich
R3(config)#line vty 0 4
R3(config-line)#privilege level 7
On the cisco doc cd the info is available under IOS Security Guide Configuration
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfpass.html
To access the complete command set users enter privilege exec mode by typing ‘enable’ and by default this moves the user to privilege level 15. As such this represents an ‘all or nothing’ approach to providing access within the IOS.
Within the IOS command set it is possible to configure further privilege levels that furnish access to pre-defined commands only. Thus providing a more graded approach to access.
First to view the default privilege level of commands this can be done by making use of the show parser dump command. For example
R3#show parser dump exec inc show ip interface brief
1 show ip interface brief
R3#show parser dump exec inc debug ip packet detail
15 debug ip packet detail
15 no debug ip packet detail
15 undebug ip packet detail
In the above show ip interface brief can be seen as available at privilege level 1, whereas debug ip packet detail is available at privilege level 15.
As an example I make the debug ip packet detail command available at level 7. There are 2 steps involved: create the enable password for level 7 and then redefine the privilege level of the required command.
R3(config)#enable password level 7 RICH
R3(config)#privilege exec level 7 debug ip packet detail
R3(config)#privilege exec level 7 undebug ip packet detail
I then validate my solution….
R3>show privilege
Current privilege level is 1
Indicates current privilege level as 1
R3>debug ip packet detail
^
% Invalid input detected at '^' marker.
Indicates command is not available at privilege level 1
R3>enable 7
Password:
R3#debug ip packet detail
IP packet debugging is on (detailed)
I log into privilege level 7 and I am now able to execute said command!
It is possible to assign users to specific privilege levels by default at login time. This can be achieved in either at the user level (see below)
R3(config)#username rich privilege 7 password rich
R3(config)#line vty 0 4
R3(config-line)#privilege level 7
On the cisco doc cd the info is available under IOS Security Guide Configuration
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfpass.html
Thursday, September 25, 2008
OSPF routing part II - discard routes
The default behaviour for OSPF (in releases 12.1(6) and higher) when creating a summary route with the 'area x range' command is to auto-generate the summary pointing to the null interface. Cisco calls these discard routes as they prevent routing loops when summarization occurs i.e. if a packet is received for the summary route without a more granular present it will be discarded.
This default behavior can be turned off with the use of the 'no discard-route' at the ospf config router prompt.
config-router#no discard-route internal
config-router#no discard-route external
This default behavior can be turned off with the use of the 'no discard-route' at the ospf config router prompt.
config-router#no discard-route internal
config-router#no discard-route external
OSPF routing part I - RFC1583 vs RFC2328
When i first came across the router ospf command 'no compatible rfc1583' and read the cisco command reference description i was left feeling rather puzzled. I have pasted the Cisco documentation in the command reference section below.
The usage guidelines states
Because of the introduction of RFC 2328, OSPF Version 2, the method used to calculate summary route costs has changed. Use the no compatible rfc1583 command to enable the calculation method used per RFC 2328.
IMO this description, especially in the midst of a CCIE lab, would not be that helpfull in terms of understanding how and when to use this command. It doesn't really give enough context, unless you reference the RFC documentation which of course will not be available to you in the lab. Hence i have written the following to further expand on the use of this command in the OSPF routing protocol.
In the first implementation of OSPF (RFC1583) the summary route would assume the cost of the granular route with the lowest cost. This was and still is the default behaviour on Cisco routers.
When OSPF RFC 2328 came along this was changed so that the summary route assumes the cost of the granular route with the highest cost.
To enable the behaviour of RFC 2328 execute 'no compatible rfc1583' at the config router prompt. It is necessary to enable this command on all routers in the OSPF domain. If not the summary route from ABRs usind RFC 1583 will be chosen in preference, since the cost they are advertising will be lower.
The usage guidelines states
Because of the introduction of RFC 2328, OSPF Version 2, the method used to calculate summary route costs has changed. Use the no compatible rfc1583 command to enable the calculation method used per RFC 2328.
IMO this description, especially in the midst of a CCIE lab, would not be that helpfull in terms of understanding how and when to use this command. It doesn't really give enough context, unless you reference the RFC documentation which of course will not be available to you in the lab. Hence i have written the following to further expand on the use of this command in the OSPF routing protocol.
In the first implementation of OSPF (RFC1583) the summary route would assume the cost of the granular route with the lowest cost. This was and still is the default behaviour on Cisco routers.
When OSPF RFC 2328 came along this was changed so that the summary route assumes the cost of the granular route with the highest cost.
To enable the behaviour of RFC 2328 execute 'no compatible rfc1583' at the config router prompt. It is necessary to enable this command on all routers in the OSPF domain. If not the summary route from ABRs usind RFC 1583 will be chosen in preference, since the cost they are advertising will be lower.
One further point is how this command will slightly modify OSPFs behaviour. OSPF will re-advertise the summary whenever the cost of the summary changes. When using the default RFC 1583 behaviour this will be when the granular route with the lowest metric is changed or lost, wherease when RFC 2328 is used, this will be done dependant on the granular route with the highest cost.
Subscribe to:
Posts (Atom)
