AS-path filtering

Cisco way:

ip as-path access-list 1 deny _1234$
ip as-path access-list 1 deny _5678$
ip as-path access-list 1 permit .*

router bgp 100
neighbor 192.168.0.1 remote-as 200
neighbor 192.168.0.1 des ebgp-test
neighbor 192.168.0.1 filter-list 1 in

Juniper way:

protocols {
bgp {
group “ebgp-test” {
type external;
import test-in;
peer-as 200;
neighbor 192.168.0.1 {
}
}
policy-options {
policy-statement test {
from as-path [test test1];
then reject;
}
set policy-options as-path a “.*1234”
set policy-options as-path b “.*5678”
}

BGP regexp

Regular Expression:

Cisco Tacacs configuration

Also check :

Route servers

Route servers:

Internetwork

Internetwork

The Frontier Optronics Network now encompasses 11 hub cities. The northern route connects Los Angeles, San Francisco, Kansas City, Cleveland, and New York City at OC-48c or 2.5 Gbps speeds. A second backbone, through the South, connects Los Angeles, San Diego, Dallas, Atlanta, Washington D.C., and New York City—also at OC-48c. The two routes are joined together in a ring architecture, giving the backbone extended reliability and failover protection—a clear advantage over linear route networks (See Figure 1).

Optical Internet Benefits: Scalability and Simplicity

The hierarchical design of IP hubs in the Frontier Optronics Network provides Frontier with a robust and scalable infrastructure. At the highest level, redundant wide-area routers (WR1 and WR2) connect to the IP backbone at OC-48 speeds. At the middle layer, core routers (CR1 and CR2) connect lower layers to the WR routers at OC-12 speeds. At the lowest layer, an assortment of routers deliver specialized services: access routers (AR1) aggregate T1, T3 and OC-3 traffic; border routers (BR1) provide peering connections with other Internet providers; hosting routers (HR1) provide hosting services for web content; and dial routers (DR1) handle lower-speed customer access.

Bgp dampening

Cisco BGP dampening

Description:
When a route fails, a routing update is sent to withdraw the route from the network’s routing tables. When the route is re-enabled, the change in availability is also advertised. A route that continually fails and returns requires a great deal of network traffic to update the network about the route’s status.

Route dampening enables you to identify routes that repeatedly fail and return. If route dampening is enabled, an unstable route accumulates penalties each time the route fails and returns. If the accumulated penalties exceed a threshold, the route is no longer advertised. This is route suppression. Routes that have been suppressed are re-entered into the routing table only when the amount of their penalty falls below a threshold.

A penalty of 1000 is assessed each time the route fails. When the penalties reach a predefined threshold (suppress-value), the router stops advertising the route.

Once a route is assessed a penalty, the penalty is decreased by half each time a predefined amount of time elapses (half-life-time). When the accumulated penalties fall below a predefined threshold (reuse-value), the route is unsuppressed and added back into the BGP routing table.

No route is suppressed indefinitely. Maximum-suppress-time defines the maximum time a route can be suppressed before it is re-advertised

Use the bgp dampening command with arguments to override the defaults. If any argument is used, all the arguments must be defined.

Use the route-map keyword to associate a route-map to the dampening functionality. Only matching routes will be dampened according to the supplied parameters.

Use the no bgp dampening command to disable route dampening.

The following example enables route dampening and sets the half-life-time to 20 minutes, the reuse-value to 1800, the suppress-value to 8000, and the maximum-suppress-time to 50 minutes.

[[Category:Cisco]]

Show Interface Reference

Show Interface Reference

router#sh int Serial3/0/23:0

Interface and Line Protocol Status
Line State Possible Causes and Actions
Serial x is up, line protocol is up This status indicates that the interface is functioning properly
Serial x is down, line protocol is down This status indicates that the router is not sensing a carrier detect (CD) signal.

Possible Causes:

-Telephone company problem.
-Faulty or incorrect cabling
-Hardware failure

Suggested Actions:

-Check the LED’s on the CSU/DSU to see if the CD light is active.
-Verify that the cables are connected properly.
-Reset your equipment
-Contact your leased-line provider
-Replace faulty equipment

Serial x is up, line protocol is down Possible Causes:

-Local or remote router misconfigured
-Keep-alives not being sent by remote router
-Leased-line or other carrier service problems, such as noisy lines or faulty switch
-Timing problem on cable, possibly caused by the CSU/DSU not being set correctly.
-Failed local or remote CSU/DSU.
-Router failure.

Serial x is up, line protocol is up (looped) Possible Causes:

-Loop exists in the circuit. Contact your leased line provider or owner of remote router to remove loop.

Serial x is administratively down, line protocol is down. Possible Causes:

– Router configuration includes the shutdown interface configuration command.
– Duplicate IP address.

Hardware
This field describes the type of hardware that the interface is connected to. In this case, this Serial interface is part of a channelized T3.
Description
This field is simply used to describe the interface by the network administrator. It has not bearing on connectivity.
Internet address
This is the IP address and subnet mask assigned to the interface in question. In this case, the IP address is 207.199.99.137 and it has a subnet mask of 255.255.255.252.
MTU, BW, DLY, rely, and load

* MTU – Maximum Tranmission Unit. By default, this is 1500 bytes, which describes the largest packet that can be sent through the interface before the packet is fragmented.
* BW – Bandwidth. This field is defined by the network administrator and has no actual effect on the bandwidth of a line. It is simply used for describing the load on a specific interface.
* DLY – Delay. Amount of micro seconds of delay. I do not have any more information on this at this time.
* rely – Reliability. Reliability of the interface as a fraction of 255 (255/255 is 100% reliability), calculated as an exponential average over five minutes (default).
* load – Load Average. Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes (default).

Encapsulation and Loopback

* Encapsulation is the type of Data-Link encapsulation. This is commonly either PPP, HDLC (Cisco’s proprietary PPP), Frame-Relay, and ATM.
* Loopback specifies whether the loopback bit is set in the D channel signalling.

Last input

* The last input is the number of hours, minutes, and seconds since the last packet was successfully received by an interface. This is useful for determining when a dead interface.
* The last output is the number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface. This is useful for determining when a dead interface failed.
* The output hang is the number of hours, minutes, and seconds (or never) since the interface was last reset because of a transmission that took too long.

Last clearing

This shows the elapsed time, in seconds, since the last clearing of the interface counters that will be described in a later section on counters.
Output queue, input queue, drops

Number of packets in output and input queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets dropped due to a full queue. Output drops can be caused when the output media cannot accept frames and the output queue reaches the maximum value before it starts dropping packets. Output drops may not necessarily indicate a problem since an explorer frame being dropped because it has already traveled on a particular ring can increment the output drops counter. Increasing input drops on the other hand, can be serious and should be looked into carefully. Input drops can be caused by insufficient system buffers – see 0 no buffer in the show interfaces tokenRing 0 output above. The incrementing no buffer counter of the show interfaces output may correlate to the incrementing misses counter of the show buffers output, and the appropriate buffer pool may need to be tuned.
5 minute input/output rate

Average number of bits and packets received and transmitted per second in the last five minutes.
Counters

* Packets input – Total number of error-free packets received.
* Broadcasts – Total number of broadcast or multicast packets received.
* Runts – Number of packets discarded because they are smaller than the medium’s minimum packet size.
* Giants – Number of packets that are discarded because they exceed the medium’s maximum packet size.
* Throttle – This counter indicates the number of times the input buffers of an interface have been cleaned because they have not been serviced fast enough or they are overwhelmed. Typically, an explorer storm can cause the throttles counter to increment. It’s important to note that every time you have a throttle, all the packets in the input queue get dropped. This causes very slow performance and may also disrupt existing sessions.
* Parity – Number of parity errors on the HSSI.
* RX Disabled – Indicates inability to get a buffer when accessing a packet.
* Input Errors – Sum of all errors that prevented the receipt of datagrams. This may not balance with the sum of the enumerated output errors, because some datagrams may have more than one error and others may have errors that do not fall into any of the specific categories.
* CRC – Cyclic redundancy checksum generated mismatch. CRC errors also are reported when a far-end abort occurs and when the idle flag pattern is corrupted. This makes it possible to get CRC errors even when there is no data traffic.
* Frame – Number of packets received incorrectly having a CRC error and a noninteger number of octets.
* Overrun – Number of times the serial receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver’s ability to handle the data.
* Ignored – Number of received packets ignored by the interface because the interface hardware ran low on internal buffers.
* Abort – Number of packets whose receipt was aborted.
* Bytes – Total number of bytes, including data and MAC encapsulation, transmitted by the system.
* Underruns – Number of times that the far-end router’s transmitter has been running faster than the near-end router’s receiver can handle. This may never happen (be reported) on some interfaces.
* Congestion Drop – Number of messages discarded because the output queue on an interface grew too long.
* Output Errors – Sum of all errors that prevented the final transmission. This may not balance with the sum of the enumerated output errors, because some datagrams may have more than one error and others may have errors that do not fall into any of the specific categories.
* Interface Resets – Number of times an interface has been completely reset.
* Restarts – Number of times the controller was restarted because of errors.
* Carrier Transitions – Number of times the carrier detect signal of a serial interface has changed state.

[[Category:Cisco]]

Cisco IPIP Tunnels

Linux (192.168.2.1):

Cisco (192.168.1.1):

Cisco OSPF over GRE tunnel

Components Used

-Cisco 7206VXR (NPE200) Router <br/>
-Debian 2.6.8-1-386<br/>

Network MAP

The ideea of this plan is to see the network behind the 7200 Router on the Linux server using OSPF.

1. Private network has : 172.20.0.0/16<br/>
2. Cisco Router has several VLANs but Ill use only : 172.20.6.252/32 ( its the default GW for workstations) . Its real ip is : *.*.*.130/32<br/>
3. Firewall : the firewall blocks incoming connections from any "outside" host.<br/>
4. GRE tunnel : I
ve choosed 172.19.0.0/24 ( Linux will be 172.19.0.3 and Cisco will use : 172.19.0.2)<br/>
5. Linux server has on eth1 : *.*.*.131/32 and its default GW *.*.*.129/32<br/>
6. My workstation has : different ips..<br/>

== Checking connectivity ==

So as you probably see firewall is blocking connections.

== ACLS ==

== Configure Tunnel interface Cisco ==

== Linux server ==

/etc/network/interfaces

linux:~# /etc/init.d/networking restart

== Debug ==

So now we have our tunnel up and running.

== Configuring OSPF ==

[http://en.wikipedia.org/wiki/Open_Shortest_Path_First]
[http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ospf.htm]

=== Cisco ===

=== Linux ===

”’zebra.conf”’

So we`ve started recieving routes.. Now we can “see” all the network behind the Cisco router.

== Debugging ==

………………………………………..

An other way without configuring ospfd is to use iproute. Lets say you want to ssh to an server behind the Cisco Server :