Verifying ACL's and Prefix-list

It has been a while since I posted anything, apologies.  I have been very very busy at work with new projects. Some simple commands to verify an ACL/Prefix-list is getting programmed correctly into the TCAM(Hardware)

6509E#show tcam interface gigabitEthernet 7/1 acl in ip detail

* Global Defaults not shared

-------------------------------------------------------------------------------------------------------------------
DPort - Destination Port   SPort - Source Port        TCP-F - U -URG             Pro   - Protocol
I     - Inverted LOU       TOS   - TOS Value                - A -ACK             rtr   - Router
MRFM  - M -MPLS Packet     TN    - T -Tcp Control           - P -PSH             COD   - C -Bank Care Flag
      - R -Recirc. Flag          - N -Non-cachable          - R -RST                   - I -OrdIndep. Flag
      - F -Fragment Flag   CAP   - Capture Flag             - S -SYN                   - D -Dynamic Flag
      - M -More Fragments  F-P   - FlowMask-Prior.          - F -FIN             T     - V(Value)/M(Mask)/R(Result)
X     - XTAG               (*)   - Bank Priority
-------------------------------------------------------------------------------------------------------------------




Interface: 1018   label: 1025   lookup_type: 0
protocol: IP   packet-type: 0

+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
|T|Index|  Dest Ip Addr | Source Ip Addr|     DPort     |     SPort     | TCP-F |Pro|MRFM|X|TOS|TN|COD|F-P|
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+

Entries from Bank 0

 V 17139         0.0.0.0     10.202.218.2       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17144         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

 V 17140         0.0.0.0  10.187.36.133       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17144         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

 V 17141         0.0.0.0  10.187.36.240       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17144         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

 V 17142         0.0.0.0  10.187.50.138       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17144         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

 V 17143         0.0.0.0     10.51.3.35       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17144         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

 V 17145         0.0.0.0   10.10.83.93       P=0             P=0        ------   0 ---- 0   0 -- C-- 0-0
 M 17153         0.0.0.0 255.255.255.255         0               0        ------   0 ---- 0   0
 R rslt: L3_DENY_RESULT (*)            rtr_rslt: L3_DENY_RESULT (*)                  hit_cnt=0

6509E#show ip prefix-list detail to-someone
ip prefix-list to-someone:
   count: 8, range entries: 0, sequences: 25 - 70, refcount: 2
   seq 25 permit 1.1.1.0/23 (hit count: 20, refcount: 1)
   seq 35 permit 10.79.105.0/24 (hit count: 20, refcount: 1)
   seq 40 permit 10.67.251.0/24 (hit count: 20, refcount: 2)
   seq 50 permit 10.55.224.0/23 (hit count: 20, refcount: 1)
   seq 55 permit 10.55.192.0/24 (hit count: 9, refcount: 1)
   seq 60 permit 10.55.193.0/24 (hit count: 1, refcount: 2)
   seq 65 permit 10.55.194.0/24 (hit count: 1, refcount: 1)
   seq 70 permit 10.55.195.0/24 (hit count: 1, refcount: 5)

Good reference Link.

http://www.i-1.nl/blog/?p=134

Network Lingo

Some common terms that you will hear in the network world.

Management Plane—The management plane consists of functions that achieve the management goals of the network. This includes interactive management sessions using SSH, as well as statistics-gathering with SNMP or NetFlow. When you consider the security of a network device, it is critical that the management plane be protected. If a security incident is able to undermine the functions of the management plane, it can be impossible for you to recover or stabilize the network.

• Simple Network Management Protocol

• Telnet

• Secure Shell Protocol

• File Transfer Protocol

• Trivial File Transfer Protocol

• Secure Copy Protocol

• TACACS+

• RADIUS

• NetFlow

• Network Time Protocol

• Syslog

Control Plane—The control plane of a network device processes the traffic that is paramount to maintaining the functionality of the network infrastructure. The control plane consists of applications and protocols between network devices, which includes the Border Gateway Protocol (BGP), as well as the Interior Gateway Protocols (IGPs) such as the Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF).

Control plane functions consist of the protocols and processes that communicate between network devices to move data from source to destination. This includes routing protocols such as the Border Gateway Protocol, as well as protocols like ICMP and the Resource Reservation Protocol (RSVP).

Data Plane—The data plane forwards data through a network device. The data plane does not include traffic that is sent to the local Cisco IOS device.

Although the data plane is responsible for moving data from source to destination, within the context of security, the data plane is the least important of the three planes. It is for this reason that when securing a network device it is important to protect the management and control planes in preference over the data plane.

Upstream/Downstream—From the user's perspective, upstream network traffic flows away from the local computer toward the remote destination. If the data flows from your edge device further into your network, that would be upstream.

The Web browser sends HTTP requests upstream to the Web server, and the server replies with downstream data usually in the form of HTML pages. Downstream traffic flows to the user's computer.



Sources
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml

http://compnetworking.about.com/od/internetaccessbestuses/l/bldef_stream.htm

Multicast Links

If you are interested in learning multicast, review these in the order I have them listed. All these articles are Cisco centric and one thing to keep in mind is the architecture of your equipment.

Internet Protocol Multicast

Multicast Routing - PIM

Financial Services Design for High Availability


Configuring IP Multicast Routing

TCP & UDP

If your going to be in the network field, its a must that you learn how to read a packet capture. Some good articles that break down TCP/UDP to assist you with understanding how to read a capture are below.

Most, if not all companies have appliances that you will use to capture data on and store it for data mining purposes.  I am fortunate to have access to all the major players  in the sniffer appliance industry (Netscout,Niksun and Network Instruments). They have similar functionality to wire shark but with additional storage capabilities in the terabytes and a ton of add-ons, too many to list.

The Basics of Reading TCP/IP Traces

Understanding the TCP/IP Protocol Part 1 - 3

Understanding the UDP Protocol

As networks evolve, the amount of time it takes to put a frame on the wire             (serialization) is down to the nanosecond level, which I find amazing.  For smaller companies this might not matter as much. When you work for a financial company, thats all that does matter, how fast can you deliver a trade. Some time symbols are below for comparison and this is useful for packet captures. They all tie in together over time.

Minute --> Symbol: min
Second --> Symbol: s, sec
Millisecond --> Symbol: ms, msec
Microsecond --> Symbol: µs
Nanosecond --> Symbol: ns

Time Converter