Bogons via BGP

What is a bogon, and why should I filter it?

A bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPNs or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks.

Ref:http://www.team-cymru.org/Services/Bogons/

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems.

 The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED. Thus, for network X, if Internet Service Provider A (ISP A) sets the MED to 10, and ISP B sets the MED to 20, both ISPs agree that ISP A has the better performing path to X.

Note: The bgp deterministic-med and bgp always-compare-med commands are not enabled by default. Also, the two commands are separate; enabling one does not automatically enable the other.

Ref:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094925.shtml http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

BGP route reflectors

Route Reflector rules 

A BGP router implementing route reflector functionality propagates BGP routes according to these rules: Locally originated routes and routes received from EBGP neighbors and selected as best routes are propagated to all BGP peers (internal and external). Routes received from an IGBP peer that is not a route-reflector client and selected as best routes are propagated to all EBGP peers and all IGBP peers configured as route-reflector clients. Routes received from a route-reflector client and selected as best routes are propagated to all BGP peers (internal and external). Whenever an IBGP route is reflected (propagated to another IBGP peer), the route reflector appends two optional, non-transitive attributes to the BGP route: If the route does not have the Originator ID attribute (it has not been reflected before), the router ID of the IBGP peer from which the route has been received is copied into the Originator ID attribute. If the route does not have the Cluster list attribute, it’s added to the route. The value configured with the bgp cluster-id router configuration command (or the router ID of the route reflector if the cluster-id is not configured) is prepended to the Cluster list attribute. Route reflector does not change or remove any other attributes of the reflected routes (even non-transitive attributes), ensuring that the IBGP routes are not changed within the autonomous system.  

Loop Detection and Avoidance The BGP routers implementing original route reflector RFC (RFC 1966) use the following mechanisms to detect route-reflector-related loops: If the Originator ID in an incoming IBGP route update is equal to the BGP router ID, the update is ignored (reflected route was propagated back to its originator). If the Cluster ID of a route-reflector appears in the Cluster list attribute of an incoming IBGP update, the update is ignored (route reflector loop). The route reflector functionality was introduced in IOS release 11.1. It’s therefore relatively safe to assume that every Cisco router encountered in a production network supports it. Although the mechanisms specified in RFC 1966 ensure loop-free IBGP operation regardless of the actual topology of the IBGP sessions, RFC 4456 added new route selection rules that improve the actual convergence within an AS and reduce the amount of BGP updates propagated across the AS: Routes with shorter Cluster list attribute are preferred. This rule ensures that all routers select routes with minimum number of reflections, significantly reducing the amount of unnecessary BGP updates (remember: only best routes selected by a route reflector are reflected to its clients). The Originator ID attribute of a reflected route should be used as the Router ID attribute when comparing otherwise identical IBGP routes, ensuring the stability of route selection across AS regardless of the route reflectors.

Ref:http://wiki.nil.com/BGP_route_reflectors

Feature Information for Cisco IOS Scripting with Tcl

Table 4 Feature Information for Cisco IOS Scripting with Tcl
Feature Name

Releases

Feature Information

Cisco IOS Scripting with Tcl


12.3(2)T
12.3(7)T
12.2(25)S
12.2(33)SXH
12.2(33)SRC
12.2(33)SB
Cisco IOS XE 3.1.0SG


The Cisco IOS Scripting with Tcl feature provides the ability to run Tcl version 8.3.4 commands from the Cisco IOS command-line interface.

The following commands were introduced or modified: scripting tcl encdir, scripting tcl init, scripting tcl low-memory, tclquit, tclsh.

Tcl SNMP MIB Access


12.3(7)T
12.2(25)S
12.2(33)SXH
12.2(33)SRC
12.2(33)SB
Cisco IOS XE 3.1.0SG


The Tcl SNMP MIB Access feature introduces a set of UNIX-like SNMP commands to make access to Simple Network Management Protocol (SNMP) MIB objects easier.

The following section has more information:

•Using the Tcl Shell to Access SNMP MIB Objects.

TCL UDP and VRF support


15.1(1)T


The Tcl UDP and VRF feature provides support for UDP sockets in IOS Tcl.

The following commands were introduced or modified: fconfigure, socket, udp_open, udp_peek.

Feature Information for Cisco IOS Scripting with Tcl

Can I combine EEM applets with Tcl shell?

event manager applet Clear
event syslog pattern "OSPF-5-ADJCHG.*to FULL"
action 1.0 cli command "enable"
action 1.1 cli command "tclsh flash:tcl/clearL0.tcl"

Can I combine EEM applets with Tcl shell?: When I've been describing the limitations of kron , ??? quickly asked an interesting question: “as I cannot insert extra input keystrokes wi...

Send email from a CISCO router with specifc source IP

1. In case of CISCO EEM, need to use NAT, see below example
 Set the source IP address of EEM SMTP session


2. TCL script

If you use Tcl, you could write your own SMTP client and use the -myaddr parameter in the socket call to specify the source IP address.

socket ?options? host port

socket

change-source-ip-address-of-eem-smtp

3. EEM SMTP Library Command Extensions

smtp_send_email

Sourceaddr: $_email_ipaddr

EEM SMTP Library Command Extensions

Cisco TCL scripts sites

www.packetlevel.ch
ioshints
Tclsh_on_Cisco_IOS_tutorial

Use CISCO EEM script to send email

Send (authenticated) email from your router using EEM

event manager environment _email_to noc@isp.com
event manager environment _email_server usr:pwd@mail.isp.com
event manager environment _email_from usr@isp.com

action 1.0 mail server "$_email_server" to "$_email_to" from "$_email_from" subject "$_event_pub_time: Login via SSH" body "$_syslog_msg"

action 1.5 syslog msg priority 5 "Mail Sent"

Send email from your router using EEM

EEM Send e-mail after a router reload

For example, to execute an EEM applet that will send an e-mail twenty 
seconds after the router reload, you could use this configuration: 

hostname test
!
service timestamps debug uptime
service timestamps log uptime
!
event manager applet ReloadNotify 
 event timer countdown name Delay time 20
 action 1.0 info type routername
 action 1.1 mail server "mail.example.com" →
   to "ops@example.com" from "$_info_routername@example.com" →
   subject "Router reload: $_info_routername"
 action 1.2 syslog msg "E-mail was sent"

Ref: Send e-mail after a router reload

How To Send MIME Attachments Using EEM

::cisco::eem::register_event_none

namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

# First, create the headers and body of your message
set email_body_pre "Mailservername: $_email_server
From: $_email_from
To: $_email_to
Cc:
Subject: Email from Router $_router_name
MIME-Version: 1.0
Content-type: multipart/mixed; boundary=\"EEM_email_boundary\"
\n--EEM_email_boundary\n
\n--EEM_email_boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename=\"test.log\"\n\n"

# Then, read in the data you wish to attach.
if [catch {open "flash:test.log"} result] {
    error $result $errorInfo
}
set fd $result
# Encode that data using the built-in base64 library.
set email_b64 [::base64::encode [read $fd]]
close $fd

# Construct the final message with the headers, body, and MIME parts.
set email_body_mime "\n--EEM_email_boundary--"

set email_body [format "%s%s%s" $email_body_pre $email_b64 $email_body_mime]

# Send the email.
if [catch {smtp_send_email $email_body} result] {
    error $result $errorInfo
}

Ref:How To Send MIME Attachments Using EEM 

Cisco EEM script tracking WAN connection

This script will track WAN interface (ATM 0 in this case), if the status changed to down, it will collect some show result and save it to the nvram.

_______________________________________________________
track 1 interface ATM 0 line-protocol

event manager session cli username yourname

service internal

event manager applet MONITOR_INTERFACE

event track 1 state down

action 0.1 syslog msg "WAN interface down"

action 0.2 cli command "enable"

action 0.3 cli command "ter len 0"

action 0.4 cli command "show ip int brief | append nvram:MONITOR_INTERFACE.txt"

action 0.5 cli command "Show int atm 0 | append nvram:MONITOR_INTERFACE.txt"

action 0.6 cli command "show dsl interface atm 0 | append nvram:MONITOR_INTERFACE.txt"

action 0.7 cli command "show int summary | append nvram:MONITOR_INTERFACE.txt"

action 0.8 cli command "show log | append nvram:MONITOR_INTERFACE.txt"

action 0.9 syslog msg "Finished logging information to nvram:MONITOR_INTERFACE.txt..."

action 1.0 cli command "end"
____________________________________________________________

Reference: Monitor multiple interfaces with a single EEM applet
Working with the Embedded Event Manager (EEM)
EEM Script to reload router only once after tracked object is down.

BT LES BT WES BT EAD

BT LES = BT LAN Extension Service
BT’s LAN Extension Service provides high speed dedicated links　ｒunning between your dispersed sites, connecting together LANs　at speeds of up to 1,000Mbps with Ethernet, Fast Ethernet and　Gigabit Ethernet interfaces.
http://www2.bt.com/static/i/media/pdf/lan_san_broch.pdf


BT WES = BT　Wholesale Extension Service (replaced by EAD)
A high speed, point-to-point data circuit provided by BT Wholesale which provides a secure link between the point of presence of a CP and a third party customer site.
http://stakeholders.ofcom.org.uk/telecoms/policy/bt-undertakings/glossary

BT EAD = Ethernet Access Direct (EAD) provides permanently connected point-to-point
high speed data circuits between sites.
http://www.openreach.co.uk/orpg/home/products/ethernetservices/wholesaleextensionservices/wes/downloads/WES_BES_WEES_withdrawal_fact_sheet.pdf

Integrated Routing and Bridging (IRB)

In order for a VLAN to span a router, the router must be capable of forwarding frames from one interface to another, while maintaining the VLAN header. If the router is configured for routing a Layer 3 (network layer) protocol, it will terminate the VLAN and MAC layers at the interface a frame arrives on. The MAC layer header can be maintained if the router is bridging the network layer protocol. However, regular bridging still terminates the VLAN header. Using the IRB feature in Cisco IOS^® Release 11.2 or greater, a router can be configured for routing and bridging the same network layer protocol on the same interface. This allows the VLAN header to be maintained on a frame while it transits a router from one interface to another. IRB provides the ability to route between a bridged domain and a routed domain with Bridge Group Virtual Interface (BVI). The BVI is a virtual interface within the router that acts like a normal routed interface that does not support bridging, but represents the comparable bridge group to routed interfaces within the router. The interface number of the BVI is the number of the bridge group that the virtual interface represents. The number is the link between the BVI and the bridge group.
When you configure and enable routing on the BVI, packets that come in on a routed interface, which are destined for a host on a segment in a bridge group, are routed to the BVI. From the BVI, the packet is forwarded to the bridging engine, which forwards it through a bridged interface. This is forwarded based on the destination MAC address. Similarly, packets that come in on a bridged interface, but are destined for a host on a routed network, first go to the BVI. Next, the BVI forwards the packets to the routing engine before it sends them out of the routed interface. On a single physical interface, the IRB can be created with two VLAN sub-interfaces (802.1Q tagging); one VLAN sub-interface has an IP address that is used for routing, and the other VLAN sub-interface bridges between the sub-interface used for routing and the other physical interface on the router.
Since the BVI represents a bridge group as a routed interface, it must be configured only with Layer 3 (L3) characteristics, such as network layer addresses. Similarly, the interfaces configured for bridging a protocol must not be configured with any L3 characteristics.

Ref:Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature

L2 VPN—Any to Any Interworking

Bridged Interworking Mode

In bridged interworking mode, Ethernet frames are extracted from the AC and sent over the pseudo wire. AC frames that are not Ethernet are dropped. In the case of a VLAN, the VLAN tag is removed, leaving an untagged Ethernet frame. This interworking functionality is implemented by configuring the interworking ethernet command under the pseudo-wire class configuration mode.

Routed Interworking Mode

In routed interworking, IP packets are extracted from the AC and sent over the pseudo wire. AC frames are dropped if they do not contain the IPv4 packets. This interworking functionality is implemented by configuring the interworking ip command under the pseudo-wire class configuration mode.

Ref:L2 VPN—Any to Any Interworking 

Layer 2 Virtual Private Network Interworking 

Configuring L2VPN Interworking 

Time to Live (TTL) traceroute

4.2.2.9 Time to Live: RFC 791 Section 3.2

Time to Live (TTL) handling for packets originated or received by the router is governed by [INTRO:2]; this section changes none of its stipulations. However, since the remainder of the IP Protocol section of [INTRO:2] is rewritten, this section is as well.

Note in particular that a router MUST NOT check the TTL of a packet except when forwarding it.
A router MUST NOT originate or forward a datagram with a Time-to-Live (TTL) value of zero.
A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it.

How Traceroute Works

Traceroute transmits packets with small TTL values. Recall that the TTL (Time To Live) is an IP header field that is designed to prevent packets from running in loops. Every router that handles a packet subtracts one from the packet's TTL. If the TTL reaches zero, the packet has expired and is discarded. Traceroute depends on the common router practice of sending an ICMP Time Exceeded message, documented in RFC 792, back to the sender when this occurs. By using small TTL values which quickly expire, traceroute causes routers along a packet's normal delivery path to generate these ICMP messages which identify the router. A TTL value of one should produce a message from the first router; a TTL value of two generates a message from the second; etc.

+--------+                                          +--------+   
      | SENDER |                                          | TARGET |   
      +--------+                                          +--------+   
          |                                                   ^|     
       [============( Router )=====( Router )=====( Router )==|====]
                   ^              ^              ^            |  
                   | TTL=1        | TTL=2        | TTL=3      | TTL=4  
  Traceroute       |              |              |            |        
  shows these -----+--------------+--------------+------------/       
  IP addresses                                                         
                                                                       

In a typical traceroute session, a group of packets with TTL=1 are sent. A single router should respond, using the IP address of the interface it transmits the ICMP Timeout messages on, which should be the same as the interface it received the original packets on. The user is told this IP address, and DNS is used to convert this into a symbolic domain address. Also, round trip times are reported for each packet in the group. Traceroute reports any additional ICMP messages (such as destination unreachables) using a rather cryptic syntax - !N means network unreachable, !H means host unreachable, etc. Once this first group of packets has been processed (this can take 10 seconds or no time at all), the second group (TTL=2) begins transmitting, and the whole process repeats.

Ref:4.2.2.9 Time to Live: RFC 791 Section 3.2
When is TTL Decremented by a Router?
icmp sequence diagram
Confirming TTL
traceroute

Active FTP vs Passive FTP

Active FTP :   
     command : client >1024 -> server 21   
     data    : client >1024 <- server 20   
 

Passive FTP :   
     command : client >1024 -> server 21   
     data    : client >1024 -> server >1024

FTP operates on the application layer of the OSI model, and is used to transfer files using TCP/IP.^[3] To do so, an FTP server has to be running and waiting for incoming requests.^[3] The client computer is then able to communicate with the server on port 21.^[3][4] This connection, called the control connection,^[5] remains open for the duration of the session. A second connection, called the data connection,^[2][5] can either be opened by the server from its port 20 to a negotiated client port (active mode), or by the client from an arbitrary port to a negotiated server port (passive mode) as required to transfer file data.^[2][4] The control connection is used for session administration, for example commands, identification and passwords exchanged between the client and the server using a telnet-like protocol.^[6] For example "RETR filename" would transfer the specified file from the server to the client. Due to this two-port structure, FTP is considered an out-of-band protocol, as opposed to an in-band protocol such as HTTP.^[6]

Ref:ftp modes
wiki FTP
FTP session sequence

Internet Mix or IMIX packet

Ref:Internet Mix

Internet Mix or IMIX is a term used to describe typical Internet traffic passing some network equipment such as routers, switches or firewalls. When measuring equipment performance using an IMIX of packets the performance is assumed to resemble what can be seen in actual real life.
Networking equipment that manipulates packets typically have non-wire rate performance and as such it can not deliver wire rate performance on small 64 byte packets, this is easier at 1500 byte packets - but none of these packet sizes resemble actual traffic seen on the Internet over some time.
The IMIX traffic profile is used in the industry to simulate real-world traffic patterns and packet distributions. IMIX profiles are based on statistical sampling done on Internet routers, and are published in various levels of granularity, such as “simple” and “complete.”
Mix profiles exist for IPv4, TCP, VPN (IPsec) and IPv6 traffic, distributions are similar but frame sizes vary given the different overhead and upper layer 2 limitations on MTU.
Here is an illustration of a typical mix:

Packet size	# Packets	Bytes	Distribution
64	67	4288	57%
570	1	570	7%
594	2	1188	16%
1518	1	1518	20%

Enable Fast-Switched PBR

Enable Fast-Switched PBR

IP PBR can now be fast-switched. Prior to Cisco IOS Release 12.0, PBR could only be process-switched, which meant that on most platforms the switching rate was approximately 1000 to 10,000 packets per second. This speed was not fast enough for many applications. Users who need PBR to occur at faster speeds can now implement PBR without slowing down the router.

Fast-switched PBR supports all of the match commands and most of the set commands, with the following restrictions:

•The set ip default next-hop and set default interface commands are not supported.

•The set interface command is supported only over point-to-point links, unless a route-cache entry exists using the same interface specified in the set interface command in the route map. Also, at the process level, the routing table is consulted to determine if the interface is on a reasonable path to the destination. During fast switching, the software does not make this check. Instead, if the packet matches, the software blindly forwards the packet to the specified interface.

PBR must be configured before you configure fast-switched PBR. Fast switching of PBR is disabled by default. To enable fast-switched PBR, use the following command in interface configuration mode:

Command	Purpose
ip route-cache policy	Enable fast switching of PBR.

To display the cache entries in the policy route cache, use the show ip cache policy command. Use the show ip policy command to display which route map is associated with which interface. 

Ref:Configuring Policy-Based Routing

Linux 4 Ways to Kill a Process – kill, killall, pkill, xkill

1. Kill Command – Kill the process by specifying its PID
2. Killall Command – Kill processes by name
3. Pkill Command – Send signal to the process based on its name
4. Xkill Command – kill a client by X resource

Ref: http://www.thegeekstuff.com/2009/12/4-ways-to-kill-a-process-kill-killall-pkill-xkill/#more-2547
http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7

Linux interface commands

ifconfig eth1

ifconfig eth1 up

ifup eth1 

ip link show eth1

ethtool eth1

check if signal from the line....
sudo ethtool eth1 | grep "Link detected"
        Link detected: no

add route:

ip route add 10.10.66.229/32 dev eth1

Ref:http://linux.die.net/man/8/ip
http://www.whatismyip.com/faq/linux-ip-commands.asp