Wednesday, December 31, 2008

NAT Load Balancing


As an added feature of NAT it can be used to load balance a ‘serverfarm’. The router performing the natting can round robin connection requests to the real servers.

A virtual server address is required. The natting router takes tcp requests received on this address, and the specified ports, and passes them on in a rotary fashion to the servers.

This can be achieved with the following configuration on R2…..


interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat outside
!
interface FastEthernet1/0
ip address 11.0.0.2 255.255.255.0
ip nat inside

ip nat pool REALS 11.0.0.3 11.0.0.4 prefix-length 24 type rotary
ip nat inside destination list VIPACCESS pool REALS
!
ip access-list extended VIPACCESS
permit tcp any host 11.0.0.254 eq telnet
Now when telnetting to 11.0.0.254 from R1, R2 redirects the request to one of the 3 real server addresses
Router_1#telnet 11.0.0.254Trying 11.0.0.254 ... Open
Router_4>
On R2 i examine the nat translation table
Router_2#s ip nat trans
Pro Inside global Inside local Outside local Outside globaltcp 11.0.0.254:23 11.0.0.4:23 10.0.0.1:16630 10.0.0.1:16630

!

Monday, December 29, 2008

Multicast Gotchas





I have listed a few gotchas that i have come across when configuring IP multicast.....

Multicast on a hub-and-spoke frame-relay network.

A multipoint interface won't, by default, send multicast received from one spoke out to another spoke. This doesn't apply to a 'hub-and-spoke' where the hub is using separate physical or virtual interfaces, just multipoint interfaces. For sparse traffic this can be fixed by applying 'ip pim nbma-mode' to the multipoint interface. For dense traffic, you can use a PIM-enabled tunnel between the spokes to fix this. To use the tunnel an mroute pointing to the tunnel is required, to ensure the RPF check does not fail.

Consider the above topology where R1, R2 and R3 are all enabled with ip pim dense-mode on the serial interfaces. R1 has joined multicast group 226.1.1.1. R2 is able to successfully ping this address but from R3 this fails.

To circumvent this problem the following tunnel configuration can be applied...

R1
interface Tunnel1
ip address 148.1.1.1 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.3.3

ip mroute 0.0.0.0 0.0.0.0 Tunnel1

R3
interface Tunnel1
ip address 148.1.1.2 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.1.1



RPF Checks


If multicast traffic is required to take a path which unicast wouldn't, then the recieving router will likely drop the traffic because it fails the RPF check. This is typically fixed by applying an mroute.

Using Auto-RP in Sparse Mode
It was my misconception until recently that Auto RP operates in sparse-dense mode only. In fact in can operate in sparse mode as long as routers are configured with ip pim autorp listener command.

Sunday, December 28, 2008

IPV6 6to4 tunnels




A IPV6 tunnelling method that can be used in a one to many environment (as opposed to point to point tunnelling). To configure it all that's required is
1) a tunnel interface given a special IPV6 address with an embedded IPV4 interface address.
2002:{first 2 octects ipv4 address}:{second 2 octects of ipv4 address}:...
2) an ipv6 static route '2002::/16 tu0'

The CISCO IOS works its magic to nail up connectivity to the other tunnel end points.

interface Tunnel0
no ip address
no ip redirects
ipv6 address 2002:101:101:134::1/64
tunnel source Loopback0
tunnel mode ipv6ip 6to4

interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
ipv6 route 2002::/16 Tunnel0

interface Loopback1
no ip address
ipv6 address 2002:1::1/64


All thats required to connect IPV6 address spaces over the tunnel is to implement IPV6 routing over the tunnel

e.g.

R1
ipv6 route 2002:3::/64 2002:303:303:134::3

Router_1#PING 2002:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/97/152 ms
Router_1#

Friday, December 26, 2008

Regular Expression Special Characters

As a reminder to my self, the regular expression special characters.

Character Meaning
^ Start of string
$ End of string
[] Range of characters
- Used to specify range ( i.e. [0-9] )
( ) Logical grouping
. Any single character
* Zero or more instances
+ One or more instance
? Zero or one instance
_ start or end of string, or space

Examples (ive only scratched the surface here!)

Example 1
Only allow routes originated by as 54
ip as-path access-list 1 permit _54$
ip as-path access-list 1 deny .*

Example 2
Only allow routes from as 54 and directly connected peer AS,s
ip as-path access-list 1 permit ^54_([0-9]+)?$
ip as-path access-list deny .*

Example 3
To match on any route that has transitioned through as 54.  i.e. one that originated in, passed through, or advertised by use

ip as-path access-list 1 permit _54_

In fact the _ (underscore) character permits a space, command, start of string, end of string or a bracket symbol.




A great way to test regular expression is via the command
show ip bgp regexp {expression}
N.B. to enable a ? to be entered in a command line precede with ctrl-V.



Wednesday, December 24, 2008

Mark and Police



In this post i bring together a number of QOS features to implement an end to end QOS marking and policing scenario.

On R2 i mark all traffic destined to UDP port 3333 with an IP precednce of 3. On R3 i ensure all traffic with an IP precednce of 3 utilises no more than 100,000 bps of the bandwidth between R3 and R4.

In order to test this scenario i make use of the IP SLA feature. R1 generates the traffic to the loopback 0 on R4 with a UDP dest port of 3333. On R4 i configure an IP SLA responder to ensure these packets are answered.

Here is the config i used....

R1
ip sla monitor 1
type udpEcho dest-ipaddr 99.99.99.99 dest-port 3333
request-data-size 1500
timeout 2000
frequency 15
ip sla monitor schedule 1 life forever start-time now



R2

access-list 100 permit udp any any eq 3333

class-map match-all SLA
match access-group 100

policy-map MARK
class SLA
set precedence 3

interface FastEthernet1/0
service-policy output MARK



R3
access-list rate-limit 1 mask 08

interface FastEthernet1/0
rate-limit output access-group rate-limit 1 100000 18750 37500 conform-action transmit exceed-action drop


R4
ip sla monitor responder type udpEcho ipaddress 99.99.99.99 port 3333


For verification i used the following commands on each of the routers

R1
s ip sla monitor stat
Round trip time (RTT) Index 1
Latest RTT: 160 ms
Latest operation start time: *06:04:24.763 UTC Thu Dec 25 2008
Latest operation return code: OK
Number of successes: 152
Number of failures: 24
Operation time to live: Forever

R2
s policy-map int fa1/0
FastEthernet1/0

Service-policy output: MARK

Class-map: SLA (match-all)
296 packets, 233248 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group 100
QoS Set
precedence 3
Packets marked 296

Class-map: class-default (match-any)
451 packets, 38519 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any


R3
#s int fa1/0 rate-limit
FastEthernet1/0
Output
matches: access-group rate-limit 1
params: 96000 bps, 18750 limit, 37500 extended limit
conformed 100 packets, 78800 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 7788ms ago, current burst: 14 bytes
last cleared 00:12:48 ago, conformed 0 bps, exceeded 0 bps

R4
show ip sla monitor responder
IP SLA Monitor Responder is: Enabled
Number of control message received: 4 Number of errors: 0
Recent sources:
10.0.0.1 [06:10:24.379 UTC Thu Dec 25 2008]
10.0.0.1 [06:10:09.391 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:54.395 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:39.371 UTC Thu Dec 25 2008]
Recent error sources:

udpEcho Responder:
IP Address Port
99.99.99.99 3333


It works! :-)

Tuesday, December 23, 2008

Policing: MQC vs Rate Limiting

Suppose the lab requirement is to restrict traffic with IP precedence 3,4 and 5 to a max throughput of 500,000 mps. As ever with the CCIE there is more than one method to crack this nut. I guess it depends on your preferred method versus what the actual requirements and restrictions of the task are.

My personal preference would be to use MQC. The above requirement could be achieved as follows.....


ip access-list extended 101
permit ip any any prec 3
permit ip any any prec 4
permit ip any any prec 5

class-map PREC345
match access-group 101

policy-map POLICE
class PREC345
police 500000 93750 187500 conform-action transmit exceed-action drop

int fa0/0
service-policy output POLICE

For verification use the 'show policy-map int fa0/0' command.


Another method of achieving the same result is to use the older rate-limit command.....

rate-limit output access-group 101 496000 93750 187500 conform-action transmit exceed- action drop

There is a 3rd method of achieving the above. This is another variation on the rate-limit command. If the lab requirement specified the solution must be achieved using an ACL with only 1 line this may be one scenario where such a solution would come to the rescue.

There is a special access-list type named 'rate-limit'. This allows traffic to be selected based on MAC address, precedence or MPLS markings.

Router_2(config)#access-list rate-limit ?
<0-99> Precedence ACL index
<100-199> MAC address ACL index
<200-299> mpls exp ACL index

The requirement here is to use IP precedence 3,4 and 5.

access-list rate-limit 0 ?
Router_2(config)#access-list rate-limit 0 ?
<0-7> Precedence
mask Use precedence bitmask

As with an ACL only 1 precedence value can be configured per line. To allow multiple precedence values to be configured with one 'hit' requires the use of the mask option.

To make use of this the coding of the precedence values needs to first be recalled...

IP Precedence 0 = 00000001
IP Precedence 1 = 00000010
IP Precedence 2 = 00000100
IP Precedence 3 = 00001000
IP Precedence 4 = 00010000
IP Precedence 5 = 00100000
IP Precedence 6 = 01000000
IP Precedence 7 = 10000000


A packet with ip precedence of either 3,4 or 5 can be matched with bit pattern 00111000. The mask parameter expects this bit pattern in 2 HEX digits, so this has the equivalent value 38. (Note.. this is the 2 byte HEX equivalent and not the HEX value of the full byte which would be 56!!).

So bringing this all together the 1 line solution to the question would be

rate-limit output access-group rate-limit 0 1000000 93750 187500 conform-action
transmit exceed-action drop


Verification with rate-limiting can be done with 'show int fa0/0 rate-limit'

vlan filter






Consider the following scenario where routers 1,2 and 3 are connected on a common LAN segment. All routers are in a common RIP domain.

The requirement is for Routers 2 and 3 to not accept ANY routes from R1 WITHOUT changing the config on R2 and R3!

A solution here is to use a vlan filter on the intermediate switch.
My first attempt was to apply the following (incorrect) configuration.

access-list 1 permit 224.0.0.9

vlan access-map DROP_RIP permit 10
match ip address 1
action drop
vlan access-map DROP_RIP permit 20

vlan filter DROP_RIP vlan 232

With the above config ALL RIP neighbor adjacencies were lost!!! The problem was the access list i had used. A more targetted ACL is required to only drop RIP traffic from Router 1.

The following ACL achieves the requirement.

access-list 100 permit udp host 192.10.1.254 any eq rip

This question also got me thinking on how it would be possible to block other routing protocols of the switch.

The equivalent access list entries for EIGRP, OSPF and BGP are as follows......

Extended IP access list 100
20 permit eigrp host 50.0.0.254 any
30 permit ospf host 50.0.0.254 any
40 permit tcp host 50.0.0.254 any eq bgp
50 permit tcp host 50.0.0.254 eq bgp any

Monday, December 22, 2008

RIP - Versions 1 and 2

Most RIP scenarios these days are based on version 2. That is RIP updates are multicast to ip address 224.0.0.9. In RIP version 1 updates are broadcast to 255.255.255.255.

By default RIP sends updates in version 1 but is capable of receiving up dates in version 1 and 2.

When the 'version 2' command is entered at the router config prompt RIP only then sends and receives in version 2.

If a requirement arises where another router requires version 1 updates, whilst not changing the version 2 operation of the router, this poses a problem. This can be overcome by manipulating the sent and received RIP version on an interface level. This overrides the config router commands.

Here i enable the router to send rip version 1 and 2 updates out of interface fa1/0.

int fa1/0
ip rip send version 1 2


Use the show ip protocol command for verification.

Thursday, December 18, 2008

FRTS versus MQC FRTS - Part II

Following on from part I i know introduce a further requirement to set the frame-relay discard eligibility bit on all non critical frames (non DSCP 5).

For consistency i apply this on R4 using traditional FRTS on R4 and then using MQC FRTS on R5.

R4

1) i create a new class DSCP5 matching the critical traffic
2) I create a policy-map FR_405 that only sets the de bit for the non-critical frames
3) Finally within the pre-existing frame-relay map-class RICH i reference the new policy-map.

class-map match-all DSCP5
match dscp cs5

policy-map FR_405
class DSCP5
class class-default
set fr-de

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
service-policy output FR_405
frame-relay fragment 960


For verification is use the 'show frame-relay pvc 405' command

R4#s frame-relay pvc 405

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 169 output pkts 175 in bytes 21260
out bytes 18308 dropped pkts 6 in pkts dropped 6
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 30
out bcast pkts 112 out bcast bytes 13140
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:17:45, last time pvc status changed 00:16:05
service policy FR_405
Serial2/0: DLCI 405 -

Service-policy output: FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group 100
0 packets, 0 bytes
5 minute rate 0 bps
Match: dscp cs5 (40)
0 packets, 0 bytes
5 minute rate 0 bps

Class-map: class-default (match-any)
30 packets, 3169 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 30
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 960
cir 768000 bc 7680 be 0 limit 960 interval 10
mincir 384000 byte increment 960 BECN response no IF_CONG no
frags 175 bytes 18308 frags delayed 0 bytes delayed 0

shaping inactive
traffic shaping drops 0



On R5

As on R4 the first 2 steps are identical: i create a new class and policy map. I then reference the new policy map from within the pre-existing service-policy RICH. Nested service policies!!!:-)

class-map match-all DSCP5
match dscp cs5


policy-map FR_405
class DSCP5
class class-default
set fr-de

policy-map RICH
class class-default
shape average 768000 7680
service-policy FR_405



For verification i use the 'show policy-map int s2/0.54' command.

R5#s policy-map int s2/0.54

Serial2/0.54

Service-policy output: RICH

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 1920 7680 7680 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1 84 0 0 no

Service-policy : FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: dscp cs5 (40)

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 3



Both methods achieve the same result!

FRTS versus MQC FRTS - Part I


MQC FRTS (Modular Quallity Of Service Command Line Interface Frame Relay Traffic Shaping!) has become mainstream in IOS 12.4. This enables FRTS to conform to the same MQC standard method of configuration.

In the following example i use FRTS on the spoke routers with the equivalent MQC FRTS configuration on the hub router.

Spoke Router Config

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
frame-relay fair-queue
frame-relay fragment 960

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 405
class RICH



Hub Router Config

policy-map SHAPE
class class-default
shape average 768000 7680 0

interface Serial2/0.35 multipoint
service-policy output SHAPE
interface Serial2/0.54 multipoint
service-policy output SHAPE


Points of note
1) For the shaping within MQC this requires the configuration to be done under the class class-default.
2) If required the class-default can reference another policy map, via the service-policy command. In this way CBWFQ or LLQ can also be introduced.
3) the 'shape average 768000 7680' command equates to the 'frame-relay cir 768000' plus the 'frame-relay bc 7680' command.

For verification use 'show traffic-shape' for FRTS and 'show policy-map' for MQC FRTS

e.g.

s traffic-shape

Interface Se2/0.35
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
503 768000 6048 768000 0 63 6048 -



s policy-map int s2/0.54

Serial2/0.54

Service-policy output: SHAPE

Class-map: class-default (match-any)
22 packets, 242 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 960 7680 0 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 22 242 0 0 no

Friday, December 12, 2008

rip - neighbor filtering options


In the above topology i want R6 to only allow routes from R2. Similarly i want R2 to only allow routes from R6.

To meet this requirement i use different methods on each router to achieve the same net result. Both methods require use of the distribute-list command.

On R6 i use and extended acl to first deny the RIP neighbors i do not require and allow the rest. On R2 i make use of the distribute-list gateway command in conjunction with a prefix-list to only allow the neighbors i require.

R6

router rip
version 2
network 54.0.0.0
network 150.1.0.0
network 204.12.1.0
distribute-list 100 in
no auto-summary
!

access-list 100 deny ip host 54.1.7.254 any
access-list 100 deny ip host 204.12.1.254 any
access-list 100 permit ip any any


R2

router rip
version 2
network 204.12.1.0
distribute-list gateway RICH in
no auto-summary
!
ip prefix-list RICH seq 5 permit 204.12.1.6/32


The IP prefix-list in the distribute-list gateway statement allows prefixes to be filtered as they are received based on the source of the update. This allows updates learned from BB3 to be denied, but still allows updates to be received from R6.

Thursday, December 11, 2008

Frame Relay - End to End Keepalives


Frame Relay keepalives allow end to end monitoring of a frame-relay circuit. This enables the local DLCI status to represent the status of the end to end ciruit.

To enable it has to be configured within a frame relay map-class - so its no good looking under the frame-relay sub interface!!

map-class frame-relay DLCI504
frame-relay end-to-end keepalive request

interface s2/0.54
frame-relay class DLCI504


To verify use the command 'show frame-relay end-to-end keepalive'

End-to-end Keepalive Statistics for Interface Serial2/0 (Frame Relay DTE)

DLCI = 504, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 91, Receive Sequence Number: 255
Configured Event Window: 3, Configured Error Threshold: 2
Total Observed Events: 111, Total Observed Errors: 38
Monitored Events: 0, Monitored Errors: 0
Successive Successes: 0, End-to-end VC Status: UP

Wednesday, December 10, 2008

IP Telephony

In this post an ip phone is attached to fa0/5 on a switch. The requirement is for the switch to mark the voice vlan as 10 and data as 100. The COS value from the phone should be trusted and the switch needs to instruct the phone to assign cos value of 1 to data.

mls qos
vlan 10

int fa0/5
switchport voice vlan 10
switchport access vlan 100
mls qos trust cos
switchport priority extend cos 1
N.B. unlike data, when a voice vlan is assigned on an interface the vlan is NOT automatically created on the switch.
N.B.B without any instruction, the cisco phone will mark all data packets with a COS value of 0.

The necessary config for voice on a 3560 can be cribbed from the 'VOICE Vlan' section under the 3560 configuration guide.

Sunday, December 7, 2008

Traffic Filtering - Without an ACL

There is a requirement for R2 to filter traffic to and from neighboring routers R1 and R3. The catch however is that an ACL cannot be used. An unlikely scenario in the real world, but there again something that may be thrown up in a CCIE lab.


R1 ---------------(fa1/0) R2 (fa1/1)--------------- R3


To acheive this a service-policy can be used.


class FROM_R1
match input-interface fa1/0

class FROM_R3
match input-interface fa1/1

policy-map TO_R1
class FROM_R3
drop

policy-map TO_R3
class FROM_R1
drop

int fa1/0
service-policy output TO_R1

int fa1/1
service-policy output TO_R3



Another scenario that might lead to use of a service policy to filter traffic is when an acl cannot be used in isolation to achieve the required filtering results.
For example the requirement may be drop icmp echo and echo replies with a packet length between 300 and 350.

This functionality cannot be achieved using an ACL alone: there is no way of matching on packet length in an acl.
However packet length can be matched in a class map.

Hence

ip access-list ext 101
permit icmp any any echo
permit icmp any any echo-reply

class-map match-all ICMP
match access-group 101
match packet length min 300 max 250

policy-map ICMP
class ICMP
drop

int fa0/0
service-policy input ICMP
service-policy output ICMP

Frame Relay Traffic Shaping - Part II

In this post i look at applying WRED within the frame-relay traffic shaping construct.

Assume interface s2/0 already has frame-relay traffic shaping enabled.

interface Serial2/0
bandwidth 1544
ip address 174.1.145.4 255.255.255.0
ip pim sparse-dense-mode
encapsulation frame-relay
delay 2
serial restart-delay 0
no fair-queue
frame-relay class FR
frame-relay traffic-shaping
frame-relay map ip 174.1.145.1 401 broadcast
frame-relay map ip 174.1.145.4 401
frame-relay map ip 174.1.145.5 401 broadcast
end

The frame-relay map class FR is already applied

map-class frame-relay FR
frame-relay cir 128000
frame-relay bc 16000
frame-relay adaptive-shaping becn
frame-relay fecn-adapt

At this point there is a requirement to apply WRED to IP packets with 'critical' ip precedence. As denoted in an earlier post of mine this can be achieved within MQC via application to a service policy that either has 'bandwidth' applied or must be done in the 'class default' with fair-queue applied. As there are no bandwidth requirements here i use the 'class default' option.


policy-map WRED
class class-default
fair-queue
random-detect
random-detect precedence 5 60 90 5


With the above parameters ip packets with a priority of 5 will start to be dropped once the queue size reaches 60. Once the queue size reaches 90, 1 in 5 packets will be dropped.

To apply a policy to a frame-relay map the same method is used as applying to an interface.

Thus

map-class frame-relay FR
service-policy output WRED


Once applied use the 'show frame-relay pvc' command to examine the settings.

Rack1R4#s frame-relay pvc 401

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 329 output pkts 294 in bytes 26959
out bytes 18027 dropped pkts 16 in pkts dropped 16
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 198 out bcast bytes 11496
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
Shaping adapts to BECN
pvc create time 00:26:31, last time pvc status changed 00:24:52
cir 128000 bc 16000 be 0 byte limit 2000 interval 125
mincir 64000 byte increment 2000 Adaptive Shaping BECN
pkts 212 bytes 12481 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
service policy WRED
Serial2/0: DLCI 401 -
Service-policy output: WRED

Class-map: class-default (match-any)
187 packets, 11007 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 16
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9

class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 60 90 1/5
6 72/4237 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10


Output queue size 0/max total 600/drops 0

Wednesday, December 3, 2008

BGP Next Hop


With iBGP the next hop for the advertised route is changed to match the address of the advertising router.

With eBGP the next hop is unchanged based on the assumption that the receiving router must have reachability to the eBGP peer address. If this assumption is incorrect there are a number of commands that can be used to manipulate the next hop address associated with the route.

The simplest of these is
neighbor a.b.c.d next-hop-self

This will change the next hop for all advertised routes to the local router address.

If more garnularity is required or you are prohibited from using 'next-hop-self' then route maps can be used to influence the next hop of advertised routes.


route-map TO_R4
set ip next-hop peer-address

Saturday, November 29, 2008

MLPoFR

MLPoFR (Multilink PPP over Frame Relay)

Frame Relay does not natively support features such as authentication,
link quality monitoring, and reliable transmission. By using PPP over Frame Relay these these features can be enabled. A useful feature of PPP that can be used over Frame Relay as well is PPP multilink: Multilink PPP over Frame Relay (MLPoFR).




Example Config.

Router 2
username R3 password 0 CISCO

interface Multilink1
ip address 174.1.23.2 255.255.255.0
ppp multilink
ppp multilink group 1

interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial2/0.203 multipoint
frame-relay interface-dlci 203 ppp Virtual-Template1
!
interface Serial2/0.213 multipoint
frame-relay interface-dlci 213 ppp Virtual-Template1

interface Virtual-Template1
no ip address
ppp authentication chap
ppp chap hostname Rack1R2
ppp multilink
ppp multilink group 1


Router 3
username R2 password 0 CISCO

interface Multilink1
ip address 174.1.23.3 255.255.255.0
ppp multilink
ppp multilink group 1

interface Serial2/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 302 ppp Virtual-Template1
no frame-relay inverse-arp
!
interface Serial2/1
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 312 ppp Virtual-Template1
no frame-relay inverse-arp

interface Virtual-Template1
no ip address
ppp authentication chap
ppp multilink
ppp multilink group 1

Monday, November 24, 2008

Lock and Key ACL


A Lock and Key ACL is also known as a dynamic ACL. This feature effectively allows a router to control downstream access to other devices.

Once the user has authenticated to the router access is opened up according to the configured dynamic acl.

R3 ------ R2 ------R7

In this scenario telent access to R7 is prohibited by R2 until the user has authenticated to R2.

ip access-list extended RICH
dynamic TEST permit tcp any host 150.1.7.7 eq telnet
deny tcp any host 150.1.7.7 eq telnet
permit ip any any

lint vty 0 4
login local

username RICH pasword RICH
username RICH autocommand access-enable timeout 5


From R3 i try and telnet to R7.

R3#telnet 150.1.7.7
Trying 150.1.7.7 ...
% Destination unreachable; gateway or host down


I then telent to R2 first...
R3#telnet 150.1.2.2
Trying 150.1.2.2 ... Open


User Access Verification

Username: RICH
Password:
[Connection to 150.1.2.2 closed by foreign host]

Once authenticated to R2 controll is returned to R3 from where i can now telnet to R7.
R3#telnet 150.1.7.7
Trying 150.1.7.7 ... Open

Router_7>

On R2 i examine the access-list and can see the dynamic acl has been activated.

Extended IP access list RICH
10 Dynamic DYNAMIC permit tcp any any eq telnet
permit tcp any any eq telnet (6 matches) (time left 281)
20 deny tcp any host 150.1.7.7 eq telnet (45 matches)
30 permit ip any any (1005 matches)


N.B.
In a later lock and key scenario i encountered the extra requirement - Once authenticated the user alone should be the only one able to access the host via telnet. This was initially food for thought as with the configuration above access is opened up from 'any' source.

In fact to tie a dynamic access list down to the user in question the aoutocommand must include the 'host' keyword. i.e.

username RICH autocommand access-enable host timeout 1

N.B.B One further note the autocommand can be applied directly under the vty interface and thus applied to all vty logins.

live vty 0 4
autocommand access-enable host timeout 1


N.B.B.B!!! Whilst researching this i realised that the autocommand feature can be used to execute any command upon user login. For example

username RICH autocommand show ip interface brief

This works! Once the user has logged in, the interface status is displayed and then the user is logged out.

Filtering L2 Traffic

Mac access-lists can be used to match traffic by L2 characteristics. In turn this traffic can be forwarded or filtered using Vlan ACLs or VACLs.

For example key words available on a mac acl include the following

aarp EtherType: AppleTalk ARP
amber EtherType: DEC-Amber
appletalk EtherType: AppleTalk/EtherTalk
cos CoS value
dec-spanning EtherType: DEC-Spanning-Tree
decnet-iv EtherType: DECnet Phase IV
diagnostic EtherType: DEC-Diagnostic
dsm EtherType: DEC-DSM
etype-6000 EtherType: 0x6000
etype-8042 EtherType: 0x8042
lat EtherType: DEC-LAT
lavc-sca EtherType: DEC-LAVC-SCA
lsap LSAP value
mop-console EtherType: DEC-MOP Remote Console
mop-dump EtherType: DEC-MOP Dump
msdos EtherType: DEC-MSDOS
mumps EtherType: DEC-MUMPS
netbios EtherType: DEC-NETBIOS
vines-echo EtherType: VINES Echo
vines-ip EtherType: VINES IP
xns-idp EtherType: XNS IDP

By way of an example i will filter all DEC diagnostic traffic from VLAN 10...

mac access-list extended RICH
permit any any DEC-Diagnostic

vlan access-map TEST
match mac address RICH
action drop
vlan access-map TEST
action forward

vlan filter TEST vlan-list 10

MQC and Random Detect

To configure WRED in the MQC, one of two conditions must be met. There must either be a bandwidth reservation made within a class, or the default-class must be running weighted fair queuing.

Friday, November 21, 2008

Redistribution Gotcha


In the above scenario the loopback interface address is introduced into OSPF via the 'redistribute connected' command on router 3. Following this OSPF is redistributed into the RIP domain on router 3 using 'redistributed ospf 1 subnets metric 5'.


Upon examining the routing table on router 4 i was surprised to find no route for 150.1.3.3 present! This is to do with an anomoly with redistribution on the device performing the redistribution itself. When OSPF is redistributed into RIP it will carry all OSPF routes EXCEPT locally redistributed ones. In this instance RIP must pull such routes in explicitly using the 'redistribute connected' command itself.


Notes....
1)When redistributing in IPV6 it is also necessary to incorporate the 'redistribute connected' . Without this local interfaces are not redsitributed by default.

2) When redistributing rip into OSPF any route for directly connected interfaces ARE taken across by default. :-)!
3) With OSPF and EIGRP mutual redistribution connected routes are taken across by default.

Final note to self!!! With redistribution watch out for connected routes! particularly with RIP and IPV6.

Thursday, November 20, 2008

OSPF routing part VIII - Conditional default route


In the above scenario R3 must only advertise a default route to F4 if its connection to BB2 is up.


This can be achieved by making use of conditional default route advertisement feature. This requires use of a route-map to indicate those routes that must be available in the routing table before the default route will be advertised.


In his example


Rack1R3#show ip route inc 204.12C 204.12.1.0/24 is directly connected, FastEthernet1/0


ip prefix-list BB2 permit 204.12.1.0/24

route-map CONNECTED permit 10

match ip address prefix-list BB2


router ospf 1

default-information originate route-map CONNECTED



Once the config is applied on R3 the default route pops up on R4.

Rack1R4#sir inc 0.0.0

Gateway of last resort is 191.1.34.3 to network 0.0.0.0O*E2 0.0.0.0/0 [110/1] via 191.1.34.3, 00:16:22, Serial2/0


If i shut down the fa1/0 interface on R3 the default route 204.12.1.0/24 dissapears from the routing table on R3 and subsequently the default route dissappears from R4 routing table as well.

Wednesday, November 19, 2008

OSPF routing part VII - NSSA special case


Consider the following scenario whereby an NSSA area exists between router 2 and 7. As expected type 7 LSAs are allowed to flow from router 7 to router 2, into area 0. An additional requirement was imposed that router 7 must ONLY see a default route from router 2. This can be achieved by specifying a 'not so stubby totally stubby area'!

The issue with acheiving the lab requirements is that by default type 7 LSAs are allowed to flow in BOTH directions: i.e. router 2 <->router 7. To prevent the flow of type 7 LSAs from Router 2 the 'no-redistribution' option can be used

router 2
router ospf 1
area 27 nssa no-summary no-redistribution

Tuesday, November 18, 2008

Switchport port security

In this post i denote the config required to restrict access to port fa0/09 to 3 mac addresses only. In the event that further hosts try to connect a syslog message is generated.


interface FastEthernet0/09
switchport mode access
switchport port-security
switchport port-security maximum 4
switchport port-security violation restrict
switchport port-security mac-address 0040.7014.8ef0
switchport port-security mac-address 00d0.144e.07bf
switchport port-security mac-address 00e0.341c.7871
!
logging 134.1.8.100


To verify configuration use the 'show port-security' commands.

SW3#show port-security int fa0/09 address
Secure Mac Address Table
------------------------------------------------------------------------
Vlan Mac Address Type Ports Remaining Age
(mins)
---- ----------- ---- ----- -------------
1 0040.7014.bef0 SecureConfigured Fa0/10 -
1 00d0.144e.07bf SecureConfigured Fa0/10 -
1 00e0.341c.7871 SecureConfigured Fa0/10 -
------------------------------------------------------------------------
Total Addresses: 3



SW3#show port-security int fa0/09
Port Security : Enabled
Port Status : Secure-down
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 3
Total MAC Addresses : 3
Configured MAC Addresses : 3
Sticky MAC Addresses : 0
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0

Monday, November 17, 2008

DOT1Q Tunnelling


This feature allows a user trunk to be encapsulated in a tagged vlan across a service provider cloud. The switchport configuration is fairly straightforward.

1) Select a vlan that will be used to encapsulated and trunk the user traffic
2) Set up the service provider edge switch ports as dot1q tunnel ports



R4 --------- SW3 ----------------- SW4 ---------- R5


SW3
vlan 500

interface fastethernet 0/23
switchport access vlan 500
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable


SW4
vlan 500

interface fastethernet 0/23
switchport access vlan 500
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable


The user router ports are set as trunk ports e.g.

R4#s run begin interface Fast
interface FastEthernet0/0
no ip address
duplex full
!
interface FastEthernet0/0.4
encapsulation dot1Q 4
ip address 191.1.4.4 255.255.255.0
!
interface FastEthernet0/0.40
encapsulation dot1Q 40
ip address 191.1.40.4 255.255.255.0
!
interface FastEthernet0/0.45
encapsulation dot1Q 45
ip address 191.1.45.4 255.255.255.0
!
interface FastEthernet0/0.49
encapsulation dot1Q 49
ip address 191.1.49.4 255.255.255.0



R5#s run beg interface Fas
interface FastEthernet0/0
duplex full
!
interface FastEthernet0/0.45
encapsulation dot1Q 45
ip address 191.1.45.5 255.255.255.0
!
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 191.1.50.5 255.255.255.0
!
interface FastEthernet0/0.59
encapsulation dot1Q 59
ip address 191.1.59.5 255.255.255.0
!

N.B. 2 desirable commands when implementing a dot1q tunnel...
system mtu 1504 - ensures the exra 4 byte dot1q header is accomodated
vlan dot1q tag native - ensures there is no chance of confusion between customer and service provider untagged vlans.

N.B.B Having now revisited this blog some 5 months later i realise one assumption made here!! Of course VLAN 500 must be trunked between the SP switches!!

Wednesday, November 12, 2008

MQC - Shape vs Bandwidth Parameter

In this post i examine the difference between the MQC shape and bandwidth parameters. Often when applying a config to answer a lab question i find that i have made the incorrect choice in my selection, using one option, shape or bandwidth, when in fact the other was the required solution.

My confusion was cleared up when i found the following example on the doc cd.

Router(config)# policy-map shape-cbwfq
Router(config-pmap)# class cust1
Router(config-pmap-c)# shape average 384000
Router(config-pmap-c)# bandwidth 256
Router(config-pmap)# class cust2
Router(config-pmap-c)# shape peak 512000
Router(config-pmap-c)# bandwidth 384
Router(config-pmap-c)# configure terminal


In the above scenario both parameters, shape and bandwidth, were used at the same time! In reality this is because each parameter performs a different function.

In summary: bandwidth allocates a minimum bandwidth to the selected traffic flow, whereas shape enables the traffic flow to rise to the assigned throughput before throttling occurs. A subtle but explicitly different function.

Note to myself here, is to read carefully what the question requires. Use bandwidth to reserve throughput and shape to limit throughput.

Frame Relay - TCP and RTP header compression

TCP or RTP compression can be used to increase efficiency of bandwidth utilisation on slow serial connections. It can be enabled on a per interface basis or simply on a per DLCI basis. Likewise if enabled on a physical interface it can then also be disabled on a per DLCI basis.

Configuration for RTP and TCP compression follows the same syntax. In this post i detail the steps necessary to enable RTP compression first on an interface and second just on a single DLCI.

First to enable on an interface.

config-if#ip rtp header-compression

or

config-if#ip rtp header-compression passive


In the first case header compression is applied to all packets, whereas in the later it is only applied to those packets that arrive with header compression already enabled.

Second to apply on a per DLCI basis

config-if#frame-relay map ip 162.1.0.3 403 rtp header-compression active connections 15

Documentation can be found on the DOC CD under the WAN Configuration section at

http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/wcffrely_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1002780

Tuesday, November 11, 2008

BGP Unsuppress Maps

Within BGP routes can be summarized using the 'aggregate-address' command. When the summary-only option is utilised all granular routes within the summary range are suppressed.

If a BGP neighbor requires some of the granular routes within the summary this can be achieved via use of the 'unsuppress-map' neighbor command.

Of note here!!! When defining the routes to be unsuppressed do NOT use an acl - this simply does not work in my experience. Use a prefix-list and all works as expected.

router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 summary-only
neighbor 1.2.3.4 unsuppress-map R3

route-map R3
match ip address prefix-list R3

ip prefix-list R3 seq 10 permit 116.0.0.0/8
ip prefix-list R3 seq 15 permit 117.0.0.0/8
ip prefix-list R3 seq 20 permit 118.0.0.0/8
ip prefix-list R3 seq 25 permit 119.0.0.0/8


N.B.
An alternative to using the 'summary-only' key word on the aggregate-address command is via the 'suppress-map' option can be used to achieve the same net result.
e.g.
route-map SUPPRESS
router bgp 100
aggregate-address 112.0.0.0 248.0.0.0 suppress-map SUPPRESS

In summary routes can be suppressed on the aggregate-address command and unsupressed in a more garnular fashion with the neighbor commands.

Friday, November 7, 2008

Multicast Routing - Selecting RPS

In this post i look at auto rp and how the mapping agent can be used to select specific RPs for specified groups.

This requires the use of the command ip pim rp-announce-filter on the mapping agent. The rp-announce filter needs to match the send-rp-announce
filter used by the RPs. If the groups requested by the RP do not match the mapping agent’s filters, non matching groups are discarded.

Example:


R1 (MAPPING AGENT)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-discovery Loopback0 scope 16
ip pim rp-announce-filter rp-list 1 group-list 2
!
access-list 1 permit 150.1.3.3
access-list 2 permit 239.0.0.0 0.255.255.255



R3 (CANDIDATE RP)
interface Loopback0
ip pim sparse-dense-mode
!
ip pim send-rp-announce Loopback0 scope 16 group-list 50
!
access-list 50 permit 239.0.0.0 0.255.255.255



post script.
If the rp-announce-filter does not match an rp then NO filtering is applied. That is for filtering to take place a positive match is first required on the RP within the RP list. Hence to filter RP multicast groups announced by an RP it is first necessary to match the RP and specify the allowed multicast groups. If the RP is denied in the RP list then NO filtering is applied!!

Thursday, November 6, 2008

BGP Dampening

Enables BGP to suppress use and advertisement of routes that consistently flap.

Configured under the BGP routing protocol. Each time a route flaps a penalty of 1000 is applied to it. This value does NOT appear to be configurable. However the threshold at which routes are suppressed or unsuppressed is.

Suppress Limit: the value to start suppressing a route.

Reuse Limit: the value to start reusing a route.

Alongside these values its possible to
1) specify how quickly a routes penalty is reduced following a period of stability: this is termed 'half-life'.
2) specify the maximum suppression time for a route if it has been stable. This value kicks in if half life degradtion of a penalty takes 'too long'. For example a route may have a period of very high instability and incurr a high penalty - in this scenario it may take an inordinate time of stability to enable re-advertisement waiting for half-life degradation.

The config can simply be applied as follows if the default values will suffice:

bgp dampening

Default values are
penalty: 1000 (not configurable)
half life: 15 minutes
suppress limit: 2000
reuse limit: 750
max suppress: 4 * half life.

If there was a requirement to change half life to 30 minutes, and suppress limit to 3000, whilst leaving other parameters at default this can be achieved as follows:

R1(config-router)#bgp dampening 30 750 3000 120


R1#show ip bgp dampening para
dampening 30 750 3000 120
Half-life time : 30 mins Decay Time : 3600 secs
Max suppress penalty: 12000 Max suppress time: 120 mins
Suppress penalty : 3000 Reuse penalty : 750



You can apply dampening to specific routes by using a route-map to match the prefixes you want to apply dampening to.

First, create the prefix-lists to match the routes:

ip prefix-list RICH seq 5 permit 12.0.0.0/8
ip prefix-list RICH seq 10 permit 13.0.0.0/8


Then match them in the route-map and set the dampening parameters:

route-map DAMPEN permit 10
match ip address prefix-list RICH
set dampening 10 1000 2000 30


Finally, under the BGP process apply the route-map to the dampening command:

router bgp 100
bgp dampening route-map DAMPEN


This ensures that only the prefixes matched in the route-map have dampening applied to them.

Sunday, November 2, 2008

VRRP - Part 2 Object Tracking Using Metric








R2 and R3 are configured for VRRP on a shared LAN segment. R3 is the master unless its route to 13.0.0.0/24 disappears or its metric increases.

R3
interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
duplex half
vrrp 1 ip 10.0.0.254
vrrp 1 priority 101
vrrp 1 authentication text RICH


Here is the route to 13.0.0./24

Router_3#s ip route 13.0.0.1
Routing entry for 13.0.0.0/24
Known via "ospf 1", distance 110, metric 61, type intra area
Last update from 12.0.0.5 on FastEthernet1/0, 00:12:32 ago
Routing Descriptor Blocks:
* 12.0.0.5, from 12.0.0.5, 00:12:32 ago, via FastEthernet1/0
Route metric is 61, traffic share count is 1

Note the OSPF metric is 61. For the purposes of tracking 61 i will mark as an UP metric and anything higher/worse will be considered DOWN.

track 10 ip route 13.0.0.0 255.255.255.0 metric threshold
threshold metric up 61 down 62


I introduce the tracking parameter to VRRP

interface FastEthernet0/0
vrrp 1 track 10


I know check the state of the tracked object

Router_3#s track 10
Track 10
IP route 13.0.0.0 255.255.255.0 metric threshold
Metric threshold is Up (OSPF/61/61)
4 changes, last change 00:16:34
Metric threshold down 62 up 61
First-hop interface is FastEthernet1/0
Tracked by:
VRRP FastEthernet0/0 1



The tracked object is marked UP and R3 remains the master!

Router_3#s vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 1 101 3605 Y Master 10.0.0.3 10.0.0.254

I now increase the metric of the 13.0.0.0 route by increasing the OSPF cost on neighboring router R5.

R5(config)#int fa1/0
R5(config-if)#ip ospf cost 200


R3 detects the metric has changed and decrements the priority by 10 (default) and the router now becomes the backup.

00:44:58: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Backup
Router_3#s vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Fa0/0 1 91 3605 Y Backup 10.0.0.2 10.0.0.254

Checking the tracking status again.

Router_3#s track 10
Track 10
IP route 13.0.0.0 255.255.255.0 metric threshold
Metric threshold is Down (OSPF/201/201) 5 changes, last change 00:02:08
Metric threshold down 62 up 61
First-hop interface is FastEthernet1/0
Tracked by:
VRRP FastEthernet0/0 1

VRRP - Part 1 Authentication




VRRP is a non-proprietary router redundancy protocol (as opposed to the CISCO proprietary HSRP) defined by RFC2338. The aim of boths protocols is to provide a redundant default gateway for hosts on the same subnet. This is achieved by enabling a virtual IP address that in effect both (or more) routers service.

On the DOC CD HSRP is found under 12.2 ip services. I found VRRP under 12.3 ip services.

http://www.cisco.com/en/US/docs/ios/12_0st/12_0st18/feature/guide/st_vrrpx.html

The good news as far as i can see is that vrrp config is almost identical to HSRP: just substitute vrrp keyword instead of the standby keyword.

In this example i make R2 and R3 vrrp partners

Router 2
interface fastethernet 0/0
vrrp 1 ip 10.0.0.254

Router 3
interface fastethernet 0/0
vrrp 1 ip 10.0.0.254

Router_3#s vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.0.0.3 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec

Router_2#s vrrp
FastEthernet0/0 - Group 1
State is Backup
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.0.0.3, priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 2.741 sec)

Unlike HSRP preemption comes pre enabled. VRRP has the concept of master and backup router as opposed to HSRPs active and standby.

Now to introduce authentication. This feature only allows plain text authentication, so in itself it is not really a security feature but rather a feature to prevent misconfigured hosts joing the group.

To enable

Router 1
interface fastethernet 0/0
vrrp 1 authentication text RICH

Router 3
interface fastethernet 0/0
vrrp 1 authentication text RICH

Now to review the vrrp status again

Router_2#s vrrp
FastEthernet0/0 - Group 1
State is Master
Virtual IP address is 10.0.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Authentication is enabled
Master Router is 10.0.0.2 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec

Thursday, October 30, 2008

'Useful To Know' Commands


I have created this post to document all those ad hoc commands that can be extremely useful but can also be easily forgotten! Plus its these little tweeks that CCIE labs love to drop into the mix. Over time i hope this grows, and pls let me know if you have any suggestions of your own.

show tcp brief
Shows the status of tcp sessions on the router. Useful for troubleshooting.

ip pim spt-threshold infinity
By default PIM sparse mode will automatically move over to a source tree topology once the source has been discovered via the shared tree. This command can be used to disable this default behaviour.

ip tcp syn-timeout 5
Reduces the time the IOS will wait for a TCP SYN-ACK before timing out and returning control to the command prompt. Can be usefull if you've ever waited around for control to return after a failed telnet session attempt!

configuration mode exclusive auto
Once conf t mode is entered an exclusive lock is applied to prevent other users entering conf t.

ppp reliable-link
ppp reliable link is Cisco's implementation of RFC 1663:PPP Reliable Transmission. It enables negotiation and use Numbered Mode LAPB over a serial link. This effectively ensures retransmissions if packet loss or error is detected.

vlan dot1q tag native
By default a dot1q trunk will leave the native VLAN untagged. Use this command to ensure all VLANs are tagged with a 32 bit header

show ip bgp neighbor {address} inc Flags
Flags: higher precedence, nagle, md5
This command will denote whether BGP encryption is in use with the denoted peer.

logging trap {n}
Used to specify the severity of log messages that generate traps.

transport preferred none
The default ios behaviour when typing an ip address (or anyother name) and hitting enter assumes the user is attempting a start a telnet session. This can be changed! with this command. Once entered the user has to be explicit when trying to start a telnet session i.e. telnet {address}.

ipv6 rip {name} default-nformation originate
ipv6 rip {name} default-information only
The first command, as you might expect, injects a default route. The second command injects a default route and filters all other more specific routes.

show queue {interface}
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 772 kilobits/sec

This command shows the amount of available bandwidth left on an interface for allocation via a service policy.

class-map {xxxx}
match not protocol {yyyy}
Allows a class map to match all protocols except the one specified

int {x}
switchport trunk encap dot1q
switchport mode trunk
switchport nonegotiate
This config enables trunking on the specified interface. Even though 'trunking' mode has been specified the port will still issue DTP frames. The 'nonegotiate' ensures DTP frames are not issued. Conversely 'switchport mode dynamic desirable' can be used to enable DTP.

priority x y
When configuring a priority this goes hand in hand with setting the max available bandwidth x. Another option 'y' allows the burst value to be set.


router bgp x
no bgp fast-external-fallover

neighbor {a.b.c.d} timers 10 30
To ensure bgp routes are not immediately withdrawn from the table when a directly connected link to a neighbor drops the above commands can be used. In this instance the link is only declared down once an hello has not been received for 30 seconds.

service timestamps log datetime msec
adds current date and time including the milliseconds to logging messages

ignore lsa mospf
Cisco routers do not support LSA Type 6 MOSPF packets. Use this command to suppress warning messages if they are received.

ip ospf authentication null
Use this command to turn off authentication on an interface. N.B. Do not use no ip ospf authentication!! This will not work.

ip hello-interval eigrp x y
ip hold-time eigrp x z
To adjust the EIGRP timers use the above commands under the interface configuration. IMO it would have been a more congruent design to have had 'ip eigrp hello-interval/hold-time'. Take a look at 'ip ospf hello-interval' for example! But i guess its not my place to reason why, just to make a mental note for when i'm searching for the command and wondering where it has gone:-)


ip multicast rpf backoff x y
Command to alter the frequency of triggered RPF checks. Usefull when there is unstability in the unicast routing table. x = minimum in ms and y = maximum in ms.

line vty 0 4
ipv6 access-class
To apply an ipv6 access-class under the vty interface prefix with ipv6.

ip ftp username ric
ip ftp password cisco

With the commands above the router is configured to use the username "ric" and the password "cisco" for FTP connections.

show ntp ass det
150.1.1.1 configured, authenticated, our_master, sane, valid, stratum 8
Usefull command to determine if the ntp connection is authenticated.

line vty 0 4
rotary 23

Enables the telnet service on port 3023 (in addition to port 23). Honest! i've tried it:-)

show ip port
I stumbled across this one by accident when trying to determine listening sockets on a router (show have use ship ip scoket). This command is fantastic if you want to list the IANA ports and the relevant protocols. Could be very usefull when building acls and class maps.

config-if#ip nbar protocol-discovery
show ip nbar protocol-discovery
Wow. Stumbled across this one on a lab. It keeps a record of all the protocols flowing through a port.

logging rate-limit n
Limit the number of syslog messages to n per second

logging rate-limit n except x
limit the number of syslog messages to n pers second except for those of priority x and higher

line vty 0 4
refuse-message @Try in 5 mins@
Configure a message when the connection is refused e.g. when all lines are busy

Wednesday, October 29, 2008

ip alias

How can you make a device 'own' an address when it has no interfaces with that address??!! An example where this could theoretically be a requirement is where some hosts have been configurd with an incorrect host entry i.e. with the wrong ip address specified for the host.

With the ip alias command this effectivelly allows multiple addresses to be assigned to the router.

With the following command the router will respond to a telnet session to ip address 1.1.1.1

ip alias 1.1.1.1 23

use the command show ip alias to verify

CISCO menu

In my previous post CISCO IOS privilege levels i denoted how user access to specific commands can be controlled by making use of CISCO privilege levels. Another tool available in the CISCO arsenal is the use of menus.

By making use of the menu command access can be limited to the commands explicitly made available on the menu only.

To apply menu access to a particular user login simply apply the following config where RICH is the name of the menu to be invoked upon login.

user x password y
user z autocommand menu RICH

line vty 0 4
login local



Unless configuring menus is something that you do day to day, or you have a desire to master this subject my thoughts on creating the menus is to refer to the CISCO doc cd and crib the syntax from there.

http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf004.html#wp1002212

The example given is


menu new title ^C
Telnet Menu
^C
menu new prompt ^C
Please enter your selection: ^C
menu new text 1 telnet system1
menu new command 1 telnet system1
menu new options 1 pause
menu new text 2 telnet system2
menu new command 2 telnet system2
menu new options 2 pause
menu new text b telnet systemblue
menu new command b telnet systemblue
menu new options b pause
menu new text me show user
menu new command me show user
menu new options me pause
menu new command here show version
menu new text Exit Exit
menu new command Exit menu-exit
menu new clear-screen
menu new status-line
menu new default me

Invoking the above config gives the following menu

C
Telnet Menu


1 telnet system1

2 telnet system2

b telnet systemblue

me show user

Exit Exit

C


One hidden command 'show version' is available in this menu. This can be invoked by entering the text 'here'.

One point on this doc cd example i didnt like was the Exit command. Once entered it returns the user to the command prompt! In a real world scenario i would suggest this needs to be changed to exit the router.

This leads me to another point. After applying the following config.....

no menu new command Exit menu-exit
menu new command Exit exit

I found the first command no menu new command Exit menu-exit had in fact removed the whole menu! Hence before attempting any mods on a menu save in notepad first! Once reapplying the config with this modified command it had the desired effect - upon exiting the menu the users telnet session is terminated.

Monday, October 27, 2008

WRED - Part I precedence based

The TCP algorithm by default will cause TCP senders to back off when packet loss occurs. One of the main problems with this is that all senders will back off at the same time and slowly build up the transmission rate until packet loss occurs again. Much like cars on a three lane motorway this causes the 'concertina effect' where all traffic backs off and speeds up at the same rate.

The aim of WRED or Weighted Random Early Detect is to get around this problem by intelligently getting senders to back off at different times based on the configured weightings.

To enable the default WRED algorithim simply requires the config-if#random-detect parameter to be entered on the required interface.

The default settings can be viewed with the show queueing random-detect command.

R1#s queueing random-detect
Current random-detect configuration:
FastEthernet0/0
Queueing strategy: random early detection (WRED)
Random-detect not active on the dialer
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0

class Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 20 40 1/10
1 0/0 0/0 22 40 1/10
2 0/0 0/0 24 40 1/10
3 0/0 0/0 26 40 1/10
4 0/0 0/0 28 40 1/10
5 0/0 0/0 31 40 1/10
6 0/0 0/0 33 40 1/10
7 0/0 0/0 35 40 1/10
rsvp 0/0 0/0 37 40 1/10


Of note in the above output:-

class 0 -7 : denotes the IP precedence value.
tail drop pkts Min: denotes the interface queue size at which packets will start to be dropped.
tail drop pkts Max: denotes the interface queue size at which all packets will be dropped.
Mark Prob: denotes the fraction of packets that will be dropped once the tail drop pkts Min has been reached. The default being 1 in 10.

If there was a lab requirement to ensure packets with an ip precedence of 0 (routine) were to be subject to tail drop when the interface queue size reached 10 (as opposed to the default of 22) this can be achieved as follows:

int fa0/0
randon-detect precedence 0 10 40 10


Once entered the new parameter settings can be viewed by using the show queueing random-detect command again.

R1#s queueing random-detect
Current random-detect configuration:
FastEthernet0/0
Queueing strategy: random early detection (WRED)
Random-detect not active on the dialer
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0

class Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 10 40 1/10
1 0/0 0/0 22 40 1/10
2 0/0 0/0 24 40 1/10
3 0/0 0/0 26 40 1/10
4 0/0 0/0 28 40 1/10
5 0/0 0/0 31 40 1/10
6 0/0 0/0 33 40 1/10
7 0/0 0/0 35 40 1/10
rsvp 0/0 0/0 37 40 1/10

WRED can also be enabled based on DSCP settings and also based on configured traffic classed. Food for another post.

Sunday, October 26, 2008

Multicast Routing - Part IV Limiting Bandwith Part 2

In my previous post on rate limiting multicast traffic i made use of the ip multicast rate-limit function. If prohibited from using the function similar limiting can be achieved via MQC. As ever with the CCIE lab i think it pays to have more than one method of achieving the same goal.

ip access-list extended MCAST
permit ip 224.0.0.0 31.255.255.255

class-map MCAST
match access-group name MCAST

policy-map LIMITMCAST
class MCAST
police 8000

interface s2/0
service-policy output LIMITMCAST


R2#show policy int s2/0

Serial2/0

Service-policy output: S2/0

Class-map: LIMITMCAST (match-all)
7450 packets, 3340440 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name MCAST
police:
cir 8000 bps, bc 1500 bytes
conformed 5089 packets, 1649908 bytes; actions:
transmit
exceeded 2173 packets, 1679628 bytes; actions:
drop
conformed 0 bps, exceed 0 bps

Class-map: class-default (match-any)
991 packets, 47636 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Friday, October 24, 2008

OSPF routing part VI - load balancing


Consider the scenario where router 4 and 5 are running OSPF and have 2 paths connecting each other: one over a 1.544 mb frame relay connection and the other a 100MB LAN segment.

The requirement here is to get OSPF to equally load balance traffic over both connections, but without adjusting the OSPF cost.

The OSPF default is that it will load balance over 4 paths as long as they have equal cost. In this scneraio the OSPF cost can be examined using the show ip ospf interface command. The Frame-relay cost is 64 and the LAN segment has cost 1. This is calculated by dividing the auto-cost reference bandwidth ( 100,000,000 ) by the interface bandwidth.

Herein lies the clue to enable resolution of this problem. If we are prohibited from adjusting the cost, the only other variable that can be used to influence OSPF is the interface bandwidth. This can be adjusted under the interface configuration.

Hence on R4 and R5 i use the config-if#bandwidth 100000 command on the serial frame-relay interfaces.

I then examine the routing table on R4 to check that it now has 2 paths installed in the routing table for links originated from R5.

R4#s ip route 150.1.5.5
Routing entry for 150.1.5.5/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 141.1.54.5 on Serial2/0, 00:00:14 ago
Routing Descriptor Blocks:
* 141.1.145.5, from 150.1.5.5, 00:00:14 ago, via FastEthernet0/0
Route metric is 2, traffic share count is 1
141.1.54.5, from 150.1.5.5, 00:00:14 ago, via Serial2/0
Route metric is 2, traffic share count is 1

Wednesday, October 22, 2008

storm control - level and pps


The storm-control function can be used on the 3550 and 3560 to limit the amount of unicast, broadcast and multicast traffic on a port.

For example

config-if#storm-control unicast level 50 40
config-if#storm-control action shutdwon


The above config will limit the unicast port utilisation to 50%. At this level the port will be shutdown. When unicast utilisation drops below 40% the port will be re-enabled.


Another feature available within the storm control configuration is to set the utilisation based on the pps (packets per second). Hence if the requirement states a max throughput of 500 pps this can be achieved as follows


config-if#storm-control unicast level pps 500 400
config-if#storm-control action shutdown


With the above config the port will begin forwarding once the pps threshold drops below 400 pps.

An alternative storm control action is simply trap, this will cause the port to only generate an snmp trap when thresholds have been reached.

Tuesday, October 21, 2008

spanning-tree guard loop





In this post i look at the 'spanning-tree guard loop' command. Not to be confused with the similar 'spanning tree guard root' command that performs a very different function.


Consider the above topology where 2 switches are directly connected via two trunk links. Switch 3 is elected as the root bridge and as such both trunk links fa0/13 and fa0/15 are Designated Ports. Vlan 258 is running across both trunks.

SW3#s span vlan 258

VLAN0258
Spanning tree enabled protocol ieee
Root ID Priority 33026
Address 0013.80de.b880
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 33026 (priority 32768 sys-id-ext 258)
Address 0013.80de.b880
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ---------------
Fa0/13 Desg FWD 19 128.13 P2p
Fa0/14 Desg FWD 19 16.14 P2p




On Switch 2 port fa0/14 is elected as the root port and port fa0/13 is blocked to so ensuring a loop free path at L2.

SW2#s span vlan 258

VLAN0258
Spanning tree enabled protocol ieee
Root ID Priority 33026
Address 0013.80de.b880
Cost 19
Port 14 (FastEthernet0/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 33026 (priority 32768 sys-id-ext 258)
Address 0013.c34f.5000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- -------------
Fa0/13 Altn BLK 19 128.13 P2p
Fa0/14 Root FWD 19 128.14 P2p




Now consider the scenario where port fa0/13 on Switch 2 were to stop receiving BPDUs!? In this instance spanning tree would re-evaluate the ports role and as a result would make the port a designated port! In the above topology this createa a L2 loop!

To put this to the test i applied the command 'spanning-tree bpdufilter enable' on port fa0/13 on Switch 3. This confirmed this expected behaviour and the ports on my switches lit up like machines gun fire!! I had created an entertaining L2 loop.

This is precisely the scenario which the command 'spanning-tree guard loop' can prevent. I applied this command on Switch 2 fa0/13 port and repeated the above test. The resulting port state was then as below:-



SW2#s span vlan 258

VLAN0258
Spanning tree enabled protocol ieee
Root ID Priority 33026
Address 0013.80de.b880
Cost 19
Port 14 (FastEthernet0/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 33026 (priority 32768 sys-id-ext 258)
Address 0013.c34f.5000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ---------------
Fa0/13 Desg BKN*19 128.13 P2p *LOOP_Inc
Fa0/14 Root FWD 19 128.14 P2p

Instead of moving port fa0/13 to a Designated Role it is moved to the LOOP Inconsistent state. Once i re-enable BPDUs from Switch 3 then the port returned to its normal operation as a Altn Blk port.

Monday, October 20, 2008

VTP and Pruning

I came across the following lab requirement that initially had me puzzled.

SW1 and SW2 are part of the same VTP domain and VTP pruning is enabled - SW1 is in server mode and SW2 is in client mode. SW1 and SW2 are connected via a trunk interface. SW1 has vlan 10 and ports active in this vlan. SW2 has no ports in vlan 10. Ensure SW2 continues to receive unknown unicast, broadcast and multicast traffic for vlan 10 over the trunk link?

Of course with pruning enabled the default behaviour is for vlan 10 traffic to be pruned from the trunk interface. This is the required function of pruning!

VTP pruning is a global command and so changing this is not an option. In fact the solution to this problem is to make use of the 'switchport trunk pruning' interface command. This command takes precedence over the global setting.

Hence to achieve the lab requirement i entered the following command under the trunk interface.

config-if#switchport trunk pruning 2-9,11-1001

To examine the port pruning status use the 'show interface x switchport' command.

SW2#s int fa0/13 switchport | inc Pruning
Pruning VLANs Enabled: 2-9,11-1001

Saturday, October 18, 2008

Reflexive ACL and PING

Following on from the 'Reflexive ACL and Traceroute' post i now look at some anomolies i found when generating locally based traffic on the router carrying the reflexive acl.

With i try a ping from R3 to BB1 everything works as expected.

R3#P 200.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/546/1148 ms


When i try a ping from R6 to BB1 the same cannot be said...

R6#P 200.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


This can be explained because locally generated traffic does not run through that routers interfaces. If it is a requirement for locally based pings to execute successfully this leaves a small problem. In this post i offer two solutions to this problem.

This first is simply to allow icmp any any echo-reply on the inbound acl, effectively circunventing the reflexive acl logic.

The second solution ensures locally based traffic 'flows through' the same reflexive acl logic by 'fooling' the router into thinking this traffic has been originated externally.

ip access-list extended LOCAL
permit tcp any any
permit icmp any any
route-map LOCAL
match ip address LOCAL
set interface Loopback0

ip local policy route-map LOCAL


I now try the ping test again....

R6#P 200.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/256/684 ms


Additionally since i matched locally generated tcp traffic i also test locally generated telnet traffic

R6#telnet 200.1.1.1
Trying 200.1.1.1 ... Open

Reflexive ACL and Traceroute




In this post i describe reflexive acls and their implementation. In addition i write about the use of traceroute when used in conjunction with a reflexive acl.

The requirement with the above topology is that R6 is secured from unauthorised access from bb1. R6 should only allow TCP, UDP and ICMP traffic in from bb1 if it has been originated from behind R6. Additionally ensure traceroute can be succesfully executed from behind R6.

I create a reflexive acl to meet this requirement. On the outside interface S2/0 i create and apply my 'reflect' acl and then on the same interface i allow this traffic back in with the evaluate statement as follows:-

ip access-list extended REFLECT
permit tcp any any reflect RICH
permit udp any any reflect RICH
permit icmp any any echo reflect RICH
permit ip any any

int s2/0
ip access-group REFLECT out

As per the lab requirement the REFLECT acl has line statements for tcp, udp and icmp traffic, along with a generic permit as there is no requirement to prevent any outbound traffic.

I then create the inbound ACL for the s2/0 interface. Care needs to be taken to ensure any existing routing protocol traffic is not disrupted.

ip access-list extended INACL
permit udp any any eq rip
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate RICH
deny ip any any log

int s2/0
ip access-group INACL in

From R3 i now try an outbound tcp session to ensure the reflexive acl is acting as it should

R3#telnet 200.1.1.1

Trying 200.1.1.1 ... Open

Success! I examine the acls on R6 and can see the relexive acl has come into effect..

R6#s ip access-list RICH

Reflexive IP access list RICH permit tcp host 200.1.1.1 eq telnet host 136.1.136.3 eq 48296 (27 matches)(time left 7)


Now i try traceroute from R3 as per the lab requirement.

Rack1R3#TRACE 200.1.1.1

Type escape sequence to abort.
Tracing the route to 200.1.1.1
1 136.1.136.6 496 msec 996 msec 392 msec
2 * * *
3 * * *
4 * * *
5 * * *

Failure! I examine the relexive acl on R6


R6#s ip access-list RICH

Reflexive IP access list RICH permit udp host 200.1.1.1 eq 33480 host 136.1.136.3 eq 37054 (1 match) (time left 19)

I can see the reflexive acl has been brought into action, but the traceroute is still failing!!

I run a packet capture to further determine problem. From this i can see that the outbound traceroute packet leaves as a UDP packet, however the response coming from the far end router arrives as an ICMP port unreachable packet!

This explains the failure as this traffic exchange falls foul on the refelexive acl logic i.e. the returning packet stream does not match the outbound.
To get around this problem requires an explicit entry in the inbound ACL to permit icmp port unreachable messages.

R6(config)#ip access-list ext INACL
R6(config-ext-nacl)#41 permit icmp any any port port-unreachable

I then try traceroute from R3 this time with success!

R3#TRACE 200.1.1.1
Type escape sequence to abort.

Tracing the route to 200.1.1.1
1 136.1.136.6 724 msec 548 msec 208 msec
2 54.1.3.254 1272 msec 876 msec 1056 msec

Another example of a protocol that falls foul of reflexive acl logic is active FTP. With this protocol the control and data sessions are initiated on different ports in different directions, something that will break the reflexive acl model.