Route redistribute, filtering notes

On a router, redistribute protocol A in to protocol B

Following routes will be distributed into protocol B:
1. all interfaces which running protocol A (exclude ISIS/ODR)
2. all routes learned from protocol A

In case of mutual redistribution at multiple redistribution points, be careful when distribute from a preferred (AD) protocol into a less preferred protocol (e.g from OSPF into RIP)

Because link state protocols do not advertise routes from their routing table as do distance vector protocols, there are no updates to filter. Because of this behavior, route filters are mostly used at redistribution points into link state domains, such as an OSPF ASBR, where they can regulate which routes enter or leave the domain. Within the link state domain, route filters have limited utility.

From Routing TCP.IP

Broadcast 255.255.255.255

 
Why Broadcast?

   Broadcasts are useful when a host needs to find information without
   knowing exactly what other host can supply it, or when a host wants
   to provide information to a large set of hosts in a timely manner.

How router treat 255.255.255.255? 

The address 255.255.255.255 denotes a broadcast on a local hardware
   network, which must not be forwarded.  This address may be used, for
   example, by hosts that do not know their network number and are
   asking some server for it. 

Ref: http://tools.ietf.org/html/rfc919

http://ciscodreamer.blogspot.com/search/label/ICMP

Distance vector vs. Link state

A distance vector protocol shares everything it knows but only with
directly connected neighbors.

Link state protocols announce information only about their directly
connected links, but they share the information with all routers in their routing domain or area.

From book Routing TCP.IP

Bellman–Ford algorithm is used in distance-vector routing protocols

1. Each node calculates the distances between itself and all other nodes within the AS and stores this information as a table.
2. Each node sends its table to all neighboring nodes.
3. When a node receives distance tables from its neighbors, it calculates the shortest routes to all other nodes and updates its own table to reflect any changes. 

http://en.wikipedia.org/wiki/Bellman%E2%80%93Ford_algorithm

Routing Information Protocol (RIP)

RIPv1 is defined in RFC 1058, and operates on UDP port 520.

RIP uses only hop count as its metric, with a maximum of 15 (a metric of 16 indicates unreachability).

Upon initialization, RIP routers issue requests for routes from neighbors. Neighbors issue responses

containing their full routing tables.

Routers broadcast their entire table to the link-local broadcast address of 255.255.255.255 every 30 seconds (on average; a small jitter is included to prevent simultaneous flooding).

RIP Timers

Update (30 seconds) - How often routes are advertised (+/- a small random delay)

Invalid (180 seconds) - How long a received route will stay in the routing table without being

received again, before being marked as invalid.

Flush (240 seconds) - 60 seconds longer than the invalid timer; invalid routes will be flushed

from the table when this timer is reached.

Holddown (180 seconds) - Routes will be kept in the table for this time before being replaced

by an advertisement with a higher metric.


An offset list can be implemented to artificially increase the metric for certain routes:
offset-list <ACL> {in | out} <offset> <interface>

Use distribute-list to filter routes update:
distribute-list <ACL> {in | out} <interface>

When debugging RIP:

*Mar  1 00:15:42.943: RIP: sending v1 update to 255.255.255.255 via Loopback0 (2.2.2.2)
*Mar  1 00:15:42.943: RIP: build update entries
*Mar  1 00:15:42.943:   network 1.0.0.0 metric 2
*Mar  1 00:15:42.947:   network 10.0.0.0 metric 1 <<< this means the network is directly connected (by using network command under rip process)


*Mar  1 00:18:21.435: RIP: sending v2 update to 224.0.0.9 via Loopback0 (2.2.2.2)
*Mar  1 00:18:21.439: RIP: build update entries
*Mar  1 00:18:21.439:   1.1.1.1/32 via 0.0.0.0, metric 2, tag 0
*Mar  1 00:18:21.443:   10.0.12.0/24 via 0.0.0.0, metric 1, tag 0 <<< this means the network is directly connected (by using network command under rip process)




Ref: http://media.packetlife.net/media/library/29/Routing_TCP-IP_Vol_1_Notes.pdf

Using Subnet Zero and the All-Ones Subnet

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

PBR set ip next-hop recursive

access-list 100 permit ip host 1.1.1.1 host 4.4.4.4
!
route-map PBR permit 10
 match ip address 100
 set ip next-hop recursive 3.3.3.3

##################################################################################
set ip next-hop recursive [3.3.3.3] - The router will forward matching traffic to the interface of "show ip route 3.3.3.3", if can not find any it forward using normal routing table. 


##################################################################################


Successful PBR
*Mar  1 00:19:31.507: IP: tableid=0, s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet1/3), routed via RIB
*Mar  1 00:19:31.507: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4, len 100, policy match
*Mar  1 00:19:31.511:     ICMP type=8, code=0
*Mar  1 00:19:31.511: IP: route map PBR, item 10, permit
*Mar  1 00:19:31.511: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet0/3), len 100, policy routed
*Mar  1 00:19:31.511:     ICMP type=8, code=0
*Mar  1 00:19:31.511: IP: Ethernet0/0 to Ethernet0/3 10.2.23.3
*Mar  1 00:19:31.515: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet0/3), g=10.2.23.3, len 100, forward
*Mar  1 00:19:31.515:     ICMP type=8, code=0




Unsuccessful PBR
*Mar  1 00:15:53.939: IP: tableid=0, s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet1/3), routed via RIB
*Mar  1 00:15:53.939: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4, len 100, policy match
*Mar  1 00:15:53.943:     ICMP type=8, code=0
*Mar  1 00:15:53.943: IP: route map PBR, item 10, permit
*Mar  1 00:15:53.943: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet1/3), len 100, policy rejected -- normal forwarding
*Mar  1 00:15:53.943:     ICMP type=8, code=0
*Mar  1 00:15:53.943: IP: s=1.1.1.1 (Ethernet0/0), d=4.4.4.4 (Ethernet1/3), g=10.0.24.4, len 100, forward
*Mar  1 00:15:53.947:     ICMP type=8, code=0


Ref: http://cisconinja.wordpress.com/category/pbr/
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12s_pbr.html

Cisco spanning tree animation

Cisco spanning tree animation

Unicast RPF Examples

Unicast RPF is an input function and is applied on the interface of a router only in the ingress direction. 

Strict Mode RPF

If the source address is in the FIB and reachable only through the interface on which the packet was received, the packet is passed. The syntax for this method is ip verify unicast source reachable-via rx.  

Ref: http://www.cisco.com/en/US/docs/ios/12_3/security/command/reference/sec_i2g.html

http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html

Bash script to check validate IP address

#!/bin/bash

# Test an IP address for validity:
# Usage:
#      is_ip IP_ADDRESS
#      if is_ip IP_ADDRESS; then return 1; else return 0; fi
#



is_ip(){

    input=$1
    octet1=$(echo $input | cut -d "." -f1)
    octet2=$(echo $input | cut -d "." -f2)
    octet3=$(echo $input | cut -d "." -f3)
    octet4=$(echo $input | cut -d "." -f4)
    stat=0

if [[ $input =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]] && [ $octet1 -le 255 ] && [ $octet2 -le 255 ] && [ $octet3 -le 255 ] && [ $octet4 -le 255 ];
  then
    stat=1
fi


echo "IP $input is $stat."

return  $stat

}

if [ -z $1 ];
  then
   echo "Usage: sh is_ip.sh IP_ADDRESS"
   exit 0
  else
   is_ip $1
fi
Ref: http://www.linuxjournal.com/content/validating-ip-address-bash-script

Bash error [: =: unary operator expected

Use - if [ "$number" = "1" ]; then

NOT - if [ $number = "1" ]; then 

http://linuxcommand.org/wss0100.php

Auto ssh command

$ ssh -q -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -l remote_login remote_host "command opts args..."

 Ref: http://www.unix.com/shell-programming-scripting/75930-how-do-i-handle-ssh-response-expect.html

Auto ssh command


In expect script, below one is working:


spawn ssh  -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $vIP

Expect with different passwords

proc login {user pass} {
    expect "login:"
    send "$user\r"
    expect "password:"
    send "$pass\r"
}
set username spongebob set passwords {squarepants rhombuspants}
set index 0

spawn telnet 192.168.40.100
login $username [lindex $passwords $index]
expect {
    "login incorrect" {
        send_user "failed with $username:[lindex $passwords $index]\n"
        incr index
        if {$index == [llength $passwords]} {
            error "ran out of possible passwords"
        }
        login $username [lindex $passwords $index]
        exp_continue
    }
    "prompt>" }
send_user "success!\n"
# ...
 

http://stackoverflow.com/questions/1538444/using-conditional-statements-inside-expect 

Cisco 10GBASE XENPAK Modules

Cisco 10GBASE XENPAK Modules

http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps5138/product_data_sheet09186a008007cd00_ps5251_Products_Data_Sheet.html

Traffic Shaping and Policing

A key difference between shaping and policing is the rate at which tokens are replenished. This section reviews the difference.  


Shaping increments the token bucket at timed intervals using a bits per second (bps) value. A shaper uses the following formula:

Tc = Bc/CIR (in seconds)

In this equation, Bc represents the committed burst, and CIR stands for committed information rate. (See Configuring Frame Relay Traffic Shaping for more information.) The value of Tc defines the time interval during which you send the Bc bits in order to maintain the average rate of the CIR in seconds.


When the excess burst (Be) is configured to a value different than 0, the shaper allows tokens to be stored in the bucket, up to Bc + Be. The largest value that the token bucket can ever reach is Bc + Be, and overflow tokens are dropped. The only way to have more than Bc tokens in the bucket is to not use all Bc tokens during one or more Tc. Since the token bucket is replenished every Tc with Bc tokens, you can accumulate unused tokens for later use up to Bc + Be.

In contrast, class-based policing and rate-limiting adds tokens continuously to the bucket. Specifically, the token arrival rate is calculated as follows:

(time between packets<which is equal to t-t1>* policer rate)/8 bits per byte

In other words, if the previous arrival of the packet was at t1 and the current time is t, the bucket is updated with t-t1 worth of bytes based on the token arrival rate. Note that a traffic policer uses burst values specified in bytes, and the above formula converts from bits to bytes.







Shaping implicitly uses the averaging interval Tc=Bc/CIR to meter the average traffic rate. Larger Bc values allow for better accommodation of bursty traffic flows with oscillating traffic rates. Smaller Bc is good for stable flows, in situations where you don’t tolerate even a small violation of the instant traffic rate.

Ref:
The Meaning of Bc with Traffic Policing
Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting
Shaping and policing on Cisco

Traffic shaping

AR=Access Rate = Serialization Rate (Ethernet 10Mbps)

It will take 1.2 ms to transmit a 1500Bytes PDU on Ethernet. [1500 * 8 bytes * 1000 ms / 10M]

CIR=Committed Information Rate
Bc=Committed Burst Size
Be=Excessive Burst Size
Tc=Time Interval

Bc/Tc=CIR/SEC

if
CIR=8bps
Tc=125ms

then
Bc=1bit

|125ms_|_|_|_|_|_|_|
<-   1000ms        ->

Reduce Bc for smaller Tc to improve VoIP traffic performance (which will wait shorter per time interval)

Be/Tc=(AR-CIR)/SEC

Be allow customer to bank "credit" from early time intervals and send it later on within a second, the overall traffic will not exceed the CIR.

Understanding Single-Rate and Dual-Rate Traffic Policing

Control Plane Policing Implementation (CPP) Best Practices

Network Core Infrastructure Best Practices 

http://www.nanog.org/meetings/nanog42/presentations/Bhaiji_Network_Core.pdf 

 

Control Plane Policing Implementation Best Practices

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html 

 

Configuring Denial of Service Protection

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/dos.html

Protecting the Cisco Catalyst 6500 Series Switches Against Denial-Of-Service Attacks

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

 

Deploying Control Plane Policing

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html

 

Control Plane Policing

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html 

 

ICMP/PING drops when pinging from Nexus 7000

https://supportforums.cisco.com/docs/DOC-15510

Cisco Control Plane Policing

http://security-planet.de/2005/07/26/cisco-control-plane-policing/

Filtering BGP Routes

Using Distribute Lists to Filter Network Prefixes

Using Prefix Lists to Filter BGP Routes

Using Route Maps to Filter BGP Routes

Ref:

http://www.informit.com/library/content.aspx?b=CCIE_Practical_Studies_II&seqNum=102

ICMP PING

ICMP segment structure

The ICMP header starts after the IPv4 header. All ICMP packets will have an 8-byte header and variable-sized data section.

    Windows "ping.exe" adds, by default, 32 bytes of padding
    The Linux "ping" utility adds, by default, 56 bytes of padding

#########################################################
C:\Documents and Settings\wentao.yang>ping 121.59.0.1

Pinging 121.59.0.1 with 32 bytes of data:

Reply from 121.59.0.1: bytes=32 time=1ms TTL=247
#########################################################
yang@test.nmlon:~$ ping 192.168.231.0
PING 192.168.231.0 (192.168.231.0) 56(84) bytes of data.
64 bytes from 192.168.231.0: icmp_seq=1 ttl=251 time=1.06 ms

Ref: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
http://ss64.com/bash/ping.html

Steps for sending a packet out

THIS is from https://learningnetwork.cisco.com/thread/15223

       

Steps for sending a packet out -

Step 1 - (IPv4 Routing Lookup) --> Goal is to decide on the following entities first.

- Longest match / Lowest AD / Lowest Metric / Overlapping Routes(Multiple routes to the same destination in the routing table) / Policy Routing (Will override all the above steps)

- Outgoing interface

- Next-hop

Step 2 - (IPv4 Switching Method) --> Goal is to move packets between interfaces. Load Balancing occurs at this stage. Even though we have multiple routes in the routing table, the load balancing will not occur if the switching method is not configured to do so. If the switching method is not configured for load balancing, the packets will follow the same path even though multiple paths exists in the routing table. Can be verified by "show ip cef exact-route <source ip> <destination ip>". The above command based on the inputs of source and destination, will tell us the next hop IP and outgoing interface the packet is taking.

Decide on the following entities in the second step.

- Process

- Fast

- CEF

- Etc.

[Note -

1.) Once CEF is enabled, it will form the FIB and adjacency table with the help of Routing table and at the same moment and it will not check the routing table from then on unless there is change in the routing table and will forward all the packets based on CEF table only. CEF is ON by default on the routers.

2.) If on a local LAN, some users are saying that they are able to surf web without any issues and some are saying that they are having problems in surfing even though they all are on the sam LAN, then it's most probably issue with the underlying switching method. You can verify it using the command ip cef exact-route <source ip> <destination ip>, by giving the different Users source IP address and the same destination IP address. You can see different next-hop IP address, in the output if two route exists in the routing table for the same destination IP address.

3.) "show ip route" command simply checks whether our routing lookup is working or not. If you can see an valid output by show ip route command, it means our Routing Lookup worked fine. Now we can move on to check the Switching method. ]

Step 3 - (Layer 2 Encapsulation) --> Goal is to build Layer 2 frame header based on the next-hop value.

- Multipoint interfaces require layer 3 to layer 2 resolutions (For ethernet it depends on ARP / Proxy-ARP / Reverse ARP. For Frame-Relay it depends on Inverser-ARP / Static Mappings. Note that Ethernet is mapping remote layer 3 to remote layer 2 whereas Frame-Relay is mapping the remote layer 3 to local layer 2.)

- Point-to-Point interfaces do not require layer 3 to layer 2 mapping.

·         Debug ip-packet walkthrough

1.) First and foremost it will only show the process-switched packets.

2.) Secondly, all the packets locally generated or destined to any local interface will only be process switched no matter what. All transit traffic will be fast switched or CEF switched depending on what we have configured on the router.

3.) When you do "debug ip packet", follow the following messages

*Mar  2 02:33:38.559: IP: tableid=0, s=163.1.12.1 (local),d=163.1.12.2(Serial0/0), routed via RIB

*Mar  2 02:33:38.559: IP: s=163.1.12.1 (local), d=163.1.12.2 (Serial0/0),len 100, sending

*Mar  2 02:33:38.559:     ICMP type=8, code=0.

*Mar  2 02:33:41.559: IP: s=163.1.12.1 (local), d=163.1.12.2 (Serial0/0),len 100, encapsulation failed

*Mar  2 02:33:41.559:     ICMP type=8, code=0

STEP 1 - "routed via FIB / RIB" simply means that routing process was successful. Routed via RIB / FIB doesn't mean that the end-to-end connectivity is through.

STEP 2 - "sending" simply means that the packet is being sent to the switching process. The interface mentioned here is the outgoing interface where the switching process put the packet for transfer.

STEP 3 - If the third line in the output shows that "encapsulation failed" message, it means that our STEP 3 of packet forwarding failed. If you do "debug arp" along with "debug ip packet" you can see exactly after step 2, an ARP will be sent for any network not reachable.

[NOTE -

1.) If one of the above step is broken then it does't imply that the other step is broken. For example, if encapsulation is broken, then it doesn't imply that the routing is broken.

2.) If some router is sitting in the middle of the path and it doesn't have a route to the destination, it will generate ICMP unreachable message back to the source. You can verify it via "debug ip icmp". This is useful in determining end to end rechability. ]

Thanks to Brian McGahan for giving a clear picture of the above concept.

Regards,

Somit Maloo....

Troubleshooting Memory Problems

Memory fragmentation

Your router is facing an IO memory leak.  Don't focus on the fragmentation, it's only a side effect of the leak.  The main issue is that you're running out of IO memory and that's why you see MALLOCFAIL in Pool:I/O.

To troubleshoot this, collect 'show buffers'.  Look at which pool is heavily used (high 'total' number), then dump the packets in that pool with 'show buffer pool XXXX dump'.  We'll see what kind of packets are stuck in the buffers.

If you have a recent IOS, you can also use 'show memory debug leak' (will trigger a high CPU for a minute or so).

If you reload, memory will be cleared but we'll lose the information to troubleshoot the problem.

Only reload if you need to restore service quickly.  It won't fix the problem definitely.  The problem will come back later when the memory will be depleted again.

- show buffer pool Large dump
- show mem debug leak


Copy from: https://supportforums.cisco.com/thread/2053474

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6f3a.shtml

IPsec Anti-Replay Window

%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

Cisco IPsec authentication provides anti-replay protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. (Security association [SA] anti-replay is a security service in which the receiver can reject old or duplicate packets to protect itself against replay attacks.) The decryptor checks off the sequence numbers that it has seen before. The encryptor assigns sequence numbers in an increasing order. The decryptor remembers the value X of the highest sequence number that it has already seen. N is the window size, and the decryptor also remembers whether it has seen packets having sequence numbers from X-N+1 through X. Any packet with the sequence number X-N is discarded. Currently, N is set at 64, so only 64 packets can be tracked by the decryptor.

At times, however, the 64-packet window size is not sufficient. For example, Cisco quality of service (QoS) gives priority to high-priority packets, which could cause some low-priority packets to be discarded even though they could be one of the last 64 packets received by the decryptor. The IPsec Anti-Replay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep track of more than 64 packets.

Increasing the anti-replay window size has no impact on throughput and security. The impact on memory is insignificant because only an extra 128 bytes per incoming IPsec SA is needed to store the sequence number on the decryptor. It is recommended that you use the full 1024 window size to eliminate any future anti-replay problems. 

Ref: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_iarwe.html#wp1027188
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800949c5.shtml

https://supportforums.cisco.com/thread/2046718