engineering Journal

BGP local-as illustrated

2009-08-25T15:54:00.000-07:00

Behaviour of BGP 'local-as' feature. Local AS feature is applying on R2 toward R1 and on R3 toward R4.

router bgp 2013

neighbor 10.1.0.2 remote-as 10

neighbor 10.1.0.2 local-as 20

R2#show ip bgp neighbor 10.1.0.2 received-routes

Network Next Hop Metric LocPrf Weight Path

* 172.16.0.0 10.1.0.2 0 0 20 10 i

RIPE Policy Proposal 2005-12

2009-08-17T17:37:00.001-07:00

Summary of Proposal:

Background

Recent studies of AS Number consumption rates indicate that the existing 2-byte pool of unallocated AS Numbers will be exhausted sometime in the period between 2010 and 2016, absent of any concerted efforts of recovery of already-allocated AS Numbers [1] [2]. Standardisation work in the IETF has produced a document that is currently being submitted as a Proposed Standard that will expand the AS Number space to a 4-byte field [3].

It is noted that some advance period may be required by network operators to undertake the appropriate procedures relating to support of 4-byte AS Numbers, and while no flag day is required in the transition to the longer AS Number field, it is recognised that a prudent course of action is to allow for allocation of
these extended AS Numbers well in advance of an anticipated 2-byte AS Number exhaustion date.

This policy proposal details a set of actions and associated dates for RIR AS Number allocation policies to assist in an orderly transition to use of the 4-byte AS Number space.

The essential attributes of this policy proposal are to facilitate the ease of transitional arrangements by equipment vendors, network managers and network operations staff, to provide the industry with some predictability in terms of dates and associated actions with respect to registry operational procedures for AS Number allocations.

Nomenclature

It is proposed to identify 4-byte AS Numbers using a syntax of .. Accordingly, a 4-byte AS Number of value 65546 (decimal) would be identified as "1.10".

Terminology

"2-byte only AS Numbers" refers to AS Numbers in the range 0 - 65535

"4-byte only AS Numbers" refers to AS Numbers in the range 1.0 - 65535.65535 (decimal range 65,536 - 4,294,967,295)

"4-byte AS Numbers" refers to AS Numbers in the range 0.0 - 65535.65535 (decimal range 0 - 4,294,967,295)

MPLS Forwarding

2009-08-07T14:47:00.000-07:00

Those three LSRs will create their own label binding for each routes they have, including those 3 loopbacks.

RP/0/RP0/CPU0:CRS4B#sh mpls ldp bindings

10.1.1.4/32, rev 31

Local binding: label: 16005

Remote bindings:

LSR: 10.1.1.1:0, label: 16003

RP/0/RP0/CPU0:CRS4A#sh mpls ldp bindings

10.1.1.4/32, rev 142

Local binding: label: 16003

Remote bindings:

LSR: 10.1.1.4:0, label: IMP-NULL

LSR: 10.1.1.2:0, label: 16005

RP/0/8/CPU0:XR12410#sh mpls ldp bindings

10.1.1.4/32, rev 2

Local binding: label: IMP-NULL

Remote bindings:

LSR: 10.1.1.1:0, label: 16003

Each router will pick label for each routes, and then advertise this route to its neighbor.

RP/0/RP0/CPU0:CRS4B#ping mpls ipv4 10.1.1.4 255.255.255.255

Fri Aug 7 11:18:38.978 PST

Sending 5, 100-byte MPLS Echos to 10.1.1.4/32,

timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 6/17/59 ms

RP/0/RP0/CPU0:CRS4B#traceroute 10.1.1.4

Fri Aug 7 12:25:05.928 PST

Type escape sequence to abort.

Tracing the route to 10.1.1.4

1 5.1.1.1 [MPLS: Label 16003 Exp 0] 64 msec 4 msec 1 msec

2 23.23.23.3 62 msec * 7 msec

RP/0/RP0/CPU0:CRS4B#traceroute mpls ipv4 10.1.1.4 255.255.255.255

Fri Aug 7 12:25:52.121 PST

Tracing MPLS Label Switched Path to 10.1.1.4/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 5.1.1.2 MRU 1500 [Labels: 16003 Exp: 0]

L 1 5.1.1.1 MRU 4470 [Labels: implicit-null Exp: 0] 125 ms

! 2 23.23.23.3 8 ms

IP Multicast Multipath

2009-08-07T14:26:00.001-07:00

Multicast traffic will be handled as follows:

SAME source to SAME group will be forwarded to only 1 path
MANY sources to SAME group will be load-balanced
SAME source to MANY groups will be forwarded to only 1 path

Multicast multipath is useless on the shared tree.

Shaping and Policing

2009-07-23T15:25:00.001-07:00

What is the difference between policing and shaping? Below is the answer.

taken from: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

SONET Events and Alarms

2009-04-28T17:26:00.000-07:00

SONET equipment detects events and alarms at each of SONET's three layers : section, line, and path.

Alarm Type --- Section of Loss of Signal

Severity : Critical

Triggers : A sonet link must see a certain number of digital bit transitions (from 1 to 0 and 0 to 1) in order to ensure proper syncronization. LOS is declared when no bit transitions are detected on the incoming signal (before descrambling) for 2.3 to 100 microseconds. The LOS defect is cleared after a 125-microsecond interval (one frame) during which no LOS defect is detected.

Note: LOS typically occurs in back-to-back lab setups because the receiver is saturated with too much light, particularly when long-reach single mode interfaces are used. Try to attenuate the signal.

Troubleshoot :

1. Check the fiber optic cable in order to make sure it is plugged in.

2. Verify that the local fiber optic cable is not damaged. Look for breaks or physical abnormalities.

3. Make sure that the remote end of the fiber optic cable is connected, undamaged and that the remote port is configured properly.

4. Try a soft loopback with the loopback internal command.

5. Try a hard loopback. Connect the transmit to receive with a single fiber strand.

6. Determine whether the POS interface simply receives too little or too much light.

Alarm Type --- Section of Loss of Frame

Severity : Critical

Triggers : The A1 and A2 bytes in the section overhead provide frame alignment with a particular bit pattern. A receiving interface delcares LOF after it detects errors in the framing pattern for three miliseconds. LOF is cleard when two consecutive valid A1/A@ framing patterns are received.

Troubleshoot :

1. Check the fiber optics cable in order to make sure the cable is plugged in and is not damaged.

2. Ensure the framing format on the port matches the format configured on the line.

Alarm Type --- Alarm Indicate Signal - Line (LAIS)

Severity : Major

Triggers : LAIS is sent by the section terminating equipment (STE) to alert the downstream line terminating equipment (LTE) that a LOS or LOF defect has been detected on the incoming SONET section. Upstream STE generates line AIS to downstream LTE by setting bits 6, 7, and 8 of the K2 byte to 111.

Troubleshoot:

1. Verify that the remote configuration is correct.

2. Check the line status at the remote end of the link.

Alarm Type --- Remote Defect Indication - Line (LRDI)

Severity : Major

Triggers : RDI alarms are always reported upstream from the detecting device. LRDI specifically comes back in the K2 bits 6-8 and overrides any existing Automatic Protection Switching (APS) modes: (APS 1+1) or APS status (BLSR). AIS-L is also sent in bits 6-8 and is generally sent from a SONET regenerator or other STE.

Troubleshoot:

RDI—Line problems arise from the remote interface. Check the remote site for alarm conditions.

Alarm Type --- Alarm Indicate Signal - Path (PAIS)

Severity : Minor

Triggers : An upstream LTE that receives LAIS then sends path AIS to the downstream PTE by setting H1 and H2 bytes. The purpose is to alert the downstream PTE of a defect on the upstream LTE's incoming line signal.

Troubleshoot:

This is sent by a site that has received LAIS. This is a minor warning, and no action needs to be taken except to monitor the far end.

If the alarms are persistent, verify the interface configurations on both ends of the trunk.

Alarm Type --- Remote Defect Indication - Path (PRDI)

Severity : Minor

Triggers : Path Remote Defect Indicator (PRDI) is used only at the path level. A problem at the path layer prompts PAIS to be sent downstream and PRDI to be sent back upstream to let the traffic provider know that there is a problem with their circuit down stream.

Troubleshoot:

A PRDI alarm usually indicates a problem two sites away. If the alarm is persistent, check the alarm status of neighboring sites, beginning with the nearest neighbor.

Dealing with Large Configurations

2009-04-23T17:22:00.000-07:00

When the NVRAM is not large enough to store the router configuration there is an option which allows the configurationto be compressed (using a gzip like compression algorithm):

service compress-config

Only use this if there is a requirement to. If the existing NVRAM can hold the configuration uncompressed, do not use thisfeature. Some ISPs have extremely large configurations and this feature was introduced to assist them.

Furthermore, if the router configuration has become very large it is worth checking whether some of the newer IOSfeatures can be used. One example would be using prefix-lists instead of access-lists; the former is more space efficient inNVRAM, and also is more efficient in operation

MPLS for dummies

2009-04-02T11:30:00.000-07:00

Apa sih MPLS? Pertanyaan ini dulu pernah gw tanya ke diri sendiri, tapi setelah baca buku dan RFC, bisa gw simpulkan bahwa MPLS itu adalah metode packet forwarding yang lebih efisien. Kenapa bisa efisien, nah mari kita dengar ceritanya.

Overview

Dalam packet forwarding konvensional, router menentukan kemana packet akan di forward berdasarkan informasi Layer 3 header packet tersebut. Paling umum informasi layer 3 yang dipakai adalah destination ip address. Berdasarkan destination ip address, router akan mencari match dalam internal routing table, kemudian akan memproses packet tersebut untuk kemudian meneruskan packet tersebut ke next-hop. Proses ini dapat dibagi menjadi 2 macam proses. Pertama, menentukan FEC (Forwarding Equivalence Classes) dari packet tersebut. Kedua, melakukan mapping dari FEC ke next-hop.

Nah, dalam implementasi konvensional, setiap hop akan melakukan proses penentuan FEC. Jika ada 3 router antara source dan destination, maka setiap packet akan diproses di ketiga router tersebut untuk menentukan FEC, dan kemudian mapping FEC ke next-hop.

Tetapi dalam MPLS, proses penentuan FEC dilakukan hanya sekali ketika packet memasuki network MPLS. Selanjutnya, forwarding packet dilakukan dengan mekanisme label. Ketika packet sudah dimasukkan kedalam satu FEC, maka label akan dibinding dalam packet tersebut, untuk kemudian packet dengan label dikirim ke next hop. Forwarding packet dilakukan oleh router kedua berdasarkan label, sampai packet keluar dari cloud MPLS.

Dengan demikian, analisis IP header dan algoritma routing tidak perlu dilakukan lagi di setiap router dalam cloud MPLS (kecuali router pertama). Hal ini memberikan keuntungan yaitu:

MPLS forwarding dapat dilakukan oleh switch, yang notabene tidak bisa melakukan analisis layer 3 IP header.
Penentuan FEC yang dilakukan oleh router pertama, maka router pertama memiliki kekuasaan yang absolut untuk menentukan FEC. Penentuan ini bisa saja dilakukan tidak berdasarkan IP header, tetapi berdasarkan source port.
Bila ada dua packet yang sama (IP header sama), tetapi masuk melalui router yang berbeda, penentuan path bisa berbeda. Hal ini tidak bisa dilakukan di routing konvensional, karena informasi source router tidak ada dalam IP header.
Penentuan FEC bisa dibuat berdasarkan parameter yang kompleks. It's ok, karena setelah itu router berikutnya hanya forward berdasarkan label.
Penentuan path dapat dilakukan sesuka hati, tanpa bergantung dengan routing protocol yang ada. Ini disebut dengan traffic engineering.

QoS dalam MPLS dapat diberlakukan. Informasi Precendence dari IP header dapat di copy ke dalam label. Untuk kemudian, router berikutnya akan memberlakukan DiffServ berdasarkan label. Jadi, label itu berisi informasi FEC dan precendence/class of service.

MPLS support semua network layer protocol. Karena itulah dinamakan 'Multiprotocol' Label Switching. Setiap router yang support MPLS disebut Label Switching Router (LSR).

MPLS Basics

Label

Label adalah indentifier yang diberikan oleh LSR untuk menentukan FEC dari packet tersebut. Label bersifat locally significant, jadi bisa jadi label 100 dipakai untuk menentukan FEC X, tetapi LSR yang lain menggunakan label 100 untuk FEC Y. Besarnya label ini fix dan pendek.

Biasanya label diassign ke packet berdasarkan network header dari packet tersebut.

Jika Ru dan Rd adalah LSR, maka keduanya harus melakukan perjanjian yang menyatakan, jika incoming label di Rd adalah U untuk FEC F, maka Ru harus setuju bahwa outgoing label U adalah untuk FEC F dengan next hop Rd. Label U adalah label yang di binding ke FEC F, dan locally significance untuk Ru dan Rd.

Service Nagle - RFC 896

2009-03-19T16:37:00.001-07:00

The Nagle congestion control algorithm is one feature that is proven useful to improve the performance of telnet session to and from the router. Standard TCP implementation will send one packet for every keystroke typed. This can use up bandwidth and contribute congestion, especially in larger network.

John Nagle proposed the algorithm, as documented in RFC 896, to alleviate the small-packet problem in TCP. The way it works is in this way:

- It will send one packet for the first keystroke after connection establishment. But, TCP holds any additional characther typed until receiver acknowledges the first packet.

- Then, larger packet is send, and additional typed characters are saved until the acknowledgement comes back.

This mechanism is to accumulate characters into larger chunks, and pace them our of the network at a rate matching the round-trip time of the given connection. This feature is basically good for all TCP-based traffic

cisco command to enable this: service nagle

Private Vlan illustrated

2009-02-16T17:21:00.001-08:00

The concept of Private Vlan is complicated to understand, even I had to take some time to understand. After reading over and over again, I immediately wrote on my note so I won't be coming to the white paper again in case I can not recall the concept.

Figure above shows that vlan 20 is community vlan, vlan 120 is private. Vlan 100 and 200 is primary vlan. Both community and isolated vlan reside in their primary vlan. Neighbor switch or host knows only primary vlan, while community and isolated vlan are transparent.

Hosts in community vlan are able to communicate between each other. Hosts in isolated vlan are not allowed to communicate each other.

Community and isolated vlan are able to communicate to their gateway through promiscuous port. There are two types of promiscuous port, promiscuous port and promiscuous trunk port.

Basic config is below:

vlan 100

private-vlan primary

private-vlan association 10 20

vlan 200

private-vlan primary

private-vlan association 101 120

vlan 10

private-vlan community

vlan 20

private-vlan community

vlan 101

private-vlan isolated

vlan 120

private-vlan isolated

interface gigabitethernet 2/20

switchport mode private-vlan prosmiscuous

switchport private-vlan mapping 100 10

interface gigabitethernet 2/21

switchport mode private-vlan host

switchport private-vlan host association 200 101

interface gigabitethernet 2/20

switchport mode private-vlan trunk prosmiscuous

switchport private-vlan mapping trunk 200 101

switchport private-vlan mapping trunk 100 20

When does IGMP Snooping kick in ?

2009-02-16T11:45:00.000-08:00

IGMP Snooping will kick in under this circumstances:

Switch receive IGMP Join message from host.
Switch detect Multicast router by receiving IGMP General Query message.

Unless switch detect both packets above, all multicast streams will be flooded to all ports.

Virtual Switching System

2009-02-10T21:37:00.000-08:00

I receive this news yesterday, and immediately read thoroughly on this. One word to describe this feature: SIMPLICITY. Yes, it eliminates complexity of redundant switching core, which is already complicated for both designer and administrator.

In current implementation of redundant switching core, which reside in distribution or core layer, usually network designer put Layer 2 link between two redundant switch. There is another alternatives, that is by using layer 3 link between two redundant switch, yet this topology is rarely deployed in live network.

Layer 2 link between two redundant switch creates redundant gateway for each Vlan, and this configuration relies on high-availability feature such as, HSRP, VRRP, or GLBP. Spanning tree protocol is important in this scenario as well, because it dictates which link will be put in forwarding and blocking. Network designer must realize that manually specifying root bri

dge is the first thing needs to be considered. As a kn

own rule, one of the core switch should be a root bridge. Why? to make sure high-availability feature send its hello protocol via link between two redundant switch. So, in traditional core switch, we must have spanning-tree protocol, high-availability feature, and at least 2 ip addresses for the gateway (if we use VRRP). Traditional deployment is illustrated below.

Now, VSS come up to simplify this complicated core switch. It does:

Form two core switches to be one virtual switch. As a result, we have only one gateway ip address, instead of two. It removes the need to configure two switched if there are configuration and policy changes.
There is no need of high-availability feature, thus removes HSRP, VRRP, or GLBP.
Etherchannel is needed between VSS switch and lower layer switch. This etherchannel will eliminate vlan-based load balancing, and deterministic load-balancing will be possible.
No spanning-tree.

To sad, Cat4k has no this feature yet.

sekian dulu..

IGMP Switch Querier

2009-02-05T18:13:00.000-08:00

Problem Definition
IGMP switch querier is a feature that works on top of IGMP snooping functionality, and assists IGMP snooping so that it can work properly. In order to understand the necessity of this feature, we need to understand how IGMP snooping works.

IGMP snooping helps layer 2 switch to prune the flooding of unwanted multicast traffic on each switch port. Without enabling IGMP snooping on layer 2 switch, multicast traffic by default will be flooded to all layer 2 ports which has same vlan with the incoming multicast source port. IGMP snooping is made to lessen this inefficent, bandwith-consuming traffic. How does igmp snooping know to which port multicast traffic should be flooded? There are two ways, one is by receiving IGMP join message from host, and second is by receiving IGMP Query Message from Multicast router. IGMP join message lets switch know that certain ports is subscribing multicast groups, and multicast traffic should be flooded to this port. IGMP Query Message lets switch know where the Multicast router is, and it will forwards all IGMP join messages to this port.

This igmp snooping works pretty smooth in multicast network, where it has Multicast router attach to the layer 2 network. Multicast router has reponsibility to send IGMP General Query to the network, querying all hosts if they still have interest to receive multicast groups or not. Layer 2 switch floods this IGMP general Query to all layer 2 ports, and waiting host's response. Upon receiving Query message from Multicast router, host will send IGMP join message to multicast router to inform its presence and which group it wants to join. This is where IGMP snooping kicks in, that is by receiving IGMP join from host, igmp snooping taking a note and updating its snooping table. Multicast router keeps sending query message periodically, and host keeps sending response periodically, hence igmp snooping keeps updating its snooping binding table periodically, then switch is able to prune unwanted traffic properly.

Now, how about in the network which has no Multicast router? If there is no multicast router, then there is no Query message. If there is no query message, then there is no way for hosts to send IGMP join message. If host does not send IGMP join message, snooping binding table will obsolete, because there is no information from host.

This situation happens in Layer 2-only network with layer 2 switch, where multicast router is absence. So, there is a need for layer 2 switch to have equivalent function to generate General Query in the network. Hereafter such functionality is referred to as the IGMP switch querier.

Functionality
This switch querier follows querier election rules stated in RFC 2236. Some rules are

Querier candidate should yield to another candidate iwth a lowe rIP address. In other word, lower ip address switch is the winner and become Switch Querier
Switch generates General Query periodically based on configured parameters.
Since IGMP siwtch querier is designed for layer 2 environment, there is no DR-related issue.
When switch querier is operating in the non-querier state, it monitors General Query on the network. If it does not hear a General Query from a lower IP address querier for a querier-timeout interval, it will start transmitting General Query and become a Querier.
At least one ip address must be configured in the switch, or manually provisioned. If there is no source IP address, Querier will not generate any IGMP General Query messages.

Command to enable/disable IGMP switch querier:

Switch(config-vlan)# ip igmp snooping querier
Switch(config-vlan)# no ip igmp snooping querier

ATM config in IOS and IOX

2009-02-04T21:28:00.000-08:00

Straight to the point.

Config on IOS

interface ATM0/1
no ip address
no ip directed-broadcast
atm clock INTERNAL
atm enable-ilmi-trap
atm ilmi-keepalive
!
interface ATM0/1.101 point-to-point
ip address 214.5.0.6 255.255.255.252
no ip directed-broadcast
no atm enable-ilmi-trap
bfd interval 82 min_rx 82 multiplier 3
pvc 1/101
oam-pvc manage
!

Config on IOX

interface ATM0/4/0/1
atm ilmi-keepalive
mtu 4478
!
interface ATM0/4/0/1.101 point-to-point
pvc 1/101
oam-pvc manage
!
ipv4 address 214.5.0.5 255.255.255.252
!

That’s it. I still have no time to explain in detail, what meaning of each command.

G. Polya, How to Solve it

2009-02-04T13:25:00.000-08:00

UNDERSTANDING THE PROBLEM
- First. You have to understand the problem.
- What is the unknown? What are the data? What is the condition?
- Is it possible to satisfy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory?
- Draw a figure. Introduce suitable notation.
- Separate the various parts of the condition. Can you write them down?
DEVISING A PLAN
- Second. Find the connection between the data and the unknown. You may be obliged to consider auxiliary problems if an immediate connection cannot be found. You should obtain eventually a plan of the solution.
- Have you seen it before? Or have you seen the same problem in a slightly different form?
- Do you know a related problem? Do you know a theorem that could be useful?
- Look at the unknown! And try to think of a familiar problem having the same or a similar unknown.
- Here is a problem related to yours and solved before. Could you use it? Could you use its result? Could you use its method? Should you introduce some auxiliary element in order to make its use possible?
- Could you restate the problem? Could you restate it still differently? Go back to definitions.
- If you cannot solve the proposed problem try to solve first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Could you solve a part of the problem? Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary? Could you derive something useful from the data? Could you think of other data appropriate to determine the unknown? Could you change the unknown or data, or both if necessary, so that the new unknown and the new data are nearer to each other?
- Did you use all the data? Did you use the whole condition? Have you taken into account all essential notions involved in the problem?
CARRYING OUT THE PLAN
- Third. Carry out your plan.
- Carrying out your plan of the solution, check each step. Can you see clearly that the step is correct? Can you prove that it is correct?
Looking Back
- Fourth. Examine the solution obtained.
- Can you check the result? Can you check the argument?
- Can you derive the solution differently? Can you see it at a glance?
- Can you use the result, or the method, for some other problem?

Policy-based Routing scenario

2009-02-04T03:36:00.000-08:00

I got a phone call from customer when I was working as network engineer back in Indonesia. It was at 10 pm at night when they called, and they were puzzled with routing problem in their backbone. This is the problem description. Each site has 2 upstream connections. Voice traffic should be forwarded thru 1st link, and data traffic should be forwarded thru 2nd link. Routing protocol is impotent to this problem, since the decision can only be made based on layer 3 information on each packet. This is where Policy Based Routing needs to kick in, using its privilege to control the decision based on layer 3 to layer 7 information.

This is the problem; PBR does not have capability to detect the death of next hop interface, so router will forward the matched packet to the dead interface, and resulting dropping the packet in queuing buffer. Starting from IOS 12.3(4)T, Cisco had added new feature to check availability of next hop interface before forwarding the packet. This feature is only available when PBR is enabled.

Router Site has 2 upstream neighbors. Site router has responsible to manage the traffic forwarding, which is Voice traffic should be forwarded to R1 while Data traffic should be forwarded to R2. To do this fancy routing job, interface in router Site should to be configured with PBR feature which allows routing decision to be done by PBR first instead of CEF, and this affects to all incoming traffic on corresponding interface. Basically, every incoming packet to this interface will be switched by PBR policy lookup, if the packet has no match in PBR policy, CEF forwarding will do the job as it is intended to be.

In this case, I configured the PBR policy to match both traffic. This is simply by configuring Voice traffic to be forwarded to R1, while non-voice traffic to be forwarded to R2. So, we have 2 cases here: voice traffic and non-voice traffic.

For voice traffic, R1 is the next-hop based on PBR policy, regardless whether R1 is alive or not. New feature has responsibility to track the status of R1 interface, thus it can inform the PBR to change its policy once the R1 interface found to be dead. If R1 interface happens to be dead, PBR will check if another next hop is configured. If it is configured and alive, packet will be forwarded to this new next-hop. It no other next hop configured, forwarding decision will be done by CEF.

For non-voice traffic, the concept is the same.

For the configuration of site router, you can see below.

Cisco NSF (Nonstop Forwarding)

2009-02-03T18:40:00.001-08:00

Cisco Nonstop Forwarding is a feature that allows backup supervisor to keep forward the traffic while the active supervisor is down, due to switchover or failure. Without this feature, backup supervisor will not have route entries in its forwarding table, hence there is no way for router to switch the incoming traffic. CEF is a forwarding switching algorithm for most Cisco products. CEF, which is most advanced of forwarding mechanism, is vital component for forwarding. CEF builds its table as a reference for supervisor in order to do its duty as traffic forwarder. The forwarding/CEF table is built by copying each entries in the routing table, which is build by Cisco software. The entries in routing table depends on the routing protocol that is running on the system, and each routing protocol participate in establishing the routing table. Now, if the supervisor fails, then the process inevitably will fail, therefore the routing protocol adjacency also fails. When the routing protocol adjacency fails, then the routes in routing table is wiped off. And because of synchronization between CEF ans routing table always occur all the time, route entries in CEF will be wiped off as well. This is the main reason why backup supervisor drops the traffic until the routing protocol recovered their adjacencies.

NSF allows to maintain CEF table for some periods of time, while routing protocol builds the adjacency and recovers the routing table.

Cisco NSF has two primary components:
1. NSF-awareness
This the capability for a router to be able to forward the traffic to its neighbor, while switchover is taking place. The neighbor should be an NSF-capable.

2. NSF-capable
This is the capabiity for a router to minimize the downtime during switchover. This NSF-capable router will inform to all its neighbor that he is capable to forward the traffic if switchover take place. Only the NSF-aware and NSF-capable neighbor which will still forward the traffic down to this router.

NSF provides these benefits:

• Improved network availability

NSF continues forwarding network traffic and application state information so that user session information is maintained after a switchover.

• Overall network stability

Network stability may be improved with the reduction in the number of route flaps, which were created when routers in the network failed and lost their routing tables.

• Neighboring routers do not detect a link flap

Because the interfaces remain up during a switchover, neighboring routers do not detect a link flap (the link does not go down and come back up).

• Prevents routing flaps

Because SSO continues forwarding network traffic during a switchover, routing flaps are avoided.

• Maintains user sessions established prior to the switchover

Creative answer

2009-02-02T13:49:00.000-08:00

Got these stuffs from my friends. Some of the answers are so creative, so smart. If I was a teacher, I would call him, and saluted to them. They were thinking differently compared to normal man, and created such a funny answer, yet creative.

One of the best answer is below..

Multiple Multicast Router on Broadcast Network

2009-02-02T00:39:00.000-08:00

If there are more than one router connected to same subnet, it needs mechanism for router to elect who forward multicast traffic to subnet. It is not efficient if there are two routers forward same multicast traffic on same time, on same subnet.

One way to ensure only one router forward the traffic onto the subnet is to add a designated router, or querier, function to multicast routing protocol. The querier is responsible for forwarding the multicast stream. The other router or router only listen, and they begin forwarding the stream only if the querier fails.

MAC Address Filtering

2009-02-01T00:07:00.000-08:00

MAC Address Filtering is a feature to filter frame based on their mac-address, and it is intended only for non-IP packet. So, be careful, if IP packet pass through an interface configured with MAC access-list, the packet will not hit the list.

example to deploy mac address filtering:

int Fa0/7
mac access-group YES in
!
mac access-list extended YES
deny host 000d.2998.4f80 any
permit any any
!

Troubleshooting CEF Forwarding

2009-01-31T23:52:00.000-08:00

Step 1: Accurately describe the problem and scoping the network topology
Visual topology is needed whenever we are going to narrow down the problem in our complex network. But, if we have already localized the issue in one specific router and switch, then we can skip scoping the network topology.

Step 2: Review the OSI model
This approach is to isolate the problem effectively. There are three approaches that are recommended, i.e bottom-up approace (start from lowest layer to layer 7), up-bottom approach (start from layer 7 to layer 1), and break-down approach (start from any layer we suspect, then either going down or up).
Engineers usually use first approach, as it has been known as more effective.

There are some commands that is useful for troubleshooting Layer 1 (physical connectivity). They are "show" command and "debug" command. Many times debug command is not being used, unless show command does not give us the information we need. Show interfaces command is to verify the physical connectivity, to verify input errors, cyclic redundancy check (CRC) errors, output errors, excessive collisions, overruns, late collisions, or output buffer failures.

Step 3: Verify ARP table
You have to verify on both devices that are connected back-to-back. "sh arp" is what you need if it is IOS, and "arp -a" if it is Windows OS.

Step 4: Verify IP Routing table
checking the entry of routing table.

Tips: we can use ping with record option to rule out CEF, to make sure if the problem is in CEF or routing table. If an ICMP echo with the record option is succesful and a standard ICMP echo is not, you can assume with some certainty that CEF is indeed is broken somewhere along the path.

Step 5: Verify CEF FIB table
You have to verify CEF configuration, whether this has been run or not. "show ip cef" is to verify that CEF is enabled globally and per-interface. If it is needed, issue command "show ip interface XX" to verify if CEF is enabled on that interface.
Then we need to verify the switching path of the router. Make sure the packets are being CEF switched, instead of fast-switched or software switched. "show interface stat" and "show ip cache" can show us if the packet is hardware-switched or software-switched.

Step 6: Verify adjacency table
use "show adjacency" command to verify this.