Thursday, December 31, 2009

Gus Dus Biography

Former President of Indonesia to 4 Abdurrahman Wahid, often called Gus Dur (born in Jombang, East Java, September 7, 1940, and died in Jakarta, December 30, 2009 at age 69 years).

He is a Muslim of Indonesian kiai and political leader who became president of Indonesia from 1999 to 2001. He succeeded President BJ Habibie after elected by the People's Consultative Assembly (MPR) 1999 election results.

Implementation of government assisted the National Unity Cabinet. Abdurrahman Wahid's presidency begins October 20, 1999 and ended after transmitted through the Special Session of the Assembly in 2001.

Right July 23, 2001, his leadership was replaced by Megawati Sukarnoputri after the mandate was revoked by the Assembly.

Abdurrahman Wahid is the former chairman of Tanfidziyah (executive body) NT NU and founder of the National Awakening Party (PKB).

Gus Dur was born on the 4th and 8th month of Islamic calendar year 1940 in the village of Denanyar, Jombang, East Java, from pair Wahid Hasyim and Solichah.

There is a belief that he was born on August 4, but the calendar used to mark the day of birth is the Islamic calendar, which means he was born on 4 Sha'ban, equal to September 7, 1940.

He was born with the name of Abdurrahman Addakhil. "Addakhil" means "The Conqueror". The word "Addakhil" is not well known, and changed the name of "Wahid", and then better known as Gus Dur calls.

"Gus" is a typical boarding school honor calls to a child kiai means "brother" or "mas".

Gus Dur is the first son of six children. Wahid was born from a very respectable family in the Muslim community of East Java. Grandfather from his father is KH Hasyim Asyari, founder of Nahdlatul Ulama (NU), while the maternal grandfather, KH Bisri Syansuri is the first boarding school teacher who teaches classes on women.

Father Gus Dur, the KH Wahid Hasyim, was involved in the nationalist movement and became Minister of Religious Affairs in 1949. Her mother, Mrs. Hj. Sholehah is the daughter of the founder of Pesantren Denanyar Jombang.

Gus Dur has openly stated that he had blood Tionghoa. He claimed descent from Tan Kim Han who is married to Tan A Lok, siblings Raden Patah (Tan Eng Hwa), founder of the Sultanate of Demak.

A Lok Tan and Tan Eng Hwa is a son of Princess Campa, daughter of a concubine China Raden Brawijaya V.

Tan Kim Han himself and based on studies of a French researcher, Louis-Charles Damais, identified as Sheik Abdul al-Shini Qodir the grave was found in the area Trowulan, East Java.

In 1944, Wahid moved from Jombang to Jakarta, where his father was elected as Chairman I Masyumi Party of Indonesia (Masyumi), an organization that stands with the support of the Japanese army occupied Indonesia.

After the declaration of Independence of Indonesia on August 17, 1945, Wahid returned to Jombang and remained there during the war of independence against the Dutch Indonesia.

At the end of 1949, Wahid moved to Jakarta, and his father was appointed as Minister of Religious Affairs. Abdurrahman Wahid studied in Jakarta, went to primary school before moving to KRIS SD Matraman Perwari. Wahid was also taught to read non-Muslim books, magazines, and newspapers by his father to expand his knowledge.

Wahid continued to live in Jakarta with his family although his father was not a minister of religion in 1952. In April 1953, Wahid's father died from a car accident.

Wahid continued education and in 1954, he entered the Junior Secondary School. In that year, he did not take the class. His mother then sent Gus Dur to Yogyakarta to continue his education. In 1957, after graduating from junior high, Wahid moved to Magelang to start education in pesantren Tegalrejo Muslims. He developed a reputation as a gifted student, completing the pesantren in two years (instead of four years). In 1959, Wahid moved to Tambakberas Pesantren in Jombang. There, while continuing his own education, Abdurrahman Wahid also received his first job as a teacher and later as head of the madrassa schools. Gus Dur is also employed as a journalist magazines like Horizon and Culture Magazine Jaya.

Overseas Education

In 1963, Wahid received a scholarship from the Ministry of Religious Affairs to study at Al Azhar University in Cairo, Egypt. He went to Egypt in November 1963.

Although he was proficient in Arabic, Wahid was told by the university that he had to take remedial classes before studying Islam and Arabic. Unable to provide proof that he has the ability Arabic, Wahid was forced to take remedial classes.

Abdurrahman Wahid began to enjoy living in Egypt in 1964, watching the European and American films, and also watch the football. Wahid was also involved with the Indonesian Student Association and became the association's magazine journalist.

At the end of the year, he successfully passed the remedial class was Arab. When he began his studies in Islam and Arabic in 1965, Wahid was disappointed. He has studied many of the materials provided and refuse to learn the methods used by the university.

In Egypt, Wahid was employed at the Embassy of Indonesia. By the time he worked, Movement event occurred 30 September 1965. Major General Suharto in Jakarta to handle the situation and the efforts made to eradicate communism.

As part of these efforts, the Indonesian Embassy in Egypt was ordered to conduct investigation on university students and provide reports on their political stance. This command is given to Wahid, who was assigned to write a report

But it can be said Wahid failed in Egypt. He did not agree with the method of education and work after the G 30 S / PKI which distracted him.

In 1966 he was told that he had to repeat. Wahid's tertiary education be saved through scholarship at the University of Baghdad. Wahid then was later moved to Iraq and enjoying his new environment.

Although he failed at first, Wahid quickly learned. He also continued his involvement in the Indonesian Students Association and also wrote the association's magazine.

After completing his education at the University of Baghdad in 1970, Wahid went to Holland to continue his education. Wahid wants to study at the University of Leiden, but was disappointed that his education at the University of Baghdad is less recognized. From the Netherlands, Wahid went to Germany and France before returning to Indonesia in 1971.

Early Career

Wahid returned to Jakarta and expect he will go abroad again to study at McGill University in Canada. It's kept himself busy by joining the Institute for Research, Education and Economic and Social Information (LP3ES), an organization comprised of Muslim intellectuals and progressive social democrats.

LP3ES then founded a magazine called Prisma, and Wahid became one of the main contributors to the magazine. In addition to working as a contributor LP3ES, Wahid was also around the pesantren and madrasah throughout Java.

At that time, boarding schools struggling to get funding from the government by adopting the government curriculum. Wahid was concerned that the conditions for the traditional values of the fade due to boarding school this change.

Wahid was also concerned with the poverty he saw the pesantren. At the same time when they persuaded the government boarding schools to adopt curricula, the government is also encouraging pesantren as agents of change and assist the government in the economic development of Indonesia. Wahid decided to drop plans for overseas studies in favor of developing the pesantren.

Abdurrahman Wahid then continued his career as a journalist, and writes for Tempo magazine and newspaper Kompas. The article was well received, and he began to develop a reputation as a social commentator.

With the popularity of that, he was invited to give lectures and seminars, forcing him to travel back and forth between Jakarta and Jombang, where Wahid lived with his family.

Despite having a successful career at that time, Gus Dur was still found it hard to live only from one source of livelihood, and he worked to earn additional income by selling peanuts and delivering ice to be used in her businesses Es Lilin.

In 1974 Wahid was an additional job as a teacher in Jombang in Pesantren Tambakberas, and soon developed a personal reputation. One year later, Wahid add jobs to become teachers Kitab Al Hikam.

In 1977, joined the University of Wahid Hasyim Asyari as Dean of the Faculty of Islamic practice and belief. Once again, Wahid was his job and the universities that want to Wahid to teach additional subjects such as pedagogy, Islamic Shari'a and missiology.

But the excess lead to resentment by some universities, and Wahid was blocked for teaching these subjects. While undertaking all these, Wahid was also addressed during Ramadan at the Muslim community in Jombang

NU
Zahid's family background and then quickly become meaningless. He will be asked to play an active role in running the NU. This ran contrary to the aspirations of Gus Dur in a public intellectual, and he had twice rejected offers to join the Religious Advisory Council of NU.
However, Wahid finally joined the board after his grandfather, Bisri Syansuri, gave him a third bid. Since taking this job, Wahid also choose to move from Jombang to Jakarta and stayed in the capital. As a member of the Religious Advisory Council, Wahid himself as a reformer to lead NU.
At Dur ituGus also got his first political experience. In legislative elections in 1982, Wahid was campaigning for the United Development Party (PPP), an Islamic party that was formed as a result of a merger of four Islamic parties, including NU.
Wahid said that the government interfere with the PPP campaign by arresting people like him. However, Wahid always managed to escape because they have relationships with important people, among them the General Benny Moerdani.

Election 1999 and the MPR

In June 1999, PKB participate in the legislative election arena. PKB won 12 percent of the vote, while the PDI-P won with 33 percent of the vote Raihan.
With the victory party, Megawati will win the election expected in the MPR president. However, the PDI-P does not have a full majority, thus forming an alliance with PKB.
In July, Amien Rais forming the Central Axis, a coalition of Islamic parties. Central Axis then began nominated Gus Dur as a third candidate in the presidential elections, and the commitment of PKB to the PDI-P began to change.
On October 7, 1999, Amien and Central Axis officially declared candidate Abdurrahman Wahid as president. On October 19, 1999, the Assembly rejected Habibie's accountability speech, and Habibie had to withdraw from the presidential election.
A few moments later Akbar Tanjung, Golkar Party Chairman and Chairman of the House declared that Golkar would support Gus Dur. On October 20, 1999, the Assembly re-assembled and began to elect a new president. Abdurrahman Wahid and Indonesia was elected as President of the 4th with 373 votes, while Megawati won only 313 votes.
Not happy because their candidates failed to win the election, Megawati supporters raged, Gus Dur and Megawati must realize that the elected vice president.
Once convinced, General Wiranto, to not participate in the election of vice-president and make the PKB supports Megawati, Gus Dur had managed to convince Megawati to participate.
On October 21, 1999 participate in the election of Megawati's vice president and defeated Hamzah Haz of the PPP



Friday, December 04, 2009

Dispelling LTE Myth

Myth 1: LTE is Data only

Reality: LTE supports voice and efficient support of voice was one of the key considerations in designing LTE. The voice solution for LTE is IMS VoIP and it is fully specified.

The 3GPP solution for voice over LTE is a combination of multiple efforts:

  • The work in Rel 7 to optimize IMS signalling and VoIP encoding so it would be as good or better than CS voice in terms of quality and efficiency,
  • The work in Rel 8 to develop a radio and core network evolution optimized for the transfer of packet data.
  • The work in Rel-7 to add the IMS emergency call requirements and to adapt it to regulatory requirements in LTE and GPRS in Rel-9.
  • The work in Rel-8 to add the always-on IP connectivity requirements in LTE

A key consideration to recognize is that under LTE, voice is just one of many potential media streams that can be communicated. A packet based network and VoIP allows this flexibility while still providing efficient use of radio and network resources.

However, 3GPP recognizes that adoption of both LTE and IMS will not occur overnight. For this reason 3GPP provided a transition solution for voice called CS Fallback. This allows a LTE device to drop back to the legacy 3G or 2G network if IMS VoIP capabilities are not supported. This is viewed as an interim solution to ease the transition to IMS and VoIP.

Myth 2: SMS isn’t supported over LTE

Reality: LTE and EPS will support a rich variety of messaging applications and also SMS is supported over LTE. The solution is twofold, covering both the full IMS case and a transition solution for those networks that do not support IMS.

SMS over IP was fully specified 3GPP Rel 7. It depends on IMS and it is intended to provide compatibility between the existing cellular legacy and the implementations with more elaborate messaging capabilities via SMS and IMS interworking..

For environments without IMS a transition solution was specified. This is called SMS over SGs (previously called the misleading name: SMS over CS). It is a hybrid approach that allows the transmission of native SMS from CS infrastructure over the LTE radio network. SMS over SGs was specified as part of Rel 8. SMS over SGs provides SMS service for mobiles in LTE and since it requires also CS domain infrastructure for the SMS transmission, it is intended to be a transition solution.

Myth 3: IMS isn’t ready for prime time

Reality: IMS has been around a long time. It was first developed as part of Rel 5 in 2002. It is based on IETF protocols such as SIP and SDP that are very mature. These technologies have been embraced by the industry as the signalling mechanism for multimedia applications.

In Rel 7 an effort was made to optimize IMS and the supporting protocols to ensure that voice and other media were supported as efficiently as in circuit switched networks.

IMS is fully specified and mature. The difficulties in rolling out IMS are not due to the protocols or the specifications. The consideration point is not only technical aspects but also shifting the whole industry paradigm from CS services to a truly IP-based environment, i.e. service migration, policies, interoperability and deployment plan included. However, these complexities must be addressed if the idea is to truly provide a richer service environment. This work is ongoing in many forums outside of 3GPP (e.g. Rich Communication Suite).

Myth 4: LTE doesn’t support emergency calls

Reality: VoIP support for emergency calls (including location support) is specified as part of Rel 9. This fulfils the last regulatory requirement separating VoIP from CS in 3GPP networks. A transition solution exists which is falling back to 3G/2G for completing emergency calls. This solution has existed since IMS was introduced (Rel 5).

However, to satisfy the situation of a fallback network not existing, this enhancement was completed in Rel 9. This allows the operator the option of supporting the regulatory requirements for LTE VoIP calls both for phones that can register for normal services and for those in limited service, including the USIM-less case.

Also the emergency call callback from the PSAP and its interaction with the possibly activated supplementary services is specified.

Legacy ServiceTransition SolutionEPS Solution
CS Voice CS Fallback (Rel 8) IMS VoIP (Rel 7)
SMS SMS over SGs (used to be called SMS over CS) (Rel 8) SMS over IP (Rel 7)
Supplementary Services CS Fallback (Rel 8) Multimedia Telephony (Rel 7)
Emergency Calls w Location Support CS Emergency Calls (Rel 5) IMS Emergency Calls w Location Support (Rel 9)

Wednesday, December 02, 2009

What is LTE

Introduction
LTE (Long Term Evolution) is the preferred development path of GSM/W-CDMA/HSPA networks currently deployed, and an option for evolution of CDMA networks. This essential evolution will enable networks to offer the higher data throughput to mobile terminals needed in order to deliver new and advanced mobile broadband services.

The primary objectives of this network evolution are to provide these services with a quality at least equivalent to what an end-user can enjoy today using their fixed broadband access at home, and to
reduce operational expenses by means of introducing flat IP architecture.

Why LTE
lthough 3G/3.5G technologies such as HSPA/EV-DO deliver significantly higher bit rates than 2G technologies, they do not fully satisfy the “wireless broadband” requirements of instant-on, always-on and multi-megabit throughput. With LTE delivering even higher peak throughput and much lower latency, mobile operators (either 3GPP or 3GPP2 based) have a unique opportunity to evolve their existing infrastructure to next- generation wireless networks. These networks will deliver their subscriber’s Quality of Experience (QoE) expectations in terms of real-time services such as Voice Over IP, Multi-User Gaming Over IP, High Definition Video On Demand and Live TV. This will also continue to improve the quality of delivery for all legacy applications (e-mail, internet browsing, MMS, etc.)

The improved speed and low latency provided by LTE will offer a much improved end-user experience for all corporate services:
• For applications where data throughput is important - faster e- mail and file uploads, enhanced VPN connection, high-speed internet, etc. and;
• For interactive applications where latency is crucial - IMS based VoIP, mail and file synchronization with an on-line server, peer-to-peer applications such as “NetMeeting”, SIP multimedia services including video and voice conference over IP, application sharing, etc.

In addition to typical corporate applications, we expect an increased interest from the vertical markets where information accuracy, reliability and immediacy are key: medical applications where latency and high resolution imaging are highly important; machine-to-machine communication where security and immediacy are crucial; live network based navigation; etc. The mass market will benefit from improvements delivered by LTE for all person-to-person and internet community applications: Push-to-See, improved quality for VoIP, photo and video downloading / uploading for personal blogs, online gaming, mobile social networks (such as YouTube, myspace), and “Second
life” type applications etc. On top of those improvements, LTE will enable the introduction of new services, such as High Definition Video (or HD TV) and multi-user interactive gaming:
• HD TV requires between 10 to 20 Mbits/s bandwidth (18 Mbits/s for example with Blue Ray standard), which is higher than current HSPA capabilities.
• Interactive multi-user gaming is extremely sensitive to latency: the very low latency offered by LTE (less than 10ms versus 60ms with HSPA) is key for fighting games, car races, or any action games involving a large number of simultaneous users. In addition, the higher throughput offered will enable high-resolution video games. Lastly LTE will play a key role in the development of N-uple services at home (IP TV, Internet, telephone, mobile…services bundle). We are observing an increasing need for broadband access at home and the same will apply to mobile services for two main reasons. Firstly, as subscribers become used to higher speeds at home, they will require the same quality of service when they are mobile so as to benefit from a seamless experience. The second reason is the possibility of offering higher bandwidth in remote areas where ADSL throughput is no longer sufficient and fibre
may not be economically viable compared with LTE. In those areas the same LTE infrastructure will deliver mobile services as well as broadband access at home, bringing economies of scale.

With the recent introduction of HSDPA and EV-DO Rev A, we have observed a significant increase in mobile data traffic, with some operators quadrupling their Packet Switched traffic in one
year. At this growth rate, and with the proliferation of new applications on the network, cells in hot spots will be quickly saturated and the network will require densification in these overloaded areas. This can be delivered by using a higher capacity solution such as LTE.

LTE and Multimedia Broadcast Multicast Service The Multimedia Broadcast Multicast Service (MBMS) enables multiple users to receive data over the same radio resource. This creates a more efficient approach for delivering content, such as video programming, to which multiple users have subscriptions. However, with HSPA, MBMS does not match the capabilities of broadcasting and/or broadband wireless technologies (such as DVB-H or WiMAX). With an OFDM/SC-FDMA (Orthogonal Frequency Division Multiplex /Single-Carrier Frequency Division Multiple Access) system, LTE provides the possibility of operating MBMS in a single frequency network mode where significant performance gains (up to five times existing capacity) can be achieved without additional receiver complexity. LTE will consequently dramatically enhance MBMS, and match DVB-H and WiMAX, capabilities.

Reducing the Total Cost of Ownership Another key driver behind LTE is the reduction of the cost per
byte, which is expected to decrease by a factor of six compared with HSPA today. This cost reduction is derived from network simplification, with flat IP architecture and the enhanced capacity delivered by the new radio technologies implemented by LTE.


What Is LTE Technology?
In order to prepare for wireless operator’s future needs and to ensure the competitiveness of their mobile systems over the next ten years, a progression of network architecture, as well as an evolution of the radio interface is required. This is being evaluated in the 3GPP System Architecture Evolution (SAE), Long Term Evolution (LTE) and HSPA Evolution (HSPA+) Study Items. From a network deployment perspective it is likely that HSPA enhancements will be introduced first followed by the progression to a radio interface (LTE). LTE will allow operators to achieve even greater peak throughputs in higher spectrum bandwidth, and to benefit from greater capacity at a reduced cost. Initial deployments are targeted for 2009.
LTE characteristics include:
• Peak LTE throughputs (high spectral efficiency)
− DL: 100 Mb/s SISO (Single Input Single Output);
− 173 Mb/s 2x2 MIMO (Multiple Input Multiple Output);
− 326 Mb/s 4x4 MIMO; for 20 MHz
− UL: 58 Mb/s 16 QAM
− 86 Mb/s 64 QAM (based on 1 Tx UE)
• Increased Spectrum efficiency over Release 6 HSPA
− DL: 3-4 times HSDPA for MIMO (2,2)
− UL: 2-3 times E-DCH for MIMO(1,2)
• Ultra low Latency
− less than 10 msec for round-trip delay (RTD) from UE to
server
− Reduced call setup times (50-100ms)
− =>wired user experience
• Capacity per cell
− 200 users for 5 MHz, 400 users in larger spectrum
allocations
• Flexible spectrum use maximizes flexibility
− 1.4, 3/3.2, 5, 10, 15, 20 MHz
− All frequencies of IMT-2000: 450 MHz to 2.6 GHz
LTE is being developed by the 3GPP (3rd generation Partnership Project) standards body that is also responsible for GSM and W-CDMA. LTE standards are currently being developed and are expected to be finalized in early 2008. In order to reach this performance, LTE will make the best use of the latest technologies on the market. For radio, a new modulation scheme is being used based on OFDM, and the latest antenna technologies, such as MIMO will be deployed. For the core network, an IP based network topology will also be introduced to considerably reduce network complexity. LTE uses Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink, which is better suited than W-CDMA for achieving high peak data rates in high spectrum bandwidth. On the uplink LTE uses SC-FDMA (Single Carrier Frequency Division Multiple Access), a technology that provides advantages in power efficiency and resulting terminal battery life versus a pure OFDM approach.

MIMO refers to a technique that employs multiple transmit and receive antennas, often in combination with multiple radios and parallel data streams. This results in numerous data paths effectively operating in parallel and, through appropriate decoding, a multiplicative gain in throughput. For example, with a 2X2 MIMO system, a gain of a factor of 2 is expected on the peak
throughput. LTE also requires new network architecture, with the main functional entities being: the e-node B on the access side, and the Serving (S) and Packet Data Network (PDN) gateways and the
Mobile Management Entity (MME) in the core network, as depicted in the figure below.

LTE is a pure packet system, with no support for legacy circuit- switched voice/data. This shift allows a significant simplification of the network, reducing the number of nodes and improving operational efficiencies. This network simplification also removes any bottlenecks from the system, ensuring the network permanently runs at peak efficiency. The next figure shows the impacts of this simplification comparing traditional UMTS elements and LTE nodes, and provides a macroscopic mapping of User Plane and Control Plane between nodes.



In contrast to UMTS architecture, no Radio Network Controller (RNC) is required: the RNC’s functions are collapsed into the eNodeB. On the Core network side, the Mobility Management Entity (MME) assumes the role of the SGSN for the control plane, and the serving and PDN gateways ensure the role of user plane, routing user data traffic to the network edge, replacing the GGSN.

Tuesday, October 13, 2009

A peek into the (not-so-distant) future of wireless broadband

What are the applications and services LTE will make possible? Check out this video to find out! Connected car, crowdcasting, mobile e-commerce… these are some of the reasons people in this video are so happy!



Source: Alcatel-Lucent blog.

Tuesday, July 07, 2009

Ping & Traceroute Troubleshooting Example

In this example, a ping to 186.9.17.153 gave a “TTL timeout” message. Ping TTLs will usually only timeout if there is a routing loop in which the packet bounces between two routers on the way to the target. Each “bounce” causes the TTL to decrease by a count of one until the TTL reaches zero at which point you get the timeout.

The routing loop was confirmed by the traceroute in which the packet was proven to be bouncing between routers at 186.40.64.94 and 186.40.64.93.

G:\>ping 186.9.17.153

Pinging 186.9.17.153 with 32 bytes of data:

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Ping statistics for 186.9.17.153:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

G:\>tracert 186.9.17.153

Tracing route to lostserver.confusion.net [186.9.17.153]

over a maximum of 30 hops:

1 <10>

2 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

3 70 ms 71 ms 70 ms rtr-1.confusion.net [186.40.64.93]

4 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

5 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

6 60 ms 70 ms 61 ms rtr-2.confusion.net [186.40.64.94]

7 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

8 60 ms 70 ms 60 ms rtr-2.confusion.net [186.40.64.94]

9 70 ms 70 ms 70 ms rtr-1.confusion.net [186.40.64.93]

...

...

...

Trace complete.

This problem was solved by resetting the routing process on both routers. The problem was initially triggered by an unstable network link that caused frequent routing recalculations. The constant activity eventually corrupted the routing tables of one of the routers.


Possible Reasons For Failed Traceroutes

Traceroutes can fail to reach their intended destination for a number of reasons, these include:

o Traceroute packets are being blocked or rejected by a router in the path. The router immediately after the last visible one is usually the culprit. It’s usually good to check the routing table and/or other status of this next hop device.

o The target server doesn’t exist on the network. It could be disconnected, or turned off. (!H or !N messages may be produced.)

o The network on which you expect the target host to reside doesn’t exist in the routing table of one of the routers in the path (!H or !N messages may be produced.)

o You may have a typographical error in the IP address of the target server

o You may have a routing loop in which packets bounce between two routers and never get to the intended destination.

o The packets don’t have a proper return path to your server. The last visible hop being the last hop in which the packets return correctly. The router immediately after the last visible one is the one at which the routing changes. It’s usually good to:

v log on to the last visible router.

v Look at the routing table to determine what the next hop is to your intended traceroute target.

v Log on to this next hop router.

v Do a traceroute from this router to your intended target server.

v If this works: Routing to the target server is OK. Do a traceroute back to your source server. The traceroute will probably fail at the bad router on the return path.

v If it doesn’t work: Test the routing table and/or other status of all the hops between it and your intended target.

Note: If there is nothing blocking your traceroute traffic, then the last visible router of an incomplete trace is either the last good router on the path, or the last router that has a valid return path to the server issuing the traceroute.

Sunday, May 24, 2009

ITIL Fundamental

General Overview

ITIL Service Support Processes (Operational Processes):
• Configuration Management
• Incident Management
• Problem Management
• Change Management
• Release Management

ITIL Service Delivery Processes (Strategic Processes):
• Availability Management
• IT Services Continuity Management
• Capacity Management
• Financial Management
• Service Level Management

ITIL Functions (Non-Process):
• Service Desk

Configuration Management
Summary: Configuration Management provides information on the IT infrastructure
to other ITIL processes and for decision support by IT Management. Configuration
Management enables control of the infrastructure by monitoring and maintaining
information on:
• All the resources needed to deliver services
• Configuration item (CI) status and history
• Configuration item relationships

Specific Configuration Management tasks:
• Identification and naming
• Management information
• Verification
• Control
• Status Accounting

Tip: A configuration Item (CI) is different than an Asset, which is a component of
a business process such as human resources (people), computer systems,
stationary/paper, telephones, etc.
Configuration Management Database (CMDB): A database, which contains all
relevant details of each Configuration Item (CI) and details of important
relationships between CIs.


A Configuration Item (CI):
• Is needed to deliver a service
• Is uniquely identifiable
• Is subject to change
• Can be managed

A Configuration Item (CI) has:
• a category
• one or more relationships
• one or more attributes
• a specific status at any given point in time

Configuration Item (CI) Variant: A Configuration Item (CI) that has the same
basic functionality as another Configuration Item (CI) but is different in some
small way (ex: has more memory)

Configuration Baseline: A snapshot of the state of a Configuration Item and any
component or related Configuration Items, frozen in time for a particular purpose
(such as the ability to return a service to a trusted state if a change goes wrong)

Configuration Management is critical in supporting and furthering the maturity of
all other ITIL service support and delivery processes.

Service Desk
The Service Desk concentrates on incident lifecycle management and performs the
following primary functions:
• Customer Interface
• Business Support
• Incident Control
• Management Information

Tip: Remember that the Service Desk is not a process, but is an IT function.

The Service Desk is the primary point of contact for all internal and/or external
customers and handles:
• Calls
• Questions
• Requests
• Complaints
• Remarks

The goal of the Service Desk is to:
1. To restore the service as quickly as possible
2. To manage the incident life-cycle (coordinating resolution)
3. To support business activities
4. To generate reports, to communicate and to promote

The different Types of Service Desks include:
• Call Centers: Handles large volumes of general support calls generally via
telephone.
• Help Desks: Manages, coordinates, and resolves incidents as quickly as
possible.
• Service Desks: Handles incidents, problems, questions and requests for
customers submitted through one or more interface points.

Tip: for incidents (an unexpected disruption to agreed service), the Service Desk
sets a priority based on business impact and urgency. Correctly assessing priorities
enables optimal deployment of resources in the best interest of the customer.

Incident Management
Incident: Any event which is not part of the standard operation of a service and
which causes or may cause an interruption to or a reduction in the quality of that
service.

The goal of Incident Management is to restore normal service as quickly as possible,
with the additional objectives of:
• Minimizing adverse impact of incidents on business operations
• Ensuring that the best possible levels of service quality and availability are
maintained according to established Service Level Agreements (SLAs).

Work-Around: Method of avoiding an incident or problem.

Service Request: Requests not related to incidents or failures in the IT
environment.

Problem: The unknown root cause of one or more incidents.

Known Error: A condition that exists after successfully diagnosing the root cause of
a problem; one or more specific Configuration Items (CIs) are determined to be at
fault.

Category: Classification of a group of incidents (e.g. Application, Hardware,
Network, etc.).

Vertical Escalation: Incident(s) escalate up the management chain.

Horizontal Escalation or Referral: Incident(s) escalate across different knowledge
groups or IT domains.

Primary activities in the Incident Management Life-Cycle:
• Acceptance / logging
• Registering events
• Consult the CMDB
• Classification
• Resolution
• Closure

Incident reporting includes:
• Daily reviews of incident and problem status against service levels
• Weekly management reviews
• Monthly management reviews
• Proactive service reports

Problem Management
The goal of Incident Management is to stabilize IT services through the following
activities:
• Determine the root causes of incidents
• Remove root cause points of failure
• Prevent incidents and problems proactively
• Minimize the consequences of incidents
• Prevent recurrence of incidents related to errors
• Improve the productive use of resources

Specific Problem Management tasks include:
• Facilitate Problem Control
• Implementing Error Control
• Proactive Problem Prevention
• Identifying Problem Trends
• Providing Management Information
• Performing Post Implementation Reviews (PIR)

Tip: The primary difference from the Incident Management process is Problem
Management’s proactive approach towards eliminating inefficiencies from the IT
environment.


Primary process inputs:
• Incident details
• Configuration details
• Defined workarounds

Primary process outputs:
• Known Errors (KE)
• Requests for Change (RFC)
• Updated Problem records including:
o Workarounds
o Solutions (Fixes)
• Management information matching

The Problem Control sub-process includes:
• Identification
• Classification
• Assign Resources
• Investigation and Diagnosis
• Establish Known Error

The Error Control sub-process includes:
• Error Identification and Recording
• Error Assessment
• Recording Error / Resolution (Send out RfC)
• Error Closure

Known Error: An Incident or Problem for which the root cause is known and a
temporary workaround or permanent alternative has been identified.

Proactive Problem Management involves:
• Trend Analysis
• Targeting Support Action
• Providing Information to the Organization

Change Management
The goal of Change Management is to implement approved changes efficiently,
cost-effectively and with minimal risk to existing and new IT infrastructure
components.

Tip: Only approved changes should be performed in order to reduce overall risk
to the IT environment.

Specific tasks in the Change Management process include:
• Filtering Changes
• Managing Change Process
• Managing Changes
• Chairing CAB and CAB/EC
• Review and Closure
• Management Information

The process inputs include:
• Requests for Change (RfC)
• CMDB / CI data
• Forward Schedule of Changes (FSC)

The process outputs include:
• Forward Schedule of Changes (FSC)
• Requests for Change (RfC)
• CAB minutes and action items
• Change Management reports

The impact categorization of changes may include:

Category 1
• Little impact on current services
• Change Manager may authorizes Requests for Change (RfC)

Category 2
• Clear impact on services
• RfC must be reviewed by the Change Advisory Board (CAB)
• Change Manager requests advice prior to authorization and planning

Category 3
• Significant impact on the service to the business
• Considerable resources required for change
• RfC is reviewed and approved by the Change Advisory Board (CAB)

Change Management priority settings may include:

Urgent: Change is required now to avoid severe adverse business impact

High: Change needed as soon as possible; may be potentially damaging to
business service provision

Medium: Scheduled changes intended to fix minor errors or issues with
functionality

Low: Change leads to minor improvements

Change: The addition, modification, or removal of approved and/or supported
hardware, software, applications and other environment components, systems, and
related documentation.

Request for Change (RfC): Formal request and recording of details surrounding the
intended change to the IT environment, impacting one or more Configuration Items
(CIs).

Forward Schedule of Changes (FSC): Schedule that contains details of and timing
for all approved changes scheduled for implementation.

The primary Change Management process activities include:
1. Request for Change (RfC)
2. Registration & Classification
3. Monitoring & Planning
4. Approval
5. Building & Testing
6. Authorizing Implementation
7. Implementation
8. Evaluation

Tip: Additional Change Management considerations:
• Change backout plan(s) should always be in place prior to implementation
• All changes should be reviewed prior to implementation

Release Management
The primary goal of Release Management is safeguard all hardware, software and
related items within the IT environment by ensuring the deployment of authorized
and tested versions of hardware and software.

Specific Release Management tasks include:
• Defining release policies
• Control of the Definitive Software Library (DSL)
• Control of the Definitive Hardware Storage (DHS)
• Distribution of software and associated Configuration Items (CIs)
• Execution of software audits
• Managing software releases
• Managing software builds

Tip: Releases are performed in conjunction with and under the control of the
Change Management process.

Definitive Software Library (DSL): Reliable versions of software in a single logical
location.

Tip: Software need not be centrally located in a DSL and may be physically
stored at different locations.

The Release Management policy should include:
• Release Unit
• Full / Package / Delta Releases
• Numbering
• Frequency
• Emergency Change

Release Management version control should include:
• Development
• Testing
• Production Release (Go-Live)
• Archiving

The primary activities within the Release Management process should include:
• Software Control & Distribution (Operational Release)
• Change Management (Release Control)
• Configuration Management (Release Control & Administration)

Availability Management
The primary goal of Availability Management is to predict, plan for and manage the
availability of services by ensuring that:
• All services are underpinned by sufficient, reliable and properly maintained
Configuration Items (CIs)
• Appropriate contractual agreements with third party suppliers are in place (if
applicable)
• Changes are proposed to proactively prevent future loss of service availability

Tip: Availability Management is critical to ensuring IT organizations deliver the
levels of availability agreed upon with customers through Service Level
Agreements (SLAs).

The primary attributes of Availability Management include:
• Reliability
• Maintainability
• Resilience (Redundancy)
• Serviceability

Tip: Availability Information may be stored in an Availability Database (ADB).
Availability information is used to create Availability plan(s), dictated by the
Service Level Management process.

Mean Time to Repair (MTTR): Downtime; period of time that elapses between the
detection of an incident and actual resolution.

MTTR Lifecycle: Incident, Detection, Diagnosis, Repair, Recovery, Restoration.

Mean Time Between Failures (MTBF): Uptime; time period that elapses between
restoration of an incident and a new recurrence of the same incident.

Mean Time Between System Incidents (MTBSI): Time period that elapses
between two incidents.


IT Service Continuity Management
The primary goal of IT Service Continuity Management (ITSCM) is to support the
Business Continuity Plan (BCP) process by ensuring the IT environment can be
recovered within required timeframes.

Tip: An IT Service Continuity Plan cannot be created without the existence of a
valid Business Continuity Plan (BCP).

An ITSCM plan is important in order to:
• Reduce the impact of IT infrastructure failure
• Decrease business risk and vulnerability
• Increase customer and end-user confidence
• Fulfillment of legal and/or regulatory requirements

A Business Impact Analysis (BIA) includes the following components:

Risk Analysis
• Determining the value of assets
• Determining threats
• Determining vulnerabilities

Risk Management
• Outlining countermeasures
• Planning for potential disasters
• Managing a disaster

Infrastructure options specific to the ITSCM process include:
1. Do Nothing
2. Manual Workarounds
3. Reciprocal Arrangements
4. Gradual recovery (“Cold Standby”)
5. Intermediate Recovery (“Warm Standby”)
6. Immediate Recovery (“Hot Standby”)

An effective IT Service Continuity Management (ITSCM) plan should include the
following sections:
• IT Administration
• Infrastructure Overview
• Operating Procedures
• IT Personnel
• IT Security
• Contingency Site(s)

Testing and reviewing the ITSCM plan should include the following activities:
• Initial Review (immediate / initial sign-off)
• Continuous Review (e.g. every 6 to 12 months)
• Post-Implementation (e.g. after an actual recovery has occurred)
• Documentation Reviews (and continuous updates)
• Adherence to all Change Management requirements

Capacity Management
The primary goal of Capacity Management is to determine the appropriate and
cost-justifiable capacity of IT resources to ensure that agreed-upon service levels
are achieved within the required timeframes.

Specific objectives are achieved through:
• Demand Management (Business Capacity Management)
• Workload Management (Service Capacity Management)
• Resource Management (Resource Capacity Management)
• Performance Management of:
o Internal and external financial data
o Usage data

Capacity Data Base (CDB): Contains all measurements and associated metrics
used to create a Capacity Management Plan; populated with Performance
Management data used for decision support related to:
• Customer capacity requirements / demands
• Workload management
• Performance management
• Capacity planning
• Defining capacity thresholds
• Monitoring capacity

Application Sizing: Estimates resource requirements in support of a proposed
application change, ensuring all required service levels are met.

• Capacity Management Modeling includes:
• Trend Analysis
• Analytical Modeling
• Simulation Modeling
• Baseline Models

IT Financial Management
The primary goal of IT Financial Management is to provide information and
control over the cost of delivering IT services delivered to business customers.

Specific cost units include:
• Equipment Cost Units (ECU)
• Organization Cost Units (OCU)
• Transfer Cost Units (TCU)
• Accommodation Cost Units (ACU)
• Software Cost Units (SCU)

Transfer Costs: Costs incurred by IT, acting as an agent for the customer, but
not allocated against the IT budget.

IT Financial Management cost types include:
• Fixed: Costs unaffected by the level of usage
• Variable: Varying costs according to level of usage
• Direct: Costs associated with the usage of a specific service
• Indirect (Overhead): Costs specific to more than one specific service
• Capital: Costs that are not diminished by usage
• Revenue (Running): Costs that diminish with usage

Specific Financial Management pricing options may include:
• No Charging: IT performs service support and delivery as a support
center
• Cost Recovery: IT performs as a service center
• Notional Charging (Cost Center): IT performs services as a cost center
• Actual Charging: Specific charges for IT products and services charged
by actual usage of these services
• Cost Price Plus (Market Pricing): IT provides services for / as a profit
center

Soft Charging: Used by Support and Cost centers to facilitate service provision
without actual exchange of currency.

Hard Costing: Money for IT services transferred between [bank] accounts
and/or departments

Tip: Profit centers focus on the value of the IT service to the customer

Three primary sub-processes of IT Financial Management include:

Budgeting: Predicting and controlling spending within through periodic
negotiation cycles to set budgets and regular, consistent monitoring of
budgets.

IT Accounting: Enabling the IT organization to fully account for expenditures
by breaking down costs by specific customer, service and/or activity.

Charging: Billing customers for actual services provided through established,
proven IT accounting methods and ongoing analysis, billing, and reporting
procedures.

Tip: Mature IT Financial Management helps streamline IT service by shaping
customer demand for services that have specific, tiered levels of service.

Service Level Management
The primary goal of Service Level Management is to obtain a balance between
the demands for and supply of specific IT services through ongoing facilitation
and negotiation of business requirements with full knowledge of available IT
services and capabilities.

Specific Service Level Management (SLM) objectives may include:
• Establishing sound Business Relationship Management (BRM) between
service providers and customers
• Improving communication of IT services to the business and/or internal
customers
• Increasing the flexibility and responsiveness of IT service provision
• Balancing customer demands with the ongoing cost of IT service provision
• Measuring and reporting accurate service levels
• Implementing continuous improvement of IT service quality
• Ensuring objective conflict resolution

Specific Service Level Management (SLM) tasks should include:
• Creation of an IT Service Catalog
• Obtaining specific customer Service Level Requirements (SLRs)
• Establishing Service Level Agreements (SLAs)
• Establishing Operational Level Agreements (OLAs)
• Reviewing, creating and refining Underpinning Contracts (UCs)
• Implementing specific Service Quality Plans
• Monitoring, reviewing and reporting on IT service levels
• Establishing IT Service Improvement Programs (SIPs)
• Engaging the business through effective relationship management (BRM)

Minimum Requirements for a Service Agreement (SLA/OLA/UC):
• Timing / Period of Service Provision
• Service Description / Narrative
• Throughput (Inputs / Outputs / Service Levels)
• Service Availability
• Service [Desk] Response Times
• Sign-Off / Sponsorship (Physical Signatures)

Other Service Agreement coverage areas may include:
• Contingency arrangements
• Review procedures
• Change procedures
• Additional Support services
• Customer roles & responsibilities
• Administration requirements
• Maintenance requirements
• Amendments

Tip: Service Level Agreements must be monitored and reviewed regularly to
ensure IT products and services are being delivered optimally against all
service level requirements

Friday, March 06, 2009

Areas of Work Where a Juniper Engineer Works Best

Author: Ribvar Shafeei

There are three areas where you can efficiently utilize the services of a third party or in-house Juniper engineer. The expertise that can be provided by a Juniper engineer could improve the security protocols of your network. Network security should become one of the top priorities of your company’s IT infrastructure. That’s because risks and vulnerabilities have increased overtime due also to the increasing sophistication of technologies designed to breach the defenses of corporate IT networks. By utilizing the expertise of a Juniper engineer, your company will be able to deploy effective network security solutions. Analyze and Assess Network Security with the Help of a Juniper Engineer An expert Juniper engineer can accurately assess and analyze the security performance and defense posture of your company’s networks. Proper evaluation of existing networks and security protocols deployed on it would enable you to address vulnerabilities. Analysis and assessment can also provide information on what areas of your network need improvement. Through the expert evaluation of a Juniper engineer, you can enhance your network’s security performance and add value to your IT investments. The return on investments of your network facilities could also improve if it can be properly evaluated by a Juniper engineer. Specifically, a Juniper engineer will look into the current security protocols deployed on your system. After assessing the procedures and security policies of your network, the Juniper engineer could provide mitigating actions which could minimize risks and vulnerabilities. Assessment and analysis of your network are critical steps you need to optimize the performance of your company’s IT environment. A Juniper Engineer Can Design and Plan Network Security If you are still planning to build your company’s network infrastructure, a Juniper engineer can provide valuable help in designing the appropriate security protocols for it. Design is a critical phase of network building. This is the stage where a Juniper engineer can correctly configure the core security applications of your network infrastructure. After the design stage, the actual network implementation plan should be created. At this stage, a Juniper engineer can provide valuable input and assistance in terms of pinpointing the areas where security optimization can be deployed. Planning robust and scalable network security applications can also be done by a Juniper engineer. It could help your company maximize the potential benefits of a secured network and reduce incidence of malicious attacks. With the help of a Juniper engineer, you can shorten the time involved in network design and planning, thus giving your company much savings in time, resources, and effort. Deployment and Implementation of Network Security One of the biggest network projects is the actual deployment of security applications, protocols and procedures. This stage requires the expertise of a network security professional. A Juniper engineer can provide the expertise for such project. For new networks, the task could be simpler as the infrastructure will be built from scratch. Deployments become more complicated during migration procedures of existing networks. Migration of security protocols from one system to another could expose the network to vulnerabilities and greater risks. That is why it is extremely important to get proper support from an expert Juniper engineer during network security migrations and actual deployments.

Article Source: http://www.articlesbase.com/networks-articles/areas-of-work-where-a-juniper-engineer-works-best-627370.html

About the Author:
Bsecure is a Sydney based Network Security Services company that provides affordable assessment, consultation, design and implementation services in all areas of network and information security.

Tuesday, March 03, 2009

Algorhyme

I think that I shall never see
A graph more lovely than a tree.

A tree whose crucial property
Is loop-free connectivity.

A tree which must be sure to span
So packets can reach every LAN.

First the Root must be selected
By ID it is elected.

Least cost paths from Root are traced
In the tree these paths are placed.

A mesh is made by folks like me.
Then bridges find a spanning tree.

by Radia Perlman (creator Spanning Tree Protocol / STP)

Saturday, February 28, 2009

Unblocking Google Talk Contact

google-talk-logo

This topic would sound absurd, but it really isn’t, so keep on reading :) Have you ever blocked a contact in Google Talk? Well, recently a friend of mine was annoying me a lot. I even warned him not to disturb, but he kept on bugging me, so in the end the only choice I had was to block him. After block, I worked in peace but the next day I felt sorry for what I have done and wanted to unblock him back. But to my surprise, there was no way I can unblock him from Google Talk itself.

I know, this is very weird, but when I blocked him, Google Talk blocked and deleted him from my list. In the end, I did found how to get the contact unblocked back. In thsi post, I’ll tell you how to unblock contacts.

Note: After reading the above paragraphs, please don’t try blocking anyone just for the sake of trying. If you block, and cannot unblock afterwards, I’m not responsible for that. Read on further to learn how to unblock contacts. Here I’ll be using sizzled.test@gmail.com as a sample. I have blocked this contact through my Google Talk, and now want to unblock it.

1. After blocking, you’ll notice that the contact entry in your Google Talk has been permanently deleted. Even if you try searching from the search bar, you won’t find him.

gtalk-block

2. Open you Gmail inbox, and wait for the Google Talk module to load in the left sidebar. Then type the user id/email of the contact in it’s search bar whom you blocked and want to unblock. Then point to it’s Profile link, and press the big Chat button.

gtalk-block-2

(click the image to enlarge)

3. It will show the contact as offline (doesn’t matter if the contact is really online or offline). Try typing anything in the chat box. I wrote hello, and got a message above saying: You cannot send a message to a blocked contact.

gtalk-block-3

4. Press the Options button now, and click Unblock [contact name].

gtalk-block-4

5. Contact unblocked! :)

gtalk-block-5

See, I told you that unblocking is a little tricky. If there’s any other method, let me know below.

Courtesy from :

http://www.sizzledcore.com/2007/10/11/how-to-unblock-contacts-in-google-talk/

Monday, February 23, 2009

Why BGP MPLS VPNs?

"Why do we need VPNs?"

We need VPNs because enterprises need private connectivity, and they need that over a shared infrastructure to minimize their costs.

"Why do we need MPLS?"

This is because MPLS offers a good infrastructure for converged networks. Rather than using passwords, it offers hierarchy, data privacy, traffic engineering, and differentiated services.

"Why do we need BGP?"

We need BGP because it offers a common framework for providing all VPN types--Layer 2 VPNs, IP VPNs, and VPLS. In addition, it can do auto-discovery, VPN label exchange, and interprovider and carrier-to-carrier VPNs.

Why do we need all these kinds of VPNs?

We need Layer 2 VPNs because of their legacy; they are there and have been for a long time.
We need IP VPNs because traffic is increasingly all IP, and any-to-any connectivity has its benefits. Moreover, outsourcing routing can be a big cost saver.And we need VPLS, as this is an exciting new service that takes advantage of an exciting new medium, Ethernet.

Debugging my fault

I had taken a sat at JNCIP exam before. Its a remote lab, telnet-ing to physical lab in Amsterdam.
Its an 8-hour practical exam excluding one hour lunch time, start from 10 AM to 7 PM including one hour lunch time. I had build an ISP consisting of seven M-series routers and multiple EBGP neighbors. All 7 router's IGP, BGP route reflector and EBGP neighbors had been reach up. And then i jump into IGP/BGP customization task and routing policy, but i saw the clock already 5 PM, i hurried up finish my task, and by 7 PM i feel i had meet all the requirements but i did not had time to check and verified the configuration.

15 days after the exam, Gary Hausser, who is proctoring me send me an email, he said i failed the exam and i lost big points in IGP/BGP customization task and routing policy. I feel very sad to had receiving email like that. :( i realized that i had no enough time to verified again my configuration at that area. Its because i didn't wisely allocate my time wisely, the pitfall was my battle against unfamiliar interface at beginning of exam taking 3 hour to conquered them.

Debugging my fault
After receiving email from Gary, i check again configuration my m7i's logical router, yeah i found a lot of mistake because i didn't re-read the requirements, i just follow my assumption not following what the juniper want.
Now, i preparing myself to taking another exam by trying bunch of exam scenario and a lot of what if question...

Wish me luck okay :D

Thursday, February 05, 2009

show version and haiku

IS-IS screams,
BGP peers are flapping:
I want my mommy!

IS-IS sleeps.
BGP peers are quiet.
Something must be wrong.

Look, mama, no hands!
Only one finger typing.
Easy: commit scripts.

TTL down one
the end nearer with each hop
little packet, poof.

3am; darkness;
Maintenance window closing.
Safety net: rollback.

Weeks of studying,
Days of lab exercises:
JNCIE.

Juniper babies
The next generation starts
Gotta get more sleep

Tuesday, February 03, 2009

General Networking Troubleshooting Tips

  • You must know what is "NORMAL" for your system
  • Start with a visual inspection
  • A divide-and-conquer approach is ideal when multiple fault can lead to a common symptom
  • Failure hypotheses should be testable-be definitive about parameter of the test
  • Please do not blinded by subjectivity-open your eyes and mind
  • Layered troubleshooting approach
  • modern communication networks are modeled around architecture layer
  • matching a symptom to the root-caused layer is a critical step in rapid diagnosis and restoration
  • identifying the specific fault within the root-cause layer is icing on the cake!

Wednesday, January 21, 2009

Case Study: IS-IS

The following case study simulates a typical JNCIP-level IS-IS configuration scenario. You should refer to the criteria listing and the information in Figure 4.4, the case study topology, in order to complete the IS-IS case study. It is assumed that you will be adding the IS-IS related configuration on top of the interface configuration that was left from the case study at the end of Chapter 2, 'Interface Configuration and Testing.' You should therefore first remove any protocol, policy, family iso interface statements, and any static route-related configuration resulting from the examples given in this chapter from all your routers before beginning the case study. Ideally you will start the case study by reloading your Chapter 2 baseline configuration using load override.

It is expected that a JNCIP candidate will be able to complete this case study in approximately one hour, with the result being an IS-IS IGP that exhibits no serious operational problems. Sample IS-IS configurations from all seven routers are provided at the end of the case study for comparison with your own configurations. Multiple solutions are sometimes possible, so differences between the provided examples and your own configurations do not always indicate that mistakes have been made. Because you are graded on the overall functionality of your IGP and its conformance to the specified configuration criteria, various operational mode commands are included so that you may compare the behavior of your network to a known good example.

To complete this case study, your IS-IS configuration must meet the following criteria:

  • lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.

  • Backbone area routes must be summarized into area 49.0001.

  • The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure that no adjacencies can be established on this subnet.

  • Redistribute the 10.0.5/24 route into the backbone such that area 49.0002-attached routers see a metric of at least 100.

  • r5 and r6 must use a level 1 priority of 0.

  • Ensure that r7 never functions as a pseudonode when its adjacencies are up.

  • Summarize all routes (internal and external) into the backbone area.

  • You may not modify or view the OSPF router's configuration.

  • All areas must use hello authentication based on md5 with a secret of jnx. The backbone area must also authenticate LSPs using a simple password of jnx.

  • Configure r6 and r7 to advertise the IS-IS default route to the OSPF router. Ensure that the OSPF router can load balance over the default route.

  • Configure r6 and r7 to redistribute OSPF routes learned from the OSPF router into IS-IS.

  • Except for r5, ensure that no single router or link failure will isolate r1, r2, or the OSPF router.

  • Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.

  • No static routes and no loops.

  • Set the level 1 preference in area 49.0001 to 155.

  • You must not have suboptimal routing between r6, r7, and the OSPF router.

  • Configure the network to keep LSPs that are up to 3600 seconds old.

  • Only one adjacency is permitted between any two routers.

In this case study, the OSPF router is preconfigured and its configuration cannot be modified or viewed. You may assume, however, that it is configured to run OSPF, and that it has the policy statements needed to redistribute the 192.168.0-3/24 static routes into OSPF should an adjacency be formed.

IS-IS Case Study Analysis


Each configuration requirement for the case study will now be matched to one or more valid router configurations and the commands that can be used to confirm that the router is operating within all specified case study guidelines. We begin with these four criteria, as they serve to establish baseline IS-IS operation in each area:

  • lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.

  • Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.

  • Configure the network to keep LSPs that are up to 3600 seconds old.

  • Only one adjacency is permitted between any two routers.

To get basic IS-IS connectivity going, you must add the iso family to the correct logical units on all IS-IS interfaces, assign the router's NET to its lo0 address, and correctly configure the interface to level associations so that no interfaces are running at both levels 1 and 2. The following captures show typical IS-IS configurations from key routers throughout the network, starting with r4:

[edit]
lab@r4# run show interfaces terse
Interface Admin Link Proto Local Remote
fe-0/0/0 up down
fe-0/0/1 up up
fe-0/0/1.0 up up inet 10.0.4.9/30
iso
. . .
so-0/1/0 up up
so-0/1/0.100 up up inet 10.0.2.6/30
iso
so-0/1/1 up up
so-0/1/1.0 up up soagg --> as0.0
so-0/1/2 up up
so-0/1/2.0 up up soagg --> as0.0
so-0/1/3 up down
as0 up up
as0.0 up up inet 10.0.2.10/30
iso
fxp0 up up
fxp0.0 up up inet 10.0.1.4/24
fxp1 up up
fxp1.0 up up tnp 4

. . .
lo0 up up
lo0.0 up up inet 10.0.3.4 --> 0/0
iso 49.0002.0100.0000.3004.00
. . .

The IS-IS routing instance for r4 is shown next:
[edit]
lab@r4# show protocols isis
reference-bandwidth 500m;
lsp-lifetime 3600;
interface fe-0/0/1.0 {
level 2 disable;
}
interface all {
level 1 disable;
}


r4ís configuration has the required iso family interface assignments, NET, and the correct
interface-to-level associations, which in this case was achieved by disabling level 1 on all inter-
faces with the exception of interface fe-0/0/1. Care must be taken to ensure that you do not con-
figure backbone router lo0 interfaces to operate at level 1 in order to meet the requirement that
backbone lo0 addresses are not to be injected into area 49.0002 or 49.0001. The automatic
metric requirement is achieved by assigning reference bandwidth of 500Mbps, and the default
LSP lifetime is set to 3600 seconds as required. Correct interface-to-level mapping and the auto-
matically calculated metric values are confirmed by displaying IS-IS interface status:

[edit]
lab@r4# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
as0.0 2 0x1 Disabled Point to Point 1/1
fe-0/0/1.0 1 0x2 r2.02 Disabled 5/5
lo0.0 0 0x1 Disabled Passive 0/0
so-0/1/0.100 2 0x1 Disabled Point to Point 3/3


The configuration of routers in level 1 areas will be similar to the example shown next, which
is taken from r7:

[edit]
lab@r7# run show interfaces terse
Interface Admin Link Proto Local Remote


fe-0/3/0 up up
fe-0/3/0.0 up up inet 10.0.8.2/30
iso
fe-0/3/1 up up
fe-0/3/1.0 up up inet 10.0.8.10/30
iso
. . .
lo0 up up
lo0.0 up up inet 10.0.9.7 --> 0/0
iso 49.0001.0100.0000.9007.00
. . .


The routing instance for a level 1 router r7 is configured as shown next:

[edit]
lab@r7# show protocols isis
reference-bandwidth 500m;
lsp-lifetime 3600;
interface all {
level 2 disable;
}


The correct interface-to-level mappings are now confirmed on r7:

[edit]
lab@r7# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
fe-0/3/0.0 1 0x2 r7.02 Disabled 5/5
fe-0/3/1.0 1 0x3 r5.03 Disabled 5/5
lo0.0 0 0x1 Passive Disabled 0/0


At this stage, you should have the required number and type (either level 1 or level 2) of adja-
cencies between all seven routers. To quickly confirm, we verify that we have the expected number
of SysIDs on a few strategic routers:

[edit]
lab@r3# run show isis hostname
IS-IS hostname database:
System Id Hostname Type
0100.0000.3003 r3 Static
0100.0000.3004 r4 Dynamic
0100.0000.3005 r5 Dynamic

0100.0000.6001 r1 Dynamic
0100.0000.6002 r2 Dynamic


r3 has hostname entries that correctly reflect area 49.0003 and 49.0002 routers, as expected.
We confirm area 49.0001 by performing the same command on r6:

[edit]
lab@r6# run show isis hostname
IS-IS hostname database:
System Id Hostname Type
0100.0000.3005 r5 Dynamic
0100.0000.9006 r6 Static
0100.0000.9007 r7 Dynamic


A test to confirm that backbone routers see IS-IS routes to all loopback addresses is now
performed:

[edit protocols isis]
lab@r3# run show route protocol isis | match /32
10.0.3.4/32 *[IS-IS/18] 00:39:09, metric 3, tag 2
10.0.3.5/32 *[IS-IS/18] 00:39:09, metric 3, tag 2
10.0.6.1/32 *[IS-IS/15] 00:39:09, metric 5, tag 1
10.0.6.2/32 *[IS-IS/15] 00:39:09, metric 5, tag 1
10.0.9.6/32 *[IS-IS/18] 00:37:32, metric 8, tag 2
10.0.9.7/32 *[IS-IS/18] 00:36:27, metric 8, tag 2


As expected, there are six IS-IS routes on r3 that represent the loopback addresses of all
remote routers. These results indicate that baseline IS-IS functionality is working as needed for
the remaining configuration tasks. You will now add authentication as per this requirement:
All areas must use hello authentication based on md5 with a secret of jnx. The backbone
area must also authenticate LSPs using a simple password of jnx.
Backbone authentication is now added and confirmed. The authentication-related additions
to a typical backbone router configuration are highlighted next:

[edit protocols isis]
lab@r5# show
reference-bandwidth 500m;
level 2 {
authentication-key "$9$jEkmTOBEhrv"; # SECRET-DATA
authentication-type simple; # SECRET-DATA
}
interface fe-0/0/0.0 {
level 2 disable;

level 1 {
hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}
interface fe-0/0/1.0 {
level 2 disable;
level 1 {
hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}
interface all {
level 1 disable;
level 2 {
hello-authentication-key "$9$5znCyrvMX-"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}

Backbone authentication is confirmed by verifying the status of adjacencies (hello authenti-
cation) and the presence of IS-IS routes (LSP authentication):

[edit protocols isis]
lab@r4# run show isis adjacency
Interface System L State Hold (secs) SNPA
as0.0 r5 2 Up 20
fe-0/0/1.0 0100.0000.6002 1 Down 24 0:a0:c9:b2:f8:cb
so-0/1/0.100 r3 2 Up 25


[edit protocols isis]
lab@r4# run show isis route | match /32
10.0.3.3/32 2 55 3 int so-0/1/0.100 r3
10.0.3.5/32 2 55 1 int as0.0 r5


A working authentication configuration for a typical level 1 router is shown here with
authentication-related additions highlighted:

[edit protocols isis]
lab@r1# show
reference-bandwidth 500m;
interface all {

hello-authentication-key "$9$MexL7Vji.mT3"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
level 2 disable;
}


Hello authentication in level 1 areas can be confirmed by verifying the correct adjacency status:

[edit]
lab@r2# run show isis adjacency
Interface System L State Hold (secs) SNPA
fe-0/0/1.0 r4 1 Up 25 0:90:69:6b:30:1
fe-0/0/2.0 r3 1 Up 19 0:90:69:6d:98:1
fe-0/0/3.0 r1 1 Up 25 0:a0:c9:6f:7b:84


Results such as these indicate that hello authentication has been correctly configured in level 1
areas. We next examine a working configuration example for the following case study requirements:

Backbone area routes must be summarized into area 49.0001.
The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure
that no adjacencies can be established on this subnet.
The summarization and leaking of routes into area 49.0001 requires the use of policy and the
definition of an aggregate route, as shown next in the configuration of r5, which highlights the
configuration additions needed for this task:

[edit]
lab@r5# show routing-options
static {
route 10.0.200.0/24 next-hop 10.0.1.102;
}
aggregate {
route 10.0.2.0/23;
}


The policy needed to advertise an aggregate route into a level 1 area is shown here:

[edit]
lab@r5# show policy-options
policy-statement summ {
term 1 {
from {
protocol aggregate;
route-filter 10.0.2.0/23 exact;
}

to level 1;
then accept;
}
}

The export policy must be applied to IS-IS as export for it to have any effect:

[edit]
lab@r5# show protocols isis export
export summ;


The correct operation of route summarization and leaking is easily confirmed on area
49.0001 routers:

[edit]
lab@r6# run show route 10.0.2/23
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.2.0/23 *[IS-IS/160] 00:02:56, metric 15, tag 1
> to 10.0.8.6 via fe-0/1/0.0


Setting r3ís fe-0/0/2 interface to passive ensures the 172.16.0.12/30 prefix is advertised into
the backbone area as an internal route while also guarding against IS-IS adjacency formation:

[edit protocols isis]
lab@r3# show interface fe-0/0/2
passive;
level 1 disable;


It is a good idea to explicitly disable level 1 operation on this interface because its specific
mention in the configuration results in its not being affected by the presence of the interface all
level 1 disable clause. To confirm proper behavior, we verify that the route to 172.16.0.12/
30 is present in the backbone as an IS-IS internal level 2 route:

[edit]
lab@r5# run show route 172/8
inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.12/30 *[IS-IS/18] 02:10:36, metric 8, tag 2
> to 10.0.2.2 via at-0/2/1.35