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
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.
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.
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
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
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
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
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
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.
Type escape sequence to abort.
Tracing the route to 200.1.1.1
1 136.1.136.6 724 msec 548 msec 208 msec
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.
Friday, October 17, 2008
Rate Limiting vs Policing
Rate limiting has now been by and large superceded by MQC (Modular QOS CLI). Hence if requested to rate limit a traffic flow the chances are an MQC solution will be whats required, as ever, close attention to the question specifics is required.
In this scenario i limit the traffic flow for returning web traffic to the LAN segment on connected interface fa0/0 to 512kbps.
ip access-list extended 100
permit tcp any eq www any
class-map HTTP
match access-group 100
policy-map HTTP
class HTTP
police cir 512000
int fa0/0
config-if#service-policy output HTTP
Multicast Routing - Part IV Limiting Bandwith Part I
Following on from Multicast Routing Part III i now look at how multicast streams can be controlled to limit bandwidth utilisation.
For multicast streams 227.20.20.20 i implement a policy that limits bandwidth consumption to 100k.
First i define my acl.
access-list 20 permit 227.20.20.20
Then i make use of the rate-limit function to control this streams network utilisation
#int fa0/0
config-if# ip multicast rate-limit out group-list 20 out
To prevent unnecessary bandwidth utilisation caused by multicast feeds looping around the network i can also set a multicast ttl threshold on the interface. For example to ensure no multicasts are sent when there ttl drops below 10 i can enter the following command.
#int fa0/0
config-if#ip multicast rate-limit 9
For multicast streams 227.20.20.20 i implement a policy that limits bandwidth consumption to 100k.
First i define my acl.
access-list 20 permit 227.20.20.20
Then i make use of the rate-limit function to control this streams network utilisation
#int fa0/0
config-if# ip multicast rate-limit out group-list 20 out
To prevent unnecessary bandwidth utilisation caused by multicast feeds looping around the network i can also set a multicast ttl threshold on the interface. For example to ensure no multicasts are sent when there ttl drops below 10 i can enter the following command.
#int fa0/0
config-if#ip multicast rate-limit 9
Thursday, October 16, 2008
Multicast Routing - Part III Controlling Access
If there is a requirement to restrict multicast groups that hosts on a segment can join this can be achieved by filtering on the connected interface.
Simplying create an acl denoting those multicast groups that are permitted on the LAN segment. Then apply the 'ip igmp access-group {acl}' command to the interface.
For example, i restrict access to multicast groups 227.20.20.20 and 228.20.20.20 on the interface as follows
access-list 60 permit 227.20.20.20
access-list 60 permit 228.20.20.20
#int fa0/23
config-if#ip igmp access-group 60
To check the acl has been appiled i use 'show ip igmp interface fa0/23' command.
Simplying create an acl denoting those multicast groups that are permitted on the LAN segment. Then apply the 'ip igmp access-group {acl}' command to the interface.
For example, i restrict access to multicast groups 227.20.20.20 and 228.20.20.20 on the interface as follows
access-list 60 permit 227.20.20.20
access-list 60 permit 228.20.20.20
#int fa0/23
config-if#ip igmp access-group 60
To check the acl has been appiled i use 'show ip igmp interface fa0/23' command.
Multicast Routing - Part II Statically Connected Member
If there is a requirement for a host on a segment to receive multicast traffic but the host is unable to request membership itself via igmp this initially poses a problem. To get around this the connected switch interface can request multicast traffic on behalf of the host.
Such a configuration effectively makes the host on the segment a statically connected member of the group. Two commands are available, and differ in the respect of how the switch forwards the multicast traffic.
First
#int fa0/23
config-if#ip igmp join-group {group address}
This command forces the switch to accept the multicast stream and forward out of the interface via process switching.
Second
#int fa0/23
config-if#ip igmp static-group {group address}
With this command the switch does NOT accept the multicast stream itself but simply forwards them out of the specified interface. This forwarding is done by fast switching, as opposed to process switching when the previous command is used
As with all 3560 multicast commands they can be found on the doc cd under the IP multicast routing section.
Wednesday, October 15, 2008
Multicast Routing - Part I Sparse Dense Mode
When multicast sparse dense routing is enabled then sparse mode is the preferred method of operation. If an RP is not configured or is unreachable for a particular multicast group then dense mode becomes the failover method.
The RP can be configured statically or via Auto-RP. Prior to release 12.2.7 PIM sparse dense mode was a pre-requisite for Auto-RP. This meant that dense mode failover was a feature even if not desired! To get around this from 12.2.7 onwards Auto-RP can be used with PIM sparse mode provided the 'ip pim autorp listener' global config command is used.
The RP can be configured statically or via Auto-RP. Prior to release 12.2.7 PIM sparse dense mode was a pre-requisite for Auto-RP. This meant that dense mode failover was a feature even if not desired! To get around this from 12.2.7 onwards Auto-RP can be used with PIM sparse mode provided the 'ip pim autorp listener' global config command is used.
Saturday, October 11, 2008
OSPF routing part V - network types
Running OSPF over frame relay is a core topic when it comes to the CCIE R & S lab. In my experience when there is full reachability at L2 over the frame relay cloud the choice of OSPF network type is wide. For example OSPF broadcast and point-to-multipont network types can be made to work with the right configuration.
However care needs to be taken when L2 reachability is not a full mesh. For example in a hub and spoke frame-relay topology where the spokes do NOT have complete frame-relay map statements to all the other spokes. In this instance the network type BROADCAST will NOT do, as full reachability at L2 is a prerequisite.
With such a topology either point-to-point or a point-to-multipoint must be selected as the OSPF network type. OSPF then understands there may not be full reachability at L2. It caters for this and will ensure traffic goes via the hub to reach the other spokes.
However care needs to be taken when L2 reachability is not a full mesh. For example in a hub and spoke frame-relay topology where the spokes do NOT have complete frame-relay map statements to all the other spokes. In this instance the network type BROADCAST will NOT do, as full reachability at L2 is a prerequisite.
With such a topology either point-to-point or a point-to-multipoint must be selected as the OSPF network type. OSPF then understands there may not be full reachability at L2. It caters for this and will ensure traffic goes via the hub to reach the other spokes.
PPP authentication
R2 and R3 are connected using ppp encapsulation. The following post denotes the steps necessary to enable
i) PAP or clear text authentication.
&
ii) CHAP
First PAP
On R2 and R3 its necessary to first configure the username and passwords.
R2
config#username R3 password CISCO
R3
config#username R2 password CISCO
Under the serial interfaces enable pap authentication.
on R2 and R3
config-if#ppp authentication pap
Under the serial interfaces configure the pap username and password to be sent to the remote router
R2
config-if#ppp pap sent-username R2 password CISCO
R3
config-if#ppp pap sent-username R3 password CISCO
For verification enable debub ppp authentication
For chap authentication the task list is actually shorter. The same as above except 'ppp authentication chap' under the interface and the last step does not apply!
Again debug ppp authentication denotes success or failure!
*Oct 11 11:26:36.762: Se2/1 PPP: Authorization required
*Oct 11 11:26:36.846: Se2/1 CHAP: O CHALLENGE id 2 len 28 from "Rack1R2"
*Oct 11 11:26:36.902: Se2/1 CHAP: I CHALLENGE id 3 len 28 from "Rack1R3"
*Oct 11 11:26:36.910: Se2/1 CHAP: Using hostname from unknown source
*Oct 11 11:26:36.910: Se2/1 CHAP: Using password from AAA
*Oct 11 11:26:36.914: Se2/1 CHAP: O RESPONSE id 3 len 28 from "Rack1R2"
*Oct 11 11:26:36.974: Se2/1 CHAP: I RESPONSE id 2 len 28 from "Rack1R3"
*Oct 11 11:26:36.974: Se2/1 PPP: Sent CHAP LOGIN Request
*Oct 11 11:26:36.974: Se2/1 PPP: Received LOGIN Response PASS
*Oct 11 11:26:36.974: Se2/1 CHAP: I SUCCESS id 3 len 4
Rack1R2(config-if)#
*Oct 11 11:26:36.978: Se2/1 PPP: Sent LCP AUTHOR Request
*Oct 11 11:26:36.982: Se2/1 PPP: Sent IPCP AUTHOR Request
*Oct 11 11:26:36.990: Se2/1 LCP: Received AAA AUTHOR Response PASS
*Oct 11 11:26:36.994: Se2/1 IPCP: Received AAA AUTHOR Response PASS
*Oct 11 11:26:36.994: Se2/1 CHAP: O SUCCESS id 2 len 4
*Oct 11 11:26:37.002: Se2/1 PPP: Sent CDPCP AUTHOR Request
*Oct 11 11:26:37.010: Se2/1 CDPCP: Received AAA AUTHOR Response PASS
*Oct 11 11:26:37.066: Se2/1 PPP: Sent IPCP AUTHOR Request
Thursday, October 9, 2008
Spanning Tree Timers
With the same topology as depicted in the Spanning Tree post there is a requirement to influence how long switch 2 takes to failover to its redundant paths to switch 1.
There are a few timers that can be tweaked. The spanning-tree forward-time and max-age timers allow them to be altered on a per VLAN basis.
Max-age is the time a switch waits if no configuration BPDUs are received from the root before entering the listening and then learning states. The default here is 20 seconds. Forward-time is 15 seconds by default for the listening and learning states.
The time it takes a redundant port to become active is equal to max-age plus the listening and learning forward-times i.e 20 + 15 + 15 = 50 seconds.
The minimum max-age is 6 seconds, and the minimum forward-time is 4 seconds. Hence the fastest spanning-tree convergence time that can be achieved by tweaking the timers is 14 seconds.
If faster convergence is required then tweaking the vlan spanning-tree timers is not going to help. In this instance for switch 2 where the are redundant paths to an upstream switch the spanning-tree uplink-fast feature can abe considered. This is not configurable on a per vlan basis but applies to all vlans on the switch.
With uplink-fast enabled if switch 2 detects a problem on the root port it can transition the redundant blocked interface to the forwarding state without waiting for the listening and learning timers. Typically this takes only 3-5 seconds.
Wednesday, October 8, 2008
Spanning Tree
In this post i cover a couple of the basic spanning tree concepts. Root switch selection and how root ports are elected.
In the above scenario the requirement is to make Switch 1 the root switch for vlans 4 and 44. Additionally there is a requirement for the default path for all traffic to be port fa0/12. In the event that this fails then fa0/11 should be used.
To select the root switch for vlans 4 and 44 this is simply achieved by applying the following command on Switch 1.
spanning-tree vlan 4,44 root primary
show span vlan 4
VLAN0004
Spanning tree enabled protocol ieee
Root ID Priority 24580
Address 0013.80de.b880
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24580 (priority 24576 sys-id-ext 4)
Address 0013.80de.b880
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 128.12 P2p
The output states that 'This bridge is the root' and ports 11 and 12 are both designated ports.
I repeat this command on Switch 2
SW2#s span vlan 4
VLAN0004
Spanning tree enabled protocol ieee
Root ID Priority 24580
Address 0013.80de.b880
Cost 19
Port 11 (FastEthernet0/11)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32772 (priority 32768 sys-id-ext 4)
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/11 Root FWD 19 128.11 P2p
Fa0/12 Altn BLK 19 128.12 P2p
Here the Root ID specifies the MAC address of Switch 1. Since the cost and priority of all links to SW1 are equal SW2 has elected the lowest port id as the root port - in this case fa0/11.
To meet the requirements Fa0/12 needs to be the root port. Cost and priority can be used to influence the root port selection. However the question states the configuration must be done on SW1. An important consideration is that port cost is NOT transmitted to neighboring switches. Each switch calculates its own upstream cost metric, hence modifying the port cost on SW1 will NOT change SW2 cost calculations. This only leaves priority as the parameter to change.
The default port priority is 128 (see above output). As with cost the lower the priority the more desirable the path. Hence on SW1 i change the priority of fa0/12 to 16 as follows.
SW1(config-if)#spanning-tree vlan 4,44 port-priority 16
show span vlan 4
Interface Role Sts Cost Prio.Nbr Type
-- --- --------- -- ------ --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 16.12 P2p
I then check on SW2 to ensure that fa0/12 has now become the root port.
SW2#s span vlan 4
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/11 Altn BLK 19 128.11 P2p
Fa0/12 Root FWD 19 128.12 P2p
One note of caution. The spanning-tree port priority can be set for all vlans on a port with the command 'spanning-tree port-priority x'. Be sure to read the question requirements to understand whether the priority needs to be changed for explicit vlans or for all!
IP Bridging
In this scenario two hosts belong to the same IP subnet but are assigned to 2 seperate VLANS: vlan 16 and vlan 36. I implement IP bridging to enable connectivity between the hosts.
On R6 I configure the following:-
1) configure the bridge group and enable ip routing
bridge 1 protocol ieee
bridge 1 route ip
2) assign the interfaces to the bridge group
bridge 1 route ip
2) assign the interfaces to the bridge group
config-if# bridge group 1
3) enable Intergrated Routing and Bridging (IRB)
bridge irb
4) create the bridge virtual interface and assign an ip address
#int bvi 1
config-if# ip address 136.1.136.6 255.255.255.0
I can now ping 136.1.136.1,136.1.136.3 and 136.1.136.6 from all routers.
Cisco Doc link
Tuesday, October 7, 2008
Password Encryption
When the IOS username, password combi is configured using the standard 'username xxxx password yyyy' command it is stored in the configuration in the clear.
The password can be encrypted using the 'service password-encryption' command. This ensures the password is no longer displayed in clear text in the config, but is obscured.
This type of encryption is also referred to as type 7 encryption and is in fact relatively easy to hack. Just do a google search on 'cisco password cracker'!
An alternative to this is MD5 encryption and much harder to crack. The password can be stored as an MD5 hash by using 'username xxxx secret yyyy'.
Note this way of storing passwords cannot be used in conjunction with PAP or CHAP.
ACLs and locally generated traffic
Configured router access lists do NOT apply to locally generated traffic. This default behaviour does not always meet requirements but there are ways around this feature.
With policy based routing there is the 'ip local policy route-map {name}' command to ensure locally based traffic runs through the said route-map.
With an outbound ACL traffic generated locally will not have the ACLs rules applied. Again there are workarounds to this problem. One clever method i came across was to utilise the aforementioned local policy routing command in conjunction with an attached loopback interface.
Effectively the locally generated traffic is PBR'd out of the loopback interface. This is enough to 'trick' the router that the traffic has been generated externally and it thus applies outgoing ACL logic to the traffic.
I provide an example here. I apply an outbound acl on R1 to prevent telnet traffic to R2.
ip access-list extended 100
deny tcp any any eq telnet
permit ip any any
int fa0/0
ip access-group 100 out
At first telnet traffic originating from R1 is allowed - the outbound access list is ignored. I implement PBR to ensure locally generated traffic first passes through the loopback interface.
int lo0
ip address 1.1.1.1 255.255.255.255
route-map RICH
set interface lo0
ip local policy route-map RICH
Now telnet traffic destined for R2 is blocked as required!
With policy based routing there is the 'ip local policy route-map {name}' command to ensure locally based traffic runs through the said route-map.
With an outbound ACL traffic generated locally will not have the ACLs rules applied. Again there are workarounds to this problem. One clever method i came across was to utilise the aforementioned local policy routing command in conjunction with an attached loopback interface.
Effectively the locally generated traffic is PBR'd out of the loopback interface. This is enough to 'trick' the router that the traffic has been generated externally and it thus applies outgoing ACL logic to the traffic.
I provide an example here. I apply an outbound acl on R1 to prevent telnet traffic to R2.
ip access-list extended 100
deny tcp any any eq telnet
permit ip any any
int fa0/0
ip access-group 100 out
At first telnet traffic originating from R1 is allowed - the outbound access list is ignored. I implement PBR to ensure locally generated traffic first passes through the loopback interface.
int lo0
ip address 1.1.1.1 255.255.255.255
route-map RICH
set interface lo0
ip local policy route-map RICH
Now telnet traffic destined for R2 is blocked as required!
Monday, October 6, 2008
Policy Based Routing
There are three steps to policy routing
1) Create an acl that matches the traffic that requires policy routing
2) Create a route map that specifies the next hop requirements
3) Apply a policy route map to the router inbound interface.
In this scenario the default route for traffic from R2 to R3 is over the frame relay cloud. The requirement here is to policy route ftp traffic originating from R1 1.1.1.1 to R3 3.3.3.3 over the point to point link between R2 and R3
Step 1 - create acl matching traffic
On R2
ip access-list extended 100
permit tcp host 1.1.1.1 host 3.3.3.3 eq ftp
permit tcp host 1.1.1.1 host 3.3.3.3 eq ftp-data
On R3
ip access-list extended 100
permit tcp host 3.3.3.3 eq ftp host 1.1.1.1
permit tcp host 3.3.3.3 eq ftp-data host 1.1.1.1
Step 2 - create route maps
On R2
route-map RICH
match ip address 100
set ip next-hop 11.0.0.3
On R3
route-map RICH
match ip address 100
set ip next-hop 11.0.0.2
Step 3 - apply pbr on incoming router interfaces
On R2 and R3
int fa0/0
ip policy route-map RICH
To verify the routing use the folowing commands
s ip policy
R3#s ip policy
Interface Route mapl
Fa0/0 RICH
To see the policy routing in action
debug ip policy
Sunday, October 5, 2008
BGP Summary Routes
To advertise a summary route within BGP the aggregate-address command can be used. The default is to advertise the summary alongside all the granular routes. The summary-only keyword can be used to change this behaviour, suppressing the granular route advertisement.
There may be lab requirements to vary how summary routes are advertised, for example consider the following scenario
i) advertise the summary 200.1.0.0/16 only to neighbor a
ii) do not advertise the summary 200.1.0.0/16 to neighbor b only the granular routes
This can be achieved as follows
1)
aggregate-address 200.1.0.0 255.255.0.0 summary-only
This will advertise the summary route only to ALL BGP neighbors
2)
ip prefix-list DENYAGG permit 200.1.0.0/16
route-map DENYAGG deny 10
match ip address prefix-list DENYAGG
route-map DENYAGG permit 20
ip prefix-list ALLOW permit 200.1.0.0/17 le 32
route-map ALLOW permit 10
match ip address prefix-list ALLOW
router bgp x
neigbhor b route-map DENYAGG
neighbor b unsuppress-map ALLOW
There are 2 parts to the above solution: first block the advertisement of the summary address and then second use the unsupress-map feature to permit advertisement of the required granular routes.
There may be lab requirements to vary how summary routes are advertised, for example consider the following scenario
i) advertise the summary 200.1.0.0/16 only to neighbor a
ii) do not advertise the summary 200.1.0.0/16 to neighbor b only the granular routes
This can be achieved as follows
1)
aggregate-address 200.1.0.0 255.255.0.0 summary-only
This will advertise the summary route only to ALL BGP neighbors
2)
ip prefix-list DENYAGG permit 200.1.0.0/16
route-map DENYAGG deny 10
match ip address prefix-list DENYAGG
route-map DENYAGG permit 20
ip prefix-list ALLOW permit 200.1.0.0/17 le 32
route-map ALLOW permit 10
match ip address prefix-list ALLOW
router bgp x
neigbhor b route-map DENYAGG
neighbor b unsuppress-map ALLOW
There are 2 parts to the above solution: first block the advertisement of the summary address and then second use the unsupress-map feature to permit advertisement of the required granular routes.
3550 and 3560 Macros
The tclsh tool is not available on the 3550 and 3560 switches. Instead macros can be used to perform a similar function.
To define the macro in global config
macro name richping
do ping 1.1.1.1
do ping 2.2.2.2
@
To execute the macro
macro global apply richping
To remove the macro when finished.
no macro name richping
To define the macro in global config
macro name richping
do ping 1.1.1.1
do ping 2.2.2.2
@
To execute the macro
macro global apply richping
To remove the macro when finished.
no macro name richping
Friday, October 3, 2008
RIP - route filtering options
3 ways to filter routes with an even 3rd octet: distribute-list, distance and offset-list
For the distribute-list command I create an acl that matches the routes I want to allow
ip access-list standard 1
permit 0.0.1.0 255.255.254.255
Distribute-list
router rip
distribute-list 1 in
Distance
router rip
distance 255 204.12.5.1 0.0.0.0 1
where 204.12.5.1 is the next hop of the route to be poisioned
For the offset-list commands I create an acl that matches routes I want to block
ip access-list standard 2
permit 0.0.0.0 255.255.254.255
Offset-list
router rip
offset-list 1 in 16
For the distribute-list command I create an acl that matches the routes I want to allow
ip access-list standard 1
permit 0.0.1.0 255.255.254.255
Distribute-list
router rip
distribute-list 1 in
Distance
router rip
distance 255 204.12.5.1 0.0.0.0 1
where 204.12.5.1 is the next hop of the route to be poisioned
For the offset-list commands I create an acl that matches routes I want to block
ip access-list standard 2
permit 0.0.0.0 255.255.254.255
Offset-list
router rip
offset-list 1 in 16
Thursday, October 2, 2008
backup interface
To enable an interface or link as a backup connection make use of the following 2 commands
backup interface x
backup delay a b
where a is the delay in seconds before activating the backup connection and b is the delay in seconds before the prinary interface is re-instated
This configuration is applied to the PRIMARY interface. Verification can be done via the show backup command.
R5#s backup
Primary Interface Secondary Interface Status
----------------- ------------------- ------
Serial2/0.513 Serial2/1 normal operation
Also use the show interface on the secondary/backup interface to display the standby status.
R5#s int s2/1
Serial2/1 is standby mode, line protocol is down
backup interface x
backup delay a b
where a is the delay in seconds before activating the backup connection and b is the delay in seconds before the prinary interface is re-instated
This configuration is applied to the PRIMARY interface. Verification can be done via the show backup command.
R5#s backup
Primary Interface Secondary Interface Status
----------------- ------------------- ------
Serial2/0.513 Serial2/1 normal operation
Also use the show interface on the secondary/backup interface to display the standby status.
R5#s int s2/1
Serial2/1 is standby mode, line protocol is down
EIGRP part 1 - security
If there is a shared LAN segment and there is a requirement to establish EIGRP adjencies over this but ONLY to specified neighbors, this initially represents a small problem. Of course EIGRP adjacencies are normally established via EIGRP multicast hellos to 224.0.0.10. This is effect allows any router on the LAN segment to join and become an EIGRP neighbor.
By making using of the EIGRP neighbor statement this behaviour can be eliminated. By applying a neighbor statement within EIGRP this stops the multicast hellos from exiting the associated interface. In this way any other hosts on the shared LAN segment are prevented from forming a neighbor adjacency adding a layer of security.
N.B. It is not necessary to apply the passive-interface command to the interface and in fact this will prevent all neighbor relationships forming out of the specified interface.
By making using of the EIGRP neighbor statement this behaviour can be eliminated. By applying a neighbor statement within EIGRP this stops the multicast hellos from exiting the associated interface. In this way any other hosts on the shared LAN segment are prevented from forming a neighbor adjacency adding a layer of security.
N.B. It is not necessary to apply the passive-interface command to the interface and in fact this will prevent all neighbor relationships forming out of the specified interface.
Wednesday, October 1, 2008
OSPF routing part IV - passive interface
In OSPF the passive interface command behaves a little differently from a distance vector routing protocol like RIP. When applied to an interface it will prevent an OSPF adjacency being formed and hence will not only prevent the sending of updates but receiving of updates also. This effectively creates a 'stub' network.
With RIP the passive-interface command will prevent the sending of updates but will still permit routing updates to be received. To achieve the same functionality within OSPF the command
'ip ospf database-filter all out' can be used.
With RIP the passive-interface command will prevent the sending of updates but will still permit routing updates to be received. To achieve the same functionality within OSPF the command
'ip ospf database-filter all out' can be used.
OSPF routing part III - Authentication
OSPF area 17 is exists between R1 fa0/0 and SW1 fa0/14. In this example i first introduce MD5 authentication and then plain text authentication.
To enable MD5 authentication
Router 1
int fa0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
SW 1
int fa0/14
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
To enable plain text authentication
Router 1
router ospf 1
area 17 authentication
int fa0/0
ip ospf authentication-key CISCO
SW1
router ospf 1
area 17 authentication
int fa0/14
ip ospf authentication-key CISCO
In both cases the verification is to check the neighbor adjanceny is established. Also execute a ‘show ip ospf interface’ to ensure that authentication is denoted as enabled and the authentication type is as expected.
To enable MD5 authentication
Router 1
int fa0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
SW 1
int fa0/14
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
To enable plain text authentication
Router 1
router ospf 1
area 17 authentication
int fa0/0
ip ospf authentication-key CISCO
SW1
router ospf 1
area 17 authentication
int fa0/14
ip ospf authentication-key CISCO
In both cases the verification is to check the neighbor adjanceny is established. Also execute a ‘show ip ospf interface’ to ensure that authentication is denoted as enabled and the authentication type is as expected.
The area x authentication command can be used either at the interface level or the global routing process level. If applied under the global routing process then, as expected, it applies to all interfaces in the specified area. This can be overidden by the interface level command, so allowing different authentication algorithms to co-exist in the same OSPF area.
Subscribe to:
Posts (Atom)