Saturday, May 29, 2010

INE Workbook Vol 1 IP Services

The first topic is proxy arp. Pretty simple logic overall, but there was one item I didn't know about - ip local-proxy-arp. This means that the router will run proxy-arp for the locally connected segment, which isn't usually the case because they are directly connected. INE showcased this by using 'switchport protected' on the switchports to show that the only way to get the devices on VL146 to talk, was to enable local proxy-arp on one of the nodes. Now pinging between the two protected ports is possible as the one in the middle will do proxy-arp and respond with it's own mac address.

With DHCP, configure the following to disable the BOOTP server and ignore requests.


R6(config)#ip dhcp bootp ignore 
R6(config)#no ip bootp server

To configure a host to use it's MAC address only as the dhcp client-id; issue the following:


R1(config)#int f0/0
R1(config-if)#ip address dhcp client-id fastEthernet 0/0

Verify with 'show dhcp lease' on the client. Remember, 01 is added to the client-id, so if your mac address was c200.05c5.0000, the client-id would be 01c2.0005.c500.00.

PPP and address assignment is still something I need to work on (including PPPoE). On the 'client' side, add 'ip address negotiated'. Optionally, you can also request the netmask and the dns addresses. With the DHCP On-Demand Pool, you can import IPCP parameters.


ip dhcp pool ODAP_POOL
   import all
   origin ipcp
interface Serial0/1
 ip address negotiated
 ip rip advertise 10
 encapsulation ppp
 no peer neighbor-route
 clock rate 64000
 ppp ipcp dns request
 ppp ipcp mask request

On the flip side, configure the other side like so...


interface Serial1/2
 ip address 155.1.13.3 255.255.255.0
 ip rip advertise 10
 encapsulation ppp
 no peer neighbor-route
 peer default ip address 155.1.13.1
 serial restart-delay 0
 clock rate 64000
 ppp ipcp dns 155.1.146.4 155.1.146.6
 ppp ipcp mask 255.255.255.0

A word of caution when doing IGP routing w/ PPP. You will obviously have a host route (unless you disable it) that will be injected into the IGP routing domain (depending on protocol and network advertisements). Also watch out since each end of the PPP link will be a /32 and the IGP neighbors will see updates that are NOT on the connected subnet.

DHCP proxy w/ PPP was interesting. On the client side, you do the same - 'ip address negotiated', again disabling the neighbor-route to preserve IGP functionality. On the 'server' side, just do a 'peer default ip address dhcp' instead of actually assigning an IP. Next, you need to create a default IP address pool using the proxy-client feature. Now tell the router where the DHCP server is located (instead of the helper-address). Everything should work, but the DHCP server will not have a route back to the host until IP is negotiated. So now you must add static routes to go around the host that will be assigned the IP address. Not really difficult, just new!


ip address-pool dhcp-proxy-client
ip dhcp-server 155.1.146.6
interface Serial1/3
 ip address 155.1.23.3 255.255.255.0
 ip rip advertise 10
 encapsulation ppp
 no peer neighbor-route
 peer default ip address dhcp
 serial restart-delay 0
 clock rate 64000


In summary, one host can proxy requests for another. Adding this to my list of things to revisit!

On to Option 82. To enable, you must first enable globally - 'ip dhcp relay information option'. Optionally you can set the subscriber-id per link.


interface FastEthernet0/0
 ip dhcp relay information option subscriber-id VLAN58
 ip address 155.1.58.5 255.255.255.0
 ip helper-address 150.1.6.6


On the DHCP server side, this is where 'classes' come into play. Create a class, select the relay agent information option (option 82) and then enter the HEX relay-information. How do you get the hex information? With a debug dump w/ DHCP matching ACL. Find the ASCII subscriber-id string (you did set that right?). The information option starts with decimal value 82 (hex 0x52), followed by the total option length (0x16). Following that are the suboptions. Whew. What a task...I really didn't think this would be that difficult.


ip dhcp pool VL58
   network 155.1.58.0 255.255.255.0
   default-router 155.1.58.5 
   class TEST
      address range 155.1.58.8 155.1.58.8
ip dhcp class TEST
   relay agent information
      relay-information hex 020c020a00009b013a05000000000606564c414e3538

Something pretty easy - you can have DHCP update ARP. And then you can only allow authorized arp entries thus disabling dynamic ARP.


ip dhcp pool VL146
   network 155.1.146.0 255.255.255.0
   default-router 155.1.146.4 155.1.146.6
   dns-server 155.1.146.4 155.1.146.6 
   lease 0 12
   update arp
ip dhcp pool R1
   host 155.1.146.11 255.255.255.0
   client-identifier 01c2.0005.c500.00
   update arp
interface FastEthernet0/0.146
 encapsulation dot1Q 146
 ip address 155.1.146.6 255.255.255.0
 ip rip advertise 10
 arp authorized


If not all hosts are DHCP, you need to statically add their ARP entries; 'arp 155.1.146.4 1234.5678.90AB.CDEF'.


IP SLA, VRRP and HSRP are all pretty simple. GLBP can be slightly more difficult, only because of the load-balancing aspect to it. The weighting always trips me up, but to do a 2:1 ratio, just do the following:



R4(config-if)#glbp 146 weighting 20
R4(config-if)#glbp 146 load-balancing weighted


R6(config-subif)#glbp 146 weighting 10
R6(config-subif)#glbp 146 load-balancing weighted

With the above configuration, you will achieve the 2:1 ratio since R4 has a higher weighting. Weighting does not affect the round-robin method or the host-dependent method.


IRDP is pretty easy, I just always forget the client command 'ip gdp irdp'. Moving on to NAT...


The NAT no-alias commands removes the proxy-arp ability from the NAT entries. When you do NAT, the router making the translations will proxy-arp for the NAT'd addresses. You can verify with the 'show ip alias' command. Adding the no-alias option means the proxy-arp will not happen, and you will not be able to ping that static TCP PAT address.


Overlapping addressing w/ NAT was interesting. The requirement said that only one host would complete NAT. So R1 was configured like so...



interface Loopback1
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
ip route 11.0.0.0 255.255.255.0 Null0
ip route 22.0.0.0 255.255.255.0 Serial0/1
!
ip nat pool NET22 22.0.0.1 22.0.0.254 prefix-length 24
ip nat inside source static network 10.0.0.0 11.0.0.0 /24
ip nat outside source list NET10 pool NET22

The static route to Null0 was required because NAT will first do a route table lookup before performing any translations. We simply translate 10.x.x.x to 11.x.x.x, and on the incoming we translate 10.x.x.x to 22.x.x.x so that R1 'hides' it's 10.x.x.x network (that overlaps with R2). So packets appear to come in with a dest of 11.0.0.1 and a source of 22.0.0.x.

On to TCP Load balancing. This requires the ip nat inside destination command. Pretty easy to understand - I can just never construct the proper NAT entries for some reason. I guess I get confused by items such as 'ip nat source' and 'ip nat inside|outside source'.


interface FastEthernet0/0
 ip address 155.1.58.5 255.255.255.0
 ip nat outside
interface Serial0/0
 ip address 155.1.0.5 255.255.255.0
 ip nat inside
ip nat pool ROTARY prefix-length 24 type rotary
 address 155.1.0.1 155.1.0.1
 address 155.1.0.2 155.1.0.2
 address 155.1.0.3 155.1.0.3
ip nat inside destination list LOAD_BALANCE pool ROTARY
ip access-list extended LOAD_BALANCE
 permit tcp any host 155.1.58.55 eq telnet


So now connecting to telnet via 155.1.58.55 will load-balance between R1, R2 and R3.

When doing stateful nat, without HSRP - configure the routers like so...



R4

ip nat Stateful id 1
  backup 155.1.146.4
   peer 155.1.146.6
   mapping-id 1
ip nat pool TST 155.1.254.1 155.1.254.254 prefix-length 24
ip nat inside source list Net155 pool TST mapping-id 1

R6


ip nat Stateful id 2
  primary 155.1.146.6
   peer 155.1.146.4
   mapping-id 1
ip nat pool TST 155.1.254.1 155.1.254.254 prefix-length 24
ip nat inside source list Net155 pool TST mapping-id 1

I always get confused between primary, backup and peer. Should each one have a primary and backup entry? Should they both include peer statements? The above configuration is correct.

I finally found the use for the NAT Virtual Interface.


R5(config)# int s0/0
R5(config-if)#ip nat enable 
R5(config-if)#int s0/1
R5(config-if)#ip nat en
R5(config-if)#int f0/0
R5(config-if)#ip nat en
R5(config-if)#ip access-list st VLAN8
R5(config-std-nacl)#permit 155.1.8.0 0.0.0.255
R5(config-std-nacl)#exi
R5(config)#ip nat pool NVI_POOL 155.1.188.1 155.1.188.254 prefix-length 24 
  accounting  Specify the accounting
  add-route   Add special route to Virtual Interface
  arp-ping    WLAN ARP Ping
  type        Specify the pool type
  


R5(config)#$ NVI_POOL 155.1.188.1 155.1.188.254 prefix-length 24 add-route 
R5(config)#ip nat source list VLAN8 pool NVI_POOL
R5(config)#router rip
R5(config-router)#redistribute static metric 1

The NAT direction is always inside for NVI NAT. A routing looking is performed before the translation. After the routing decision is made, the packet source is translated and then forwarded. NVI eliminates the need for a separate static route but you still need to advertise the static into the routing domain. We also finally have a use for the 'ip nat source' command.

Extendable static NAT allows you to configure multiple static mappings for the same local or global IP address.

Well, that is it for NAT. I will say I understand NAT a lot better, and I am able to craft the solutions to the majority of the scenarios. There were some slightly tricky scenarios, but nothing really all the difficult. Moving on to the remainder of IP Services....

Ahh!!! I finally found it! How to figure out the TOS from Precedence...multiply it by 32! Precedence of 3 would be TOS 96. It's easy to turn on IP Accounting for precedence packets...'ip accounting precedence' but the regular 'show ip accounting' does not show anything. Instead you need to 'show interface s0/1 precedence'.


R6(config-if)#do sh int s0/0 prece
Serial0/0 
  Input
    Precedence 6:  34 packets, 2436 bytes
  Output
    Precedence 0:  10 packets, 1040 bytes
    Precedence 3:  5 packets, 520 bytes
    Precedence 6:  38 packets, 14457 bytes


Display mac-accounting with 'sho interface fa0/0 mac-accounting'. Enable it on the interface with 'ip accounting mac in|out'.

By default, IOS routers will forward UDP packets only for the following protocols:

  • TACACS(not TACACS+)
  • TFTP
  • BOOTP
  • TIME
  • NETBIO NS and DG
  • DNS
Enable or disable with the 'ip forward-protocol udp [protocol]'. The command 'ip directed broadcast' will forward broadcast to 255.255.255.255. This can be changed with the 'ip broadcast-address x.x.x.x'.

With WCCP, the direction of the redirection indicated which traffic flows are redirected. You can exclude interface from redirection with the 'ip wccp redirect exclude in|out' interface command. You can also enable outbound ACL checks with 'ip wccp outbound-acl-check'. 

For WCCP version 2 to support multicast group membership, you must enable 'ip wccp [serviceID] group-listen' on the interface.

Server Load balancing. What IOS version is this supported on? Again, across all my real and dynamips routers, I don't have the 'ip slb' command. Here are the pertinent configs for directed mode. Pretty self-explanatory.

ip slb serverfarm SERVERS
     nat server (nat to the virtual IP and real IP)
     predictor roundrobin (round-robin)
     real 150.1.1.1 (IP address of real server)
          reassign 2 (reassign to another server after x failed syn packets)
          faildetect numconns 3 (detect a failed server after x number of connections)
          retry 120 (retry the server after x seconds
          weight 1 (round-robin weighting)
          inservice (is active)
          exit
     real 150.1.2.2
          reassign 2
          faildetect numconns 3
          retry 120
          weight 2
          inservice
          exit
     real 150.1.3.3
          reassign 2
          faildetect numconns 3
          retry 120
          weight 3
          inservice
          end
!
ip slb vserver VSERVER
     virtual 155.1.58.55 tcp telnet
     serverfarm SERVERFARM
     inservice
     exit

If anyone has any experience with any type of loadbalancers (cisco CSS, linux heartbeat, etc). These command should be very familiar. Verify with 'show ip slb vservers|serverfarns|reals|conns|stats'

SLB dispatched mode uses layer 2 mods only to forward packets to the real servers and does not do any layer 3 mods. The real servers are each assigned a unique IP address and share an overlapping anycast address to accept packets to the virtual server. In dispatched mode, SLB implements a load-balancing algorithm. The weight setting actually specifies the # of connections a server can accept before moving to another server in the farm.

'ip nbar custom' and 'ip nbar port-map' are the keys to creating custom classifications, including low-level byte string match.

You can modify netflow sampling to something say, one in every 10 packets using a policy.

R6(config)#flow-sampler-map SAMPLER
R6(config-sampler)#mode random one-out-of 10
R6(config-sampler)#policy-map NETFLOW_MAP
R6(config-pmap)#class class-default
R6(config-pmap-c)#netflow-sampler SAMPLER
R6(config-pmap-c)#int s0/0
R6(config-if)#no ip flow egress 
R6(config-if)#service-policy output NETFLOW_MAP

The interface-level netflow configuration will override the MQC configuration so it must be disabled. 

I didn't know IOS could act as an authoritive DNS server. If you know how to run a DNS server, this should be pretty easy. 

ip host cisco.com ns 155.1.146.4
ip host cisco.com ns 155.1.146.6
ip host R4.cisco.com 150.1.4.4 155.1.146.4 155.1.45.4 204.12.1.4 155.1.0.4
ip host R6.cisco.com 150.1.6.6 155.1.146.6 155.1.67.6 54.1.1.6
ip dns server
ip dns primary cisco.com soa ns.cisco.com ccie.cisco.com 21600 900 7776000 86400

The following will dampen the connection to BB1 for 30 seconds after a reload. 

R6(config-if)#dampening 30 1000 2000 60 restart 2000

The half time 30 seconds. The reuse penalty is 1000. The suppress penalty is 2000. The max dampen time is 60 seconds. With the 'restart' command, we can configure the penalty value following a restart; in this case - 2000. Since the half-life is 30 seconds, it will be down to 1000 after 30 seconds, which is the reuse penalty value.

Whew. Nice section, as usual I picked up on a few things, reinforced some others. Things are going well. Hopefully I can tackle MPLS and Bridging/Switching next week. I'm taking a day off tomorrow and probably Monday - I need it!

Wednesday, May 26, 2010

INE Workbook Vol 1 System Management

The command 'logging origin-id string ' will send syslog messages with the configured name as the origin. The 'service sequence-numbers' includes sequence numbers in syslog messages. This helps prevent against tampering with stored syslog information. 'logging count' allows to count all 'notification' and above system messages to provide statistics for quick analysis of the system history. Timestamps can be configured separately for logging and debugging messages (service timestamp [debug|log] [uptime|datetime] (msec year ...).

With archive logging, you can show the output that's suitable for direct application..

sh archive log config all provisioning

You can also show the differences (+/-) between two configs, and you can show the incremental, which will again output in a direct application format.


SW1#sh archive config differences flash:initial.cfg system:running-config
Contextual Config Diffs:
+archive
 +log config
  +logging enable
 +path tftp:155.1.58.100/sw1-config
 +rollback filter adaptive
 +write-memory
 +time-period 1440
interface Vlan67
 +ip address 155.1.76.7 255.255.255.0
 +shutdown
interface Vlan67
 -ip address 155.1.67.7 255.255.255.0


SW1#sh archive config incremental-diffs flash:initial.cfg
!List of Commands:
interface Vlan67
 ip address 155.1.67.7 255.255.255.0
end


Very cool. With the right configuration, you could get by without Ciscoworks/rancid in a small environment.You can even do a 'configure replace' to rollback changes.


Conditional debugging. Another feature I had no idea existed. You can set a debug condition for an interface, ip, username, mac, vlan, etc. Very cool. Be careful, undebug all does not remove the conditions. You can set most TCP client parameters with the 'ip tcp' configuration. The exceptions are 'service telnet-zeroidle' - idle outgoing telnet sessions should signal the remote host to pause output. The busy message 'busy-message # message # does just that - sets the busy message when the configured host is unavailable.


On the flip side, configure 'refuse-message # Sorry, the line is already in use #' to set the busy message for the VTY line directly. You can set the session limit for the console line; 'session-limit 1'. The vacant message will display the configured output when the line is idle. 


line con 0
vacant-message # Welcome to IOS#


To allow SNMP management stations to reload the device, you must enable the RW community string in addition to 'snmp-server system-shutdown' command. You can restrict access to certain MIB values using views. Simply create the view, and attach to the community string. Here we have created a view for the cisco subtree for the community PUBLIC.



snmp-server view ROVIEW cisco included
snmp-server community CISCO RW SNMP-HOSTS
snmp-server community PUBLIC view ROVIEW RO

To enable informs for a particular hosts, issue the following:

snmp-server host 155.1.146.100 inform version 2c CISCO




Traps can be configured globally or per-host, with some exceptions like snmp link up and down can only be enabled globally. The host specific configuration overrides the global snmp config. It is required to configure the 'snmp-server enable traps' and the 'snmp-server host' commands in order to send notifications.


You can set CPU and memory thresholds using the 'process cpu' and 'memory' IOS commands. When doing so, you may be required to also enable 'snmp-server enable traps cpu threshold'



memory reserve critical 512
memory free low-watermark processor 1000
process cpu threshold type total rising 50 interval 5

On to SNMPv3. For some reason, I thought this was difficult but in reality, it is not. You create groups ( attach read/write views) and add users to that group. You can do the same thing for trap hosts, NMS stations, by specifying the v3 username instead of the v1/v2c community. Great Article from Cisco on SNMPv3.

To send all debugging and high priority level messages to SNMP host, issue the following:


logging history size 100
logging history debugging
snmp-server enable traps syslog
snmp-server host 155.1.146.100 CISCO


Syslog first sends the logs to a history buffer, and then the SNMP agent replicates the messages as SNMP traps.

Now on to RMON. I have no major issues here except for absolute and delta sampling. Absolute is used for variables that increase or decrease over time and have an upper or lower bound when a log should be generated. Delta is used for variables that either constantly increase or constantly decrease. Absolute samplings would be interface queue depth, cpu, memory. Delta would be interface errors, input packets, output bytes. Remember that anytime you call a particular interface, you need to enable 'snmp-server ifindex persist'.


RSH/RCP on the IOS? Pretty cool! RSH does not use passwords, but instead an entry in the local .rhosts table. The table maps IP and username to local username and privilege level. So when asked for local username, typically you would just use the hostname.


R6:

ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-host R6 150.1.1.1 R1 enable
ip rcmd remote-host RCP 150.1.1.1 R1 enable


R1:

R1#rsh 150.1.6.6 /user R6 show run int s0/0


Building configuration...


Current configuration : 349 bytes
!
interface Serial0/0
 ip address 54.1.1.6 255.255.255.0
 ip hello-interval eigrp 10 5
 ip hold-time eigrp 10 15
 ip authentication mode eigrp 10 md5
 ip authentication key-chain eigrp 10 MD5_KEYS
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 54.1.1.254 101 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
end


R1#sh run | i ip rcmd
ip rcmd remote-username RCP
ip rcmd source-interface Loopback0


Now NTP. The part that always trips me up is NTP authentication. I finally get it. 'ntp authentication-key' simply creates the key on both masters and clients. Issue 'ntp authenticate' if you will be authenticating your time sources (ntp server, ntp broadcast/multicast, ntp peer commands). Now attach the key to the pertinent server/broadcast/multicast client statements (ntp server 1.1.1.1 key 1) and say these are trusted keys (ntp trusted-key 1). Boom! Everything should work. Verify with 'show ntp association detail'. Remember, key numbers must be the same on both master and clients.


ntp authentication-key 4 md5 062526126F615D 7
ntp authentication-key 6 md5 062526126F615F 7
ntp authentication-key 58 md5 0327723825207414 7
ntp authenticate
ntp trusted-key 4
ntp trusted-key 6
ntp clock-period 17179895
ntp source Loopback0
ntp server 150.1.4.4 key 4 prefer
ntp server 150.1.6.6 key 6


R5(config-if)#do sh ntp ass det
150.1.4.4 configured, authenticated, our_master, sane, valid, stratum 5
ref ID 127.127.7.1, time C02948F5.1BA2EA04 (00:25:25.107 UTC Fri Mar 1 2002)
...trim


150.1.6.6 configured, authenticated, insane, invalid, stratum 5
ref ID 127.127.7.1, time C0294872.9FBBF625 (00:23:14.623 UTC Fri Mar 1 2002)
...trim



Autoinstall over ethernet. The only difficult was finding out the client-id. In short, you need to enable a pool, let the client get an address, issue a 'show ip dhcp lease' to find the client ID, and then enter the client id (prepending 00 to the hex ID) in the dhcp pool. From there, you will need to run one of your routers as a DNS server, so the autoconfig host can find it's hostname as well as the hostname of the tftp server. 


Autoinstall over frame-relay was not drastically different. Instead of DHCP, the client will probe the hub router for an IP. The hub will look up the map statement for that particular DLCI and hand-out the IP address configured for that map statement. From there the client will broadcast tftp requests out all available DLCIs. The staging router should either be the tftp server, or use 'ip helper-address' pointing to the actual tftp server. 


You can also use RARP. Simply add a static arp entry to the RARP server, and set the rarp server address under the interface connected to the autoinstall client. Same tftp rules apply - the rarp server should be the tftp server itself, or use 'ip helper-address' pointing to actual tftp server.


Next came menus. The only two things I really need to remember here are 1) menu-exit is the command to exit from the menu and return to the shell; 2) username OPERTOR autocommand menu OPERATOR will automatically load the menu OPERATOR upon login for the user OPERATOR.


Banners can be confusing. Which banner performs what function? The MOTD banner will be shown to all connecting users. The login banner will be displayed before the username prompt. The exec banner is shown before the shell prompt and the incoming banner is used for reverse telnet connections. Special variables such as $(line) and $(hostname) can be used to create dynamic notifications. Also, you can disable banners per line.


line con 0
no motd-banner
no exec-banner


KRON was pretty simple except I didn't know you could do this...


sh running-config | redirect tftp:155.1.146.0/r4-conf

Ah! That explains a lot. So issue the following to configure KRON to save the running config to TFTP @ 155.1.146.100 daily at 8:00.


kron occurrence SAVE_DAILY at 8:00 recurring
 policy-list SAVE_CONFIG
kron policy-list SAVE_CONFIG
 cli show running-config | redirect tftp://155.1.146.100/r3-config

And now...EEM scripting, which I hate - simply indicated by the keyword 'scripting'. I'm no slouch when it comes to basic perl programming, grep statements, regex, etc but I am NOT a programmer. If I wanted to be a programmer, I wouldn't be worried about the damn CCIE....anyway, moving on....

The core of EEM is the EEM server that sits between the event detectors and event subscribers. There is a fixed amount of event detectors that post an event when a condition is met. They include:



  1. CLI event detector - detects commands typed in CLI based on regex matching.
  2. Syslog event detector - responds to syslog strings, allowing for matching on regex.
  3. Interface Counter - responds to various interface counters that cross a threshold setting.
  4. Counter - responds to the change of value of a generic counter.
  5. SNMP - monitors SNMP objects and post an event upon the condition being met.
  6. None - This is a special case. Called when a user issues 'event manager run' to execute a named EEM script/applet.
  7. Watchdog - generates periodic timer events and allows the EEM script to be run at repeating intervals.
Event subscribers on the other hand, are defined and registered with the EEM server as applets or scripts. Applets are a simple program written using a very basic set of CLI commands that start with the 'action' keyword. Scripts are special TCL scripts written to hand the EEM events. Applets themselves are described as easy to write, yet powerful enough to perform many functions including CLI commands, e-mail generation, snmp/syslog message generation and implementing basic program logic. TCL is a full scripting language and requires more skills to develop. It would appear that the lab will focus on applets only - which is a good thing!

Every applet has a name and a detector condition defined to trigger said applet. The applet may access global variables, defined using the 'event manager environment' command or parameters passed to them by the detector. Every event detector has pre-defined variables. Documentation on writing EEM applets, which I will be reading later. You can list variables for a detector by using 'show event manager detector detailed' command. 

The first scenario request that you fire an action if the interface Serial0/0 rxload goes above 60%. Interface load is gauged by 1 - 255, so 60% is 153. Here is the event:

event interface name Serial0/0 parameter rxload entry-op gt entry-val 153 entry-val-is-increment false poll-interval 60

Nothing really that difficult. We are checking a interface, named Serial0/0, checking for rxload that is greater than 153 and we are not incrementing. The actions are really simple and should be self explanatory.

event manager applet INTERFACE_LOAD 
 event interface name "Serial0/0" parameter rxload entry-val 153 entry-op gt entry-val-is-increment false poll-interval 60
 action 0.0 cli command "enable"
 action 1.0 cli command "configure terminal"
 action 2.0 cli command "interface Serial0/0"
 action 3.0 cli command "ip access-group CRITICAL_TRAFFIC in"
 action 4.0 mail server "155.1.146.100" to "noc@INE.com" from "r5@INE.com" subject "Interface Alert" body "Interface Serial0/0 over 60% RX load"

Next up is syslog events. The tasks asks that if someone shutdown interface Serial0/0, to un-shut the interface and send an e-mail. At first I thought this would be a 'cli event' but I couldn't construct what I needed. Looking at the solution, you create a syslog event like so. Also notice the $_cli_result" variable used in the e-mail generation. NOW I know how to do that......

event manager applet INTERFACE_SHUTDOWN 
 event syslog pattern "Interface Serial0/0.*changed.*down"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "interface Serial 0/0"
 action 4.0 cli command "no shutdown"
 action 5.0 cli command "end"
 action 6.0 cli command "show users"
 action 7.0 mail server "155.1.146.100" to "admin@ine.com" from "r5@ine.com" subject "Interface Shutdown Alert" body "Interface Serial 0/0 unshut, current users $_cli_result"

Looking at that now, not really that difficult. Just a little regex matching...moving on to CLI events....and the familiar but misunderstood sync option...

When the applet event is sync, the EEM server will hold the matched CLI command execution until the script terminates. The script should return an exit value in the variable $_exit_status and this will determine whether the triggered command will run (status 1) or not (status 0). Async will let the CLI command execute and the event will be posted after that. The script cannot affect the command execution. Async CLI events require a set of additional parameters such as # of occurances and the time window for occurances. You can also use the puts action which allows displaying arbitrary text on the console, provided the script is async. 

So if you need to modify the output, such as a show run, you need to set sync to yes.

event manager applet SHOW_RUN
   event cli pattern "show run" sync yes
   action 1.0 cli command "enable"
   action 2.0 cli command "show run | exclude username"
   action 3.0 puts $_cli_result
   action 4.0 set $_exit_status 0

I wish I could test this, but my IOS won't let me use the action 'puts'! Additionally, some of the sytax such as event tags is not there. 12.4(15)10T on C3725. Go figure. Anyway, to explain the above - we are triggering the event based on an entered cli command; show run. Since we set sync to yes, we can modify the output - excluding usernames. The 'puts' action displays the modified output to the user. In the end, we need to set $_exit_status to 0 so that the original command 'show run' does not run. Hope that helps someone out there.

Now periodic scheduling. Pretty easy - instead of matching an event on CLI, syslog, etc - you match on a watchdog timer value and set appropriate actions. Notice the syslog action below.

event manager applet SHOW_RUN_EVERY_5min 
 event timer watchdog time 300
 action 1.0 cli command "enable"
 action 2.0 cli command "write term"
 action 3.0 syslog msg "Configuration Saved"
 action 4.0 mail server "155.1.146.100" to "noc@ine.com" from "r5@ine.com" subject "Configuration" body " $_cli_result"

Now on to what INE calls "Advanced Features". We need to write an applet that clears interface counters every 3 minutes, excluding Serial interfaces and account for any future interfaces added to the router. I am guessing a watchdog timer and doing some SNMP ifindex stuff...

Yay. Loops and conditional constructs. A few interesting actions...

  1. 'info type interface-name' pulls out the list of interface names in the system matching a regex
  2. 'regexp PATTERN STRING' performs regex match against a string. If there is a match, the variable $_regexp_result is set to "1". This commands takes extra arguments for extracting the matched substrings. 
  3. 'continue' - starts another interation
  4. 'cli command COMMAND patter PATTERN' - allows the CLI commands that await a users response. The patter is the regex matching the command prompt.
Again, I couldn't test! I don't have a 'interface-names' info type option. Argh! I've also tried my 3640/12.4(16a) and my 2621xm/12.4(15)T13. Finally found a 2851 w/ 12.4(24)T3 that works. Are these ISR only commands?

Well, here is the config.

event manager applet CLEAR_INTERFACE
 event none
 action 1.0 info type interface-names regexp "Fa|Se"
 action 2.0 foreach _iface "$_info_interface_names"
 action 3.0  regexp ".*(Serial).*" "$_iface"
 action 4.0  if $_regexp_result eq 1
 action 5.0   continue
 action 6.0  else
 action 7.0   cli command "enable"
 action 8.0   cli command "clear counters $_iface" pattern "confirm"
 action 9.0   cli command "y"
 action 9.1  end
 action 9.2 end

To be honest, I'm not sure I could re-construct this in the lab. I'm just not a very good programmer and when you don't do things like foreach/loop logic every day, it is easy to forget. My programming days are WAY behind me. 

The info type action is pretty simple. Get the interface names, and extract those with Fa|Se. Attach the result to the _iface variable. For each result, if it's a serial interface, continue to the next one. If it is not a serial, clear the counters. I can look at that and make sense of it, but to construct this in a lab would be difficult. I think this is possibly the hardest EEM applet you could expect to see on the lab, and I would put those chances very low.

Well, that is it for system management. This section was not too bad, and I now feel I have a better understanding of things such as EEM, banners and NTP. Next is IP services, MPLS and then finally Switching. I am hoping by June 4th to be done with all of Volume 1, and then start on Volume 2 full labs while mixing in Troubleshooting labs and re-visiting certain Volume 1 topics. That will give my five solid weeks of doing full labs and troubleshooting and maybe a mock lab. Feeling pretty good on my progress.

Monday, May 24, 2010

INE Workbook Vol 1 Security

You can set the prompts and banners through the aaa process...


aaa authentication banner ^CWelcome Bitches!^C
aaa authentication fail-message ^C Piss off fucker - your not who you say you are!^C
aaa authentication password-prompt "Please enter your password fucker:"
aaa authentication username-prompt "Who the fuck are you:"


IOS by default do not authorize console sessions, where as Catalyst IOS always authorizes the exec shell, even the console line.


Inbound IOS UDP traceroute uses port range 33434 - 33474. Path MTU discovery uses ICMP packet-too-big. You can use 'show ip port-map' to locate common TCP/UDP port-numbers.


Reflexive access-lists used to trip me up before. I now understand them, but still have some trouble putting them together. In short, you just add a reflect [ACL_NAME] to the end of your outbound permit statements. Then on your inbound ACL, simply do a evaluate [ACL_NAME] statement. Hopefully, this will finally commit reflexive ACLs to my ROM....also, if you use reflexive ACLs, you may need to account for local traffic by either statically permitting the traffic in the inbound ACL or use local policy routing to divert the local traffic across the loopback interface and make it re-enter the router. 


Ahhh....dynamic access lists. How I hate you so. First, enable absolute timeout extension.


access-list dynamic-extended


Now create an inbound ACL permitting pertinent traffic and specifying the dynamic access-list.


ip access-list extended 100
remark == Permit Telnet ==
permit tcp any any eq telnet
remark == Permit rotary line 7001 ==
permit tcp any any eq 7001
remark == Permit RIP ==
permit udp any any eq 520
remark == Dynamic ACL for WWW ==
dynamic ACCESS timeout 15 permit tcp any any eq 80
deny ip any any log


Apply the access-list.


interface FastE0/0.67
ip access-g 100 in

Now tie the username/password to the autocommand.

username ENABLE passw CISCO
username ENABLE autocommand access-enable host timeout 5

Above, the autocommand access-enable command will add the authenticated user to the dynamic access-list. The 'access-enable host timeout 5' command is hidden from the IOS parser, so commit this to memory. Without the 'host' portion, the dynamic entry will have a simply 'any any' ACL entry. Now to configure the VTY lines...

line vty 0 3
login local
line vty 0 4
rotary 1
password CISCO
login
autocommand access-enable timeout 5

Now from the above VTY config, if a user logs in with the ENABLE username on line 0 - 3, or connects via TCP 7001 with line password CISCO, they will be added to the dynamic access-list and permitted outbound WWW connections. This is really easy to understand, but hard to remember and re-assemble. In short, if you can remember the 'autocommand access-enable host timeout x' command, you can complete the dynamic access-lists. You can manually clear the dynamic entries by issuing a 'clear access-template 100 ...' command.

Packet drop with PBR is achieved by using 'set interface null0' command.

uRPF can be enabled in strict or loose mode. With strict mode (ip verify unicast source reachable-via rx) the router applies the uRPF check to the source IP address of incoming packets to ensure the source IP address matches an explicit IP route in the routing table and the next hop for this entry should point out the interface the packet was received from.

Loose mode is commonly used with more than one ISP uplink and use asymmetric routing. Loose mode (ip verify unicast source reachable-via any) checks that it has an IP route matching the source address of the packet. It does not matter whether the next hop for this route points out the receiving interface or not. uRPF can also call an access-list for packets violating the uRPF condition. You could permit exceptions, or can use the 'deny ip any any log' to log packets denied.

Access-list logged packets are process switched. To limit impact on CPU, you may want to rate-limit the amount of process-switched packets using 'ip access-list logging interval x'.

You can enable inspection of router-generated UDP traffic using the 'ip inspect name Firewall udp router-traffic' command. Traffic inspected with CBAC will be allowed through the firewall, but will be further inspected for other details. CBAC uses the ip port-map command and you can specify a host specific port map (ip port-map ftp port 80 list 98) will inspect FTP sessions to port 80 with hosts permitted by access-list 98. When the number of connections across the firewall exceeds 4000, you may want to adjust the default hash-table size to match approximately half of the maximum connections count. With 5000 sessions, the optimal hash table size would be 2048 buckets.

On to port security. The only thing that really trips me up is protect/restrict and what each mode does. One drops the offending traffic, the other drops the offending traffic and logs to syslog. How do I remember this? Think of port-security as a bouncer at a club. If the bouncer is protecting the entrance, he doesn't need to know who tries to enter, he just needs to protect. If he needs to restrict the entrance, he needs to know who is who and thus log that information. Maybe that will help someone else, or maybe I'm just "special"...moving on....with a trunk port, we can specify a total amount per physical port, as well as total amount per vlan...

switchport port-security maximum 1 vlan 146
switchport port-security maximum 1 vlan 67
switchport port-security maximum 2


You can also limit based on 'access' and 'voice' vlans.


switchport port-security maximum 1 vlan access
switchport port-security maximum 2 vlan voice


With DHCP snooping, you need to trust the DHCP servers, as well as the trunk ports to DHCP server.You can disable/ignore Option 82 by three methods.
1)Instruct IOS DHCP server to accept DHCP messages with a zero 'giaddr' using the global 'ip dhcp relay information trust-all' or the interface 'ip dhcp relay information trusted'.
2)Configure the DHCP snooping feature to not insert Option82 using 'no ip dhcp-snooping information option'. 
3)Trust the port where you receive the original DHCP message. 


By default, the switch does not accept DHCP packets with a non-zero 'giaddr' on untrusted ports. In addition, it does not accept DHCP packets with Option 82 on untrusted ports. This can be changed with the 'ip dhcp snooping information allow-untrusted'.


With dynamic ARP inspection, the DHCP bindings database is used by default. For static hosts, you need to configure an ARP access-lists and apply the filter.


SW-1(config)#arp access-list VLAN146

SW-1(config-arp-nacl)#permit ip host 155.1.146.1 mac host 000f.3454.a66 log 
SW-1(config-arp-nacl)#permit ip host 155.1.146.4 mac host 0011.9315.78e0 log
SW-1(config)#ip arp inspection filter VLAN146 vlan 146

If there are no permit matches, and there is no explicit 'deny ip any mac any' statement, the feature also checks the DHCP bindings database. If there is a explicit deny, or the access-list has been applied with the 'static' keyword, then ARP inspection does not consult the DHCP snooping database.

To log packets matching the ARP ACL, issue an 'ip arp inspection vlan 146 logging acl-match [matchlog|none}' to enable/disable logging of ARP packets.

With catalyst switches, you can apply both ingress MAC and IP ACLs. You cannot filter IP traffic based on MAC address unless you utilize port-security. Man, do I really have to remember Ethertypes? ARP is 0x806.

Here is something I didn't know. You can attach an access-class to a username. So if you are told that a user can only connect to a specified router, issue the following..


R2(config)#access-list 100 permit ip any host 150.1.1.1
R2(config)#access-list 100 permit ip any host 155.1.146.1
R2(config)#access-list 100 permit ip any host 155.1.0.1  
R2(config)#access-list 100 permit ip any host 155.1.13.1
R2(config)#access-list 100 deny tcp any any eq 80 log
R2(config)#username TELNET access-class 100 

Now when user TELNET logs in to R1, he can only access R1, and any attempts to reach WWW servers will be logged. Pretty neat and simple. Just something I didn't know could be done.

Role-based CLI enhances the command authorization model and instead of using privilege levels, you define user roles. A view may be associated with a user utilizing the local database or special external AAA attribute. You must enable 'aaa new-model' for role-based access-control to work. The 'root' view always exists. You will need to switch to the root view to be able to create other views. Simply issue a 'enable view' and enter the enable password. Create a super-view (includes other views) using 'parser view SUPER super' view and attach the child views. Here is a sample...


parser view INTERFACE1
 secret 5 $1$ROi5$kTuvXkskL1UlhC8EZ0BwG/
 commands interface include all ip
 commands configure include interface
 commands exec include configure terminal
 commands exec include configure
 commands configure include interface FastEthernet0/0



R4#enable view INTERFACE1
Password: 


R4#
*Mar  1 00:13:20.031: %PARSER-6-VIEW_SWITCH: successfully set to view 'INTERFACE1'.
R4#?
Exec commands:
  configure   Enter configuration mode
  credential  load the credential info from file system
  enable      Turn on privileged commands
  exit        Exit from the EXEC
  show        Show running system information


R4#configure t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#?
Configure commands:
  do         To run exec commands in config mode
  exit       Exit from configure mode
  interface  Select an interface to configure


R4(config)#


Moving on to Router IP traffic Export. This is something new for me. It is a feature to monitor IP traffic received or sent on any WAN or LAN interface. This allows monitoring of IP traffic on non-shared interfaces such as Frame-Relay. Really, it's pretty easy and self-explanatory.



ip traffic-export profile EXPORT
  interface FastEthernet0/0
  bidirectional
  incoming access-list Filter
  outgoing access-list Filter
  mac-address c203.05b0.0001

You can set the mode, inbound or bidir. You can also filter a subset of the incoming/outgoing traffic. Then just specify where you are exporting the traffic to (connected interface and MAC) and you are done!

Control plane policing is pretty easy if you have already done MQC policing. Match with ACLs/class-maps, police rate x pps through the policy map, and apply service policy through 'control plane' configuration mode.

Now Control Plane Protection is a whole different beast. In short, the control plane has three sub-interfaces - host, transit and cef exception. Using CPPr, you can drop, filter, police and set queue limits. This is a pretty complicated beast. You can use a class-map type port-filter to match closed ports. You can also create a class-map type queue-threshold to set queue limits. Then when you apply the service policy, you have to specify the type as well. Wow. Will need to do some additional reading on this if I have time.

Next up - Flexible Packet matching. Holy crap.....more reading, lots to learn here...moving on.

And now, zone based firewalls. This one is pretty easy to understand, you just have to put all the pieces together.A short list of steps include:


  1. Define access-lists for traffic scopes
  2. Defines class-maps(match protocol and optionally ACL)
  3. Define policy-maps
  4. Configure zones to zone-pairs, apply the policies
  5. Assign zones to the interfaces
Meaningful names for all objects with prefixes such as ACL_, CMAP_PMAP, will allow you to easily separate the objects purpose. You can also police within the class-map, and set IOS FW type inspection parameters. You can also inspect protocol specific parameters. The basic zone-based firewall is pretty easy, but once you get into protocol parameters, it gets pretty messy. Man I hate this security stuff...if only there was a CCIE track for security professionals.....................................................

Now on to transparent firewall, which requires running a bridge group. The router can operate the bridge in two modes. Concurrent Routing and Bridging or Integrated Routing and Bridging. CRB mode allows the router to bridge frames between interfaces configured as members of a single bridge group. The router acts as a bridge for one set of interfaces, and a L3 router for the remaining interfaces. IRB mode allows configuring a special Bridge Virtual Interface for every bridge group. This represents the router as a L3 device within the bridge group. BVI is like a SVI in a layer 3 switch. You create bridges with 'bridge crb' or 'bridge irb'. In addition, with IRB, you need to add 'bridge x route ip' to route packets. Then simply add the interfaces to the bridge group by issuing 'bridge-group x'. Bridges by default will have STP disabled - enable with 'bridge x protocol IEEE'. For the transparent firewall, you may apply the classic firewall inspect rules and ACLS to the interface configured with the bridge group numbers.

To filter non-IP traffic, you need to apply a protocol-type access-list. These exist in the range 201 - 299 and permit traffic based on Ethertype of SNAP PID value. Apply with 'bridge-group x input-type-list '. Broadcast frames are subject to the transparent firewall. To permit DHCP, issue 'ip inspect l2-transparent dhcp-passthrough'. Overall, not too difficult. Create a bridge and apply firewall policies to the interfaces - inside,outside,dmz,etc.

You can also do zone-based firewall w/ transparent bridging. Good news! I was able to build the config myself. ZBF is a classic example of Narbik's 'tell a story' method. Remember the steps, and do them in the right order, and it will work every time! Now IOS IPS...

I would say the chance of actually seeing this on the lab is very small, but it is included for completeness. Here are the steps:

  1. Download IOS IPS files
  2. Creating IOS IPS configuration directory on flash
  3. Configuring IOS IPS crypto key
  4. Enabling IOS IPS
  5. Loading IOS IPS signature package(s) to the router
  6. Tuning signatures.
If you see this, the IPS files should already be loaded for you. You create the directory with the unix classic 'mkdir' command. The IOS crpyto key is used to verify the signatures. You simply needs to load Cisco's public key into the router. From there, you need to configure IOS IPS like so...

ip ips name [list ]
ip ips config location flash:
ip ips notify sdee
ip ips notify log

The above should be self-explanatory. The next step is to retire most IPS signuatures. Since the package is so big, the IOS will not be able to fit all signatures into memory. Retired signatures are not compiled in memory, disabled are compiled but not triggered - so it is important to retire the signatures.

ip ips signature-category
     category all
          retired true
     exit
     category ios_ips basic
          retired false
     exit
exit

The above will retire all signatures, and then enable the basic IPS signatures. Now you need to apply the IPS rule to the interface.

interface FastE0/0
ip ips in

The final step is loading the IOS IPS signature package. Signatures are loaded using a special destination known as IDCONF. 

copy ftp://cisco:cisco@10.0.0.100/IOS-S310-CLI.pkg idconf

This will initiate the compile process in the router memory. Use 'show ip ips signature count' to check stats on the loaded signatures. You can also tune individual signatures like so...

ip ips signature-definition
     signature 2004 0
         status
             enabled true
             retired false
         exit 
         engine 
               event-action produce-alert
         exit
         alert-severity high
         fidelity-rating 100
     exit
exit

You can also tune an entire category, use category x instead of the signature definition name above.

Finally, there is a limited Signature Event Action Processing feature. You may assign Target Value Rating to IP subnets.

ip ips event-action-rules
     target-value medium target-address 150.1.2.0/24
    exit

The risk-rating computation formula for attacks towards this IP subnet are 'medium'.

And with that being said, I have completed security. Overall, not too bad. I did learn a few new things, and was introduced to things I had not seen before. I will need to re-visit and read up on several items such as ZBF, Flexible Packet Matching, CPP/CPPr and Role Based CLI. In the mean time, I am moving on to system management, which will probably include my most-hated EEM.....