As'ad Arafat

Resiliency Defined

2011-02-01T15:10:00.000+07:00

The ability to recover from a failure. The term may be applied to
hardware, software or the network. Service guarantees in the
form of Service Level Agreements (SLA) require a resilient
network that instantaneously detects facility or node failures
and restores network operation immediately to meet the terms
of the SLA.

IPV6 Routing – some technical background

2010-10-07T15:50:00.001+07:00

Topics
- IPv6 Fragmentation
- Configurable MTU
- Path MTU Discovery
- ICMP v6

QoS:
- Classification on TC and dot1p
- Remarking of dot1p
- Remarking of TC based on FC

RFCs:
- RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
- RFC 2461 Neighbor Discovery for IPv6
- RFC 2462 IPv6 Stateless Address Auto configuration
- RFC 2463 Internet Control Message Protocol (ICMPv6) for the IP v6 specification
- RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
- RFC 3315 Dynamic Host Configuration Protocol for IPv6 (Relay Agent)
- RFC 3587 IPv6 Global Unicast Address Format
- RFC 4007 IPv6 Scoped Address Architecture
- RFC 4193 Unique Local IPv6 Unicast Addresses
- RFC 4291 IPv6 Addressing Architecture

L2VPN/VPLS-Martini and Kompella

2010-03-08T15:15:00.002+07:00

Both Martini-draft and Kompella-draft addressed setting up of a Pseudowire emulation over MPLS in order to offer L2VPN services. These drafts were initial efforts to standardise L2VPN services.

Martini draft was named after a former Cisco employee Luca Martini. Martini draft uses LDP as signalling to setup L2VPN over MPLS backbone. The tradeoff of this draft was auto-discovery.

Kompella draft on the other hand uses BGP for both signalling and auto-discovery to establish fully-meshed pseudo wires (multipoint). Kompella-draft is named after author Keerti Kompella (Juniper Employee).

draft-martini and draft-kompella terms are used as labels for the two different L2VPN services methodologies (LDP Vs BGP for signaling). The actual drafts do not exist in IETF.

In dealing with multipoint-fully meshed topologies in edge routers, draft-martini suffered auto-discovery, to overcome aut0-discovery, it suffered configuration overhead. draft-Kompella claimed to be better scalable because of suto-discovery but with complex signalling whereas draft-martini leverages simplicity.

Martini draft was standardized under RFC 4096 . however it has since been superseded by the Pseudowire Emulation Edge to Edge (PWE3) Working Group specifications described in RFC 4447 and related documents. On the other hand draft-kompella is obsolete and was not standardized.

RFC 4664 - Framework for Layer 2 Virtual Private Networks (L2VPN), it describes the framework for L2VPNs (VPWS, VPLS and IPLS). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. Requirements for L2VPNs can be found in RFC 4665 – Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks.

All this was consolidated, and the L2VPN Working Group produced two separate documents, RFC 4761 and RFC 4762, both offered VPLS but using different signaling protocols:

Kireeti Kompella and Yakov Rekhter published “Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling” RFC 4761 in January 2007.

Marc Lasserre and Vach Kompella published “Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling” RFC 4762 in January 2007.

L2VPN services for many vendors uses RFC 4762 -Martini ( with LDP) as a standard for example Alcatel 7450’s uses RFC 4762 as the standard

Taken From ciscotips.wordpress.com

Why Should I Care About IP Multicast?

2010-01-19T12:07:00.008+07:00

Many applicationsused in modern networks
require information (voice, video, or data) to be
sent to multiple end stations. When only a few end
stations are targeted, sending multiple copies of the
same information through the network (unicast)
causes no ill effects.
However, as the number of targeted end stations
increases, the harmful effects of duplicate packets
become dramatic. Deploying applications such as
streaming video, financial market data, and IP
telephony-based Music On Hold without enabling
network devices for multicast support can cause
severe degradation to a network’s performance.

What Problems Need to Be Solved?
Multicasting requiresmethods to efficiently deploy
and scale distributed group applications across the

network. This is accomplished by using protocols

that reduce the network load associated with send
ing the same data to multiple receivers and that

alleviate the high host/router processing require
ments for serving individual connections.

Internet Group Management
Protocol (IGMP)

IGMP is a protocol thatallows end stations to join

what is known as a multicast group. Joining a mul
ticast group can be thought of as like subscribing

to a session or service where multicast is used.

IGMP relies on Class D IP addresses to create mul

ticast groups.

When a multicast session begins, the host sends an

IGMP message throughout the network to discover

which end stations have joined the group. The host

then sends traffic to all members of that multicast

group. Routers “listen” to IGMP traffic and peri

odically send out queries to discover which groups

are active or inactive on particular LANs. Routers

communicate with each other using one or more
protocolsto build multicast routes for each group.

Multicast Distribution Trees

Multicast-capable routerscreate distribution trees
that control the path that IP multicast traffic takes

through the network to deliver traffic to all

receivers. The two basic types of multicast distri

bution trees are source trees and shared trees.
With source trees (also known as shortest-path
trees), each source sends its data to each receiver
using the most efficient path, as shown in the pre
ceding figure. Source trees are optimized for latency
but have higher memory requirements, because
routers must keep track of all sources.
With shared trees, shown in the following figure,
the multicast data is sent to a common point in the
etwork (known as the rendezvous point) before
being sent to each receiver. In the figure, Router D
serves as the rendezvous point, and all multicast
data is routed through it. Shared trees require less
memory in routers than source trees but may not
always use the optimal path, which can resulting
packet delivery latency

Layer 2 Multicast

A Layer 2 switchforwards all multicast traffic,
which reduces network efficiency. Two methods,
Cisco Group Management Protocol (CGMP) and
IGMP snooping, were developed to mitigate this
inefficient switch behavior.
Cisco Group Management Protocol
(CGMP)
CGMP allowsCisco Catalyst switches to make Layer
2 forwarding decisions based on IGMP information.
When configured on switches and routers, CGMP
ensures that IP multicast traffic is delivered only to
ports that are attached to interested receivers, or
multicast routers. With CGMP running, any router
receiving a multicast join message via a switch replies
to the switch with a CGMP join message. This mes
sage allows Layer 2forwarding decisions to be made.
IGMP Snooping
IGMP snoopingimproves efficiency by enabling a
Layer 2 switch to view Layer 3 information (IGMP)
used to populate the unicast routing table. PIM
uses this unicast routing information to perform
the multicast forwarding function. Although PIM
is called a multicast routing protocol, it actually
uses the unicast routing table to perform the RPF
check function instead of building a completely
independent multicast routing table. It includes
two different modes of behavior for dense and
sparse traffic environments—dense mode and
sparse mode:

• In PIM dense mode, the multicast router floods
traffic messages out all ports (referred to as a
“push” model). If a router has no hosts or
downstream neighbors that are members of the
group, a prune message is sent, telling the router
not to flood message on a particular interface.
Dense mode only uses source trees. Because of
the flood and prune behavior, dense mode is not
recommended.

• PIM sparse mode uses what is known as an

“explicit join” model. In this model, traffic is

only sent to hosts that explicitly ask to receive

it. This is accomplished by sending a join mes

sage to the rendezvous point.

An Anycast Rendezvous Point (RP) provides

load balancing, redundancy, and fault tolerance

by assigning the same IP address tomultiple RPs

within a PIM sparse mode network multicast

domain.

join/leave messages) sent between hosts and

routers. When an IGMP host report is sent

through a switch, the switch adds the host’s port

number to the associated multicast table entry.

When the switch hears the IGMP leave group mes

sage from a host, the switch removes the host’s

table entry. IGMP requires a switch to examine all

multicast packets and therefore should be imple-

mented only on high-end switches.

Multicast Forwarding

In unicast routing, traffic is routed from the source

to the destinationhost. The router scans its rout

ing table for the destination address and then for

wards a single copy of the unicast packet out the

correct interface.

In multicast forwarding, the source sends traffic to

several hosts, represented by a multicast group

address. The multicast router must determine which

direction is the upstream direction (toward the

source) and which one is the downstream direction

(toward the hosts). When more than one downstream

path exists, the best ones (toward the group address)

are chosen. These paths may or may not be the

same path that would be chosen for a unicast pack

et. This is called Reverse Path Forwarding (RPF).

RPF is used to create loop-free distribution trees.

Taken From CiscoPress

Gus Dus Biography

2009-12-31T12:32:00.005+07:00

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

Dispelling LTE Myth

2009-12-04T19:29:00.003+07:00

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 Service	Transition Solution	EPS 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)

What is LTE

2009-12-02T10:21:00.004+07:00

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.

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

2009-10-13T12:09:00.002+07:00

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.

Ping & Traceroute Troubleshooting Example

2009-07-07T11:04:00.000+07:00

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.

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.

ITIL Fundamental

2009-05-24T22:46:00.001+07:00

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

Areas of Work Where a Juniper Engineer Works Best

2009-03-06T10:12:00.000+07:00

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.

Algorhyme

2009-03-03T17:53:00.001+07:00

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)

Unblocking Google Talk Contact

2009-02-28T23:03:00.001+07:00

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.

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.

(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.

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

5. Contact unblocked! :)

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/

Why BGP MPLS VPNs?

2009-02-23T21:25:00.001+07:00

"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

2009-02-23T15:59:00.005+07:00

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

show version and haiku

2009-02-05T15:22:00.002+07:00

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

General Networking Troubleshooting Tips

2009-02-03T16:36:00.005+07:00

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!

JNCIP Case Study: OSPF

2008-12-23T15:32:00.010+07:00

The following case study is designed to simulate a typical JNCIP OSPF configuration scenario. You should refer to the criteria listing and Figure 3.10, the case study topology, for the information needed to complete the OSPF case study. It is assumed that you will be building your OSPF configuration on top of the interface configuration that was left from the case study at the end of Chapter 2. You should remove any protocol, policy, and static route configurations related to the previous examples given in this chapter from all seven routers before starting.

Figure 3.10: OSPF case study topology

It is expected that a prepared JNCIP exam candidate will be able to complete this case study in approximately one hour, and that the resulting OSPF network will have no serious operational problems. Sample OSPF configurations for all seven routers are provided at the end of the case study to compare with your own configurations. Multiple solutions to the same requirement are often possible, so differences between these sample configurations and those created by you will not necessarily 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 will be shown to allow you to compare the behavior of your network to a known good example.

To complete this case study, you must ensure that your OSPF configuration meets the following criteria:

RID based on lo0 address and reachable via OSPF for all routers.
Loopback addresses from the backbone must appear as summary LSAs in area 20.
The 10.0.5/25 subnet between r1 and r2 must appear in area 0 as an external route. Ensure that no adjacencies can be established over this subnet.
Set the metric of the 10.0.5/24 route to reflect an initial value of 10 and ensure that all routers adjust this value to reflect their internal OSPF cost. Tag this route with the value 420.
Ensure that r1 never generates a network LSA.
No type 3 or type 5 LSAs in area 1.
You must elect a DR on the 10.0.2.4/30 subnet.
Summarize all routes (internal and external) into the backbone area, including the 192.168.x/ 24 routes from the RIP router. You must not modify the RIP router's configuration.
Area 0 must use md5 authentication with secret of jnx. Configure r6 and r7 to advertise 10.0.5/24 to the RIP router, and ensure that the rip metric sent by r7 is higher than that sent from r6.
Advertise the 172.16.40.x RIP router subnets as OSPF internal routes, while ensuring that no adjacency can be established over these interfaces.
Except for r5, ensure that no single ABR or link failure will break communications between area 1 routers and the RIP router.
Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 10. You may manually set metrics as needed to allow load balancing from r5 to area 1 internal destinations.
No static routes.
The 10.0.5/24 subnet must be reachable from the RIP router and the path must be optimal.

In this case study, the RIP router is preconfigured and its configuration cannot be modified. Key aspects of the RIP router's configuration are shown in Listing 3.6.

Listing 3.6: RIP Router's Configuration

lab@rip# show policy-options
policy-statement rip {
term 1 {
 from protocol [ static rip ];
 then accept;
}
}
[edit] lab@rip# show routing-options static
route 192.168.0.0/24 receive;
route 192.168.1.0/24 receive;
route 192.168.2.0/24 receive;
route 192.168.3.0/24 receive;
route 192.168.4.0/24 receive;

[edit] lab@rip# show interfaces lo0
unit 0 {
  family inet {
             address 192.168.0.1/32;
             address 192.168.1.1/32;
             address 192.168.2.1/32;
             address 192.168.3.1/32;  
             address 192.168.4.1/32;
  }
}

OSPF Case Study Analysis

Each configuration requirement for the case study will now be matched to the necessary configuration steps, and will be confirmed operational within all specified case study guidelines. We begin with the first two configuration criteria:

RID based on lo0 address and reachable via OSPF for all routers.
Loopback addresses from the backbone must appear as summary LSAs in area 20.

As long as you do not manually specify a RID, your router's RID will be based on its lo0 address. By including the lo0 interface under the area 0 configuration of backbone routers, you ensure that the lo0 address will be injected as a network summary into other areas. These requirements are met with the highlighted configuration entry shown next:

[edit]
lab@r3# show protocols ospf area 0
authentication-type md5; # SECRET-DATA
interface at-0/1/0.35 {
authentication-key "$9$I-EhyKsYoaUH" key-id 1; # SECRET-DATA
}
interface so-0/2/0.100 {
interface-type nbma;
authentication-key "$9$6M9/CpBW87Nb2" key-id 1; # SECRET-DATA
neighbor 10.0.2.6 eligible;
}
interface lo0.0;

The results are now confirmed in area 20:

lab@r7> show ospf database netsummary advertising-router 10.0.3.5
 OSPF link state database, area 0.0.0.20
Type       ID          Adv Rtr       Seq     Age  Opt  Cksum  Len
Summary  10.0.2.0    10.0.3.5    0x80000008  1036  0x2  0x61d3  28
Summary  10.0.2.4    10.0.3.5    0x8000000c   900  0x2  0x6db9  28
Summary  10.0.2.8    10.0.3.5    0x80000007   765  0x2  0x131b  28
Summary  10.0.3.3    10.0.3.5    0x80000007   736  0x2  0x4ce2  28
Summary  10.0.3.4    10.0.3.5    0x80000007   601  0x2  0x42eb  28
Summary  10.0.3.5    10.0.3.5    0x80000007   465  0x2  0xfb37  28
Summary  10.0.7.255  10.0.3.5    0x80000007   436  0x2  0x5cb6  28

We next deal with the following configuration criteria:

The 10.0.5/25 subnet between r1 and r2 must appear in area 0 as an external route. Ensure that no adjacencies can be established over this subnet.
Set the metric of the 10.0.5/24 route to reflect an initial value of 10 plus OSPF internal cost. Tag this route with the value 420.
Ensure that r1 never generates a network LSA.

You must use OSPF export policy on both r1 and r2 to make the 10.0.5/24 subnet appear as an external route in the backbone area. There is no need to run OSPF on the 10.0.5/24 subnet, but if you do, you must include the passive keyword on r1 and r2's fe-0/0/0 interface to prevent adjacency formation. The OSPF export policy must set the correct metric type (a type 1 metric will be increased to reflect internal OSPF cost), initial metric value, and tag setting. The priority setting of 0 on r1's OSPF interfaces ensures it can never be a DR or BDR, and that it can therefore never generate a network LSA in accordance with your configuration requirements. The highlights in the screen captures shown next call out the configuration additions needed to address the requirements listed previously:

[edit]
lab@r1# show protocols ospf export external;
reference-bandwidth 1g;
area 0.0.0.1 {
nssa;
interface fe-0/0/2.0 {          
       priority 0;
}
interface fe-0/0/1.200 {
       priority 0;
        }
}

lab@r1# show policy-options
policy-statement external {
term 1 {
        from {
  route-filter 10.0.5.0/24 exact;
}     
        then {
         metric 10;
        tag 420;
        external {
        type 1;
  }         
        accept;
 }
}
term 2 {
        then reject;
}
}

The DR status of r1 is now confirmed:

lab@r1> show ospf interface
Interface              State     Area            DR ID           BDR ID       Nbrs
fe-0/0/1.200           DRother   0.0.0.1         10.0.3.3        0.0.0.0         1
fe-0/0/2.0             DRother   0.0.0.1         10.0.6.2        0.0.0.0         1

The status of DRother indicates that r1 is neither the DR nor the BDR, despite being one of only two nodes on a broadcast network. This proves that r1 is not eligible to become the DR or BDR. The following test confirms proper operation of the r1 and r2 OSPF export policy:

lab@r5> show ospf database extern detail
OSPF external link state database
Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len
Extern   10.0.5.0         10.0.3.4         0x80000002    170  0x2  0xed80  36
mask 255.255.255.0
Type 1, TOS 0x0, metric 30, fwd addr 0.0.0.0, tag 0.0.1.164

The 10.0.5/24 prefix appears in the backbone as an external LSA. The metric type, value, and tag setting all appear correct (note that the metric value has increased to reflect r5's cost to the advertising ASBR). In this display, the tag is shown in dotted decimal notation. To view its decimal setting, you can view the resulting route:

lab@r5> show route 10.0.5/24

inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.5.0/24          *[OSPF/150] 00:27:12, metric 36, tag 420                
                   > via as1.0

The following configuration requirements must now be addressed:

No type 3 or type 5 LSAs in area 1.
You must elect a DR on the 10.0.2.4/30 subnet.
Area 0 must use md5 authentication with a secret of jnx.

You must configure area 1 as a NSSA with the no-summaries option to meet the area's LSA restrictions. The default-metric option instructs the ABRs to generate the default route needed for area 1 routers to reach inter-area and external destinations. The type-7 keyword is needed to ensure that the default route is generated as a NSSA type 7 LSA, which is in accordance with the requirement that there be no type 3 LSAs in area 1:

[edit]
lab@r3# show protocols ospf area 1
nssa { 
 default-lsa {  
 default-metric 1;  
 type-7;
} 
 no-summaries;
}
. . .

The following commands confirm that no type 3 or type 5 LSAs are present in area 1:

[edit]
lab@r3# run show ospf database netsummary area 1

OSPF link state database, area 0.0.0.1
[edit]
lab@r3# run show ospf database extern area 1

[edit]
lab@r3#

The DR requirement for the 10.0.2.4/30 subnet means that you must configure the Frame Relay link between r3 and r4 as an NBMA network so that the DR election algorithm is performed. While it is odd to see a point-to-point WAN link running in NBMA mode, this is a legal NBMA topology and can be fully justified with plans for future backbone expansion. This approach also proves useful for practicing WAN interface configurations in a test bed that forces back-to-back connections due to lack of switching gear.

This example shows a correct area 0 authentication configuration from r3. The key-id value of 1 was not specified in the case study, and so was left to the operator's discretion. This key-id value must be used in all backbone routers for proper area 0 authentication. You can also see that the so-0/2/0.100 interface has been correctly configured for OSPF NBMA operation:

[edit]
lab@r3# show protocols ospf area 0
authentication-type md5; # SECRET-DATA
interface at-0/1/0.35 {
authentication-key "$9$I-EhyKsYoaUH" key-id 1; # SECRET-DATA
}
interface so-0/2/0.100 {
interface-type nbma;     
authentication-key "$9$6M9/CpBW87Nb2" key-id 1; # SECRET-DATA     
neighbor 10.0.2.6 eligible;
}
interface lo0.0;

The following confirms that authentication and DR router election is functional. The presence of neighbors on area 0 interfaces indicates that compatible authentication has been configured, and it is clear from the following output that a DR and BDR have been elected on the so-0/2/0.100

interface in keeping with its NBMA network type. Though not shown, all area 0 adjacencies are confirmed to be in the full state:

[edit] lab@r3# run show ospf interface
Interface              State     Area            DR ID           BDR ID       Nbrs
at-0/1/0.35            PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         1
lo0.0                  DR       0.0.0.0         10.0.3.3        0.0.0.0         0 
so-0/2/0.100           DR       0.0.0.0         10.0.3.3        10.0.3.4        1
fe-0/0/0.0             DR       0.0.0.1         10.0.3.3        0.0.0.0         1
fe-0/0/1.0             BDR      0.0.0.1         10.0.6.2        10.0.3.3        1

We next examine the following configuration criterion:

Summarize all routes (internal and external) into the backbone area. You must not modify the RIP router's configuration.

Internal route summarization is performed by the ABRs, and is configured under areas 1 and 20. Your summarization must include the area's physical, loopback, and RIP router subnets as applicable. Area 1 summarization is configured as shown next:

[edit]
lab@r3# show protocols ospf area 1
nssa { 
 default-lsa {
 default-metric 1;  
 type-7;
} 
 no-summaries;
} area-range 10.0.4.0/22;
interface fe-0/0/0.0 { 
metric 20;
}
interface fe-0/0/1.0 {
metric 20;
}

Because there is only one NSSA external route in area 1, there is no need for NSSA summarization through an area range specified within the NSSA stanza. Summarization for area 20, as configured on r5, is shown next:

[edit]
lab@r5# show protocols ospf area 20 
area-range 172.16.40.0/28;
area-range 10.0.8.0/21;
interface fe-0/0/0.0;
interface fe-0/0/1.0;

Because type 5 LSAs can be summarized only at the originating ASBR, the summarization of the 192.168.x/24 RIP routes must be performed on r6 and r7 using OSPF export policy and a locally configured aggregate route, as shown next. The presence of any 192.168.x/24 RIP routes will cause the aggregate route to be active:

[edit]
lab@r7# show policy-options policy-statement ospf-out
term 1 {
from {
 protocol aggregate;  
 route-filter 192.168.0.0/22 exact;
    }      then accept;
}
term 2 { 
then reject;
}

[edit]
lab@r7# show routing-options aggregate
route 192.168.0.0/22;

Address summarization is confirmed in area 0 with the commands shown in Listing 3.7:

Listing 3.7: Verify Address Summarization in the Backbone

lab@r3# run show route 192.168/16

inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both  

192.168.0.0/22     *[OSPF/150] 01:14:08, metric 0, tag 0              
            > via at-0/1/0.35

[edit]
lab@r3# run show route 10.0.8.0

inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.8.0/21         *[OSPF/10] 00:13:58, metric 26                 
                 > via at-0/1/0.35

[edit]
lab@r3# run show route 10.0.9.0

inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.8.0/21         *[OSPF/10] 00:14:03, metric 26                 
                 > via at-0/1/0.35

lab@r5>  show route 10.0.4.0

inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both  
10.0.4.0/22         *[OSPF/10] 01:16:25, metric 36                 
                 > via at-0/2/1.35

lab@r5>  show route 10.0.6.0
inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both  
10.0.4.0/22         *[OSPF/10] 01:16:33, metric 36                 
                 > via at-0/2/1.35

[edit]

The results shown in Listing 3.7 confirm that the internal and external addresses associated with the non-backbone areas are being correctly summarized before injection into the backbone area.

We now address the following configuration criteria:

Configure r6 and r7 to advertise 10.0.5/24 to the RIP router. Ensure that the rip metric sent by r7 is higher than that sent from r6.
Advertise the 172.16.40.x RIP router subnets as OSPF internal routes, while ensuring that no adjacency can be established over these interfaces.

For the first of the two requirements, r7 is configured to set the metric of advertised routes to 2, which is higher than the metric of 1 associated with the routes sent by r6. The rip-out export policy causes the OSPF route 10.0.5/24 to be exported into RIP:

[edit]
lab@r7# show protocols rip
group rip {     
    metric-out 2;
    export rip-out;
    neighbor fe-0/3/3.0 { 
                import rip-in;
         }
}

[edit]
lab@r7# show policy-options policy-statement rip-out
term 1 {
from {
          protocol ospf;  
   route-filter 10.0.5.0/24 exact;
   } 
   then accept;
}
term 2 { 
then reject;
}

To address the second requirement, both r6 and r7 have been configured to list their RIP router interfaces as passive under OSPF. This prevents adjacency formation while causing the associated routes to be advertised as OSPF internals:

[edit]
lab@r7#
show protocols ospf
export ospf-out;
reference-bandwidth 1g;
area 0.0.0.20 { 
 interface fe-0/3/0.0; 
 interface fe-0/3/1.0;
 interface fe-0/3/3.0 {  
     passive;
        }
}

To prevent loops and the possibility of inefficient routing, a RIP import policy has been defined (and applied to RIP) to ensure that r6 and r7 will accept only the 192.168.x/24 routes from the RIP router:

[edit]
lab@r7#
show policy-options policy-statement rip-in
term 1 {
from {  
 protocol rip;         
 route-filter 192.168.0.0/22 orlonger; 
 } 
 then accept;
} term 2 {
   then reject;
}

[edit] lab@r7# show protocols rip
group rip {
metric-out 2;
export rip-out;
neighbor fe-0/3/3.0 {  
 import rip-in; 
 }
}

We next analyze the following requirement:

Except for r5, ensure that no single ABR or link failure will break communications between area 1 routers and the RIP router.

To achieve this requirement, you must ensure that both r3 and r4 are generating a default route into area 1, and that both r6 and r7 are advertising the aggregate for the RIP routes. Load balancing from the RIP router will not function because of the different metrics being advertised by r6 and r7, but the failure of r6 will not isolate the RIP router once network reconvergence is complete. The following commands confirm that the redundancy requirements have been met:

lab@r1> show ospf database nssa

OSPF link state database, area 0.0.0.1
Type   ID            Adv Rtr         Seq      Age  Opt  Cksum  Len
NSSA   0.0.0.0     10.0.3.3      0x80000007    692  0x0  0xdd5e  36
NSSA   0.0.0.0     10.0.3.4      0x80000007   1246  0x0  0xd763  36

The presence of two default routes in area 1 confirms that the loss of either r3 or r4 will not isolate area 1 routers. We now confirm that both r6 and r7 are advertising the RIP aggregate:

lab@r5# run show ospf database extern

OSPF external link state database
Type        ID            Adv Rtr         Seq      Age  Opt  Cksum  Len
Extern    10.0.5.0       10.0.3.4     0x8000000b    380  0x2  0xdb89  36
Extern    192.168.0.0    10.0.9.6     0x80000003   1313  0x2  0x60f0  36
Extern    192.168.0.0    10.0.9.7     0x80000009    451  0x2  0x4efb  36

We now verify that the RIP router correctly points to r6 when forwarding to 10.0.5/24, until r6 has its RIP interface deactivated:

[edit] lab@rip# run show route protocol rip
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.5.0/24        *[RIP/100] 02:02:48, metric 2, tag 420              
            > to 172.16.40.2 via fe-0/0/0.0

[edit]
lab@r6# deactivate interfaces fe-0/1/3

[edit]
lab@r6# commit commit complete

After taking r6 out of the equation, you confirm that r7 takes over:

[edit]
lab@rip# run show route protocol 
rip inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.5.0/24          *[RIP/100] 00:00:09, metric 3, tag 420                 
              > to 172.16.40.6 via fe-0/0/1.0

Great-the RIP router fails over to r7 as expected, so we can reactivate r6's fe-0/1/3 interface. We now address the following (and last) configuration requirement:

Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 10, excepting manual settings needed to allow load balancing from r5 to internal destinations in area 1.

To meet this requirement, you must set the OSPF reference bandwidth to 1 Gig on all routers, which will result in an automatic metric setting of 10 for 100Mbps interfaces. The default OSPF reference bandwidth of 100Mbps had caused all interface used in this sample JNCIP test bed to have a metric of 1, which results in path optimization based on hop count. To achieve the required load balancing at r5, you must manually set metrics in area 1 (so that both r3 and r4 advertise the same metric in their network summary) and you must set the metric of the aggregated SONET link so that it has the same OSPF cost as the slower ATM link. The load-balancing requirement can be met with an asymmetric metric assignment on the aggregated SONET interface, which is the approach taken in the following, in that the default metric has been left in place for r4's as0 interface:

[edit]
lab@r3# show protocols ospf 
reference-bandwidth 1g;
area 0.0.0.1 {
nssa {     
   default-lsa {      
   default-metric 1;      
   type-7;
  }     
      no-summaries; 
  } 
  area-range 10.0.4.0/22; 
  interface fe-0/0/0.0 {
          metric 20; 
  } 
  interface fe-0/0/1.0 {          
          metric 20; 
  }
} area 0.0.0.0 { 
. . .

[edit]
lab@r5# show protocols ospf area 0
authentication-type md5; # SECRET-DATA
interface lo0.0;
interface at-0/2/1.35 {    authentication-key "$9$LaA7dskqf5F/" key-id 1; # SECRET-DATA
}
interface as1.0 {
metric 6;
authentication-key "$9$LBa7dskqf5F/" key-id 1; # SECRET-DATA
}

You now confirm the correct load-balancing behavior at r5:

[edit]
lab@r5# run show route 10.0.4/22

inet.0: 26 destinations, 28 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.4.0/22        *[OSPF/10] 00:53:46, metric 36                        
                 via as1.0              
            > via at-0/2/1.35
10.0.5.0/24        *[OSPF/150] 00:53:46, metric 36, tag 420
            > via as1.0

The presence of a single next hop for the 10.0.5/24 prefix is not a problem because this is not an area 1 internal route.

The last check is to verify RIP router connectivity and optimal forwarding paths through your network, in accordance with this stipulation:

The 10.0.5/24 subnet must be reachable from the RIP router using optimal paths.

Forwarding to 10.0.5/24 from area 20 is confirmed with the following test performed at the RIP router:

lab@rip> traceroute 10.0.5.1
traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets
1 172.16.40.2 (172.16.40.2) 0.194 ms 0.248 ms 0.095 ms
2 10.0.8.6 (10.0.8.6) 0.326 ms 0.295 ms 0.277 ms
3 10.0.2.10 (10.0.2.10) 0.331 ms 0.314 ms 0.294 ms
4 10.0.4.10 (10.0.4.10) 0.234 ms 0.256 ms 0.218 ms
5 10.0.5.1 (10.0.5.1) 0.314 ms 0.296 ms 0.283 ms

The results of the RIP router traceroute indicate that it is forwarding through r6, so we now know that r6 will use the path shown in the traceroute to reach the 10.0.5/24 subnet. Some candidates may be thrown by the extra hop caused by r5 forwarding through r4 instead of r3. This inefficiency is the result of r4 having a higher RID than r3, and therefore being the only ABR that is performing the type 7 to type 5 LSA translations for the NSSA. This is confirmed by changing the traceroute target to the address owned by r2, which confirms optimal forwarding:

lab@rip> traceroute 10.0.5.2
traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets
1 172.16.40.2 (172.16.40.2) 0.196 ms 0.229 ms 0.094 ms
2 10.0.8.6 (10.0.8.6) 0.332 ms 0.294 ms 0.276 ms
3 10.0.2.10 (10.0.2.10) 0.330 ms 0.307 ms 0.294 ms
4 10.0.5.2 (10.0.5.2) 0.238 ms 0.228 ms 0.220 ms

We now verify that r7 can also reach the 10.0.5/24 subnet using an optimal path, because the failure of r6 would cause r7 to become part of the forwarding path:

lab@r7> traceroute 10.0.5.2
traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets
1 10.0.8.9 (10.0.8.9) 0.351 ms 0.257 ms 0.216 ms
2 10.0.2.10 (10.0.2.10) 0.274 ms 0.247 ms 0.243 ms
3 10.0.5.2 (10.0.5.2) 0.179 ms 0.169 ms 0.155 ms

OSPF Case Study Configurations

The configuration changes needed to complete the OSPF IGP case study for all routers in the test bed are provided in Listings 3.8 through 3.14.

Listing 3.8: r1 OSPF-Related Configuration

lab@r1# show policy-options
policy-statement external {
term 1 {     
          from {         
          route-filter 10.0.5.0/24 exact;
     }     
          then {         
          metric 10;      
          tag 420;         
          external {          
                    type 1;      
                   }         
          accept;  
          } 
     }
term 2 {  
          then reject; 
   }
}

[edit]
lab@r1# show protocols ospf
export external;
reference-bandwidth 1g;
area 0.0.0.1 { 
 nssa;
 interface fe-0/0/2.0 {     
 priority 0;
 }
 interface fe-0/0/1.200 {     
 priority 0; 
 }
}

Listing 3.9: r2 OSPF-Related Configuration

lab@r2# show protocols ospf
reference-bandwidth 1g;
area 0.0.0.1 { 
   nssa; 
   interface fe-0/0/1.0; 
   interface fe-0/0/2.0; 
   interface fe-0/0/3.0;
   }

[edit]
lab@r2# show policy-options
policy-statement external {
term 1 {  
 from {         
         route-filter 10.0.5.0/24 exact;
      }  
 then {         
         metric 10;         
         tag 420;         
         external {          
         type 1;      
         }      
         accept;  
      }
    }
term 2 {     
 then reject; 
    }
}

Listing 3.10: r3 OSPF-Related Configuration

lab@r3# show protocols ospf
reference-bandwidth 1g;
area 0.0.0.1 {
nssa {     
   default-lsa {
       default-metric 1;
       type-7;  
   }
   no-summaries; 
} 
area-range 10.0.4.0/22;
interface fe-0/0/0.0 {     
    metric 20; 
} 
interface fe-0/0/1.0 {     
    metric 20; 
}
}
area 0.0.0.0 {
authentication-type md5; # SECRET-DATA 
 interface at-0/1/0.35 {  
 authentication-key "$9$I-EhyKsYoaUH" key-id 1; # SECRET-DATA
  }
interface so-0/2/0.100 {     
         interface-type nbma;
 authentication-key "$9$6M9/CpBW87Nb2" key-id 1; # SECRET-DATA  
 neighbor 10.0.2.6 eligible;
}
interface lo0.0;
}

Listing 3.11: r4 OSPF-Related Configuration

lab@r4# show protocols ospf
reference-bandwidth 1g;
area 0.0.0.1 {
nssa {     
  default-lsa {      
       default-metric 1;
       type-7;  
  }     
  no-summaries; 
} 
area-range 10.0.4.0/22;
interface fe-0/0/1.0;
}
area 0.0.0.0 {
authentication-type md5; # SECRET-DATA 
 interface so-0/1/0.100 {     
         interface-type nbma;  
         authentication-key "$9$42JUH/9pu1h" key-id 1; # SECRET-DATA  
         neighbor 10.0.4.5 eligible; 
 } 
 interface as0.0 {  
         authentication-key "$9$AXiLuBEx7Vb2a" key-id 1; # SECRET-DATA
 }
 interface lo0.0;
 }

Listing 3.12: r5 OSPF-Related Configuration

lab@r5# show protocols ospf
reference-bandwidth 1g;
area 0.0.0.0 {
authentication-type md5; # SECRET-DATA
interface lo0.0; 
interface at-0/2/1.35 {     
     authentication-key "$9$LaA7dskqf5F/" key-id 1; # SECRET-DATA 
}
interface as1.0 {  
     metric 6;     
     authentication-key "$9$LBa7dskqf5F/" key-id 1; # SECRET-DATA 
     }
}

area 0.0.0.20 {
area-range 172.16.40.0/28; 
area-range 10.0.8.0/21; 
interface fe-0/0/0.0; 
interface fe-0/0/1.0;
}

Listing 3.13: r6 OSPF- and RIP-Related Configuration

lab@r6# show routing-options aggregate
route 192.168.0.0/22;

[edit]
lab@r6# show policy-options
policy-statement rip-in { 
 term 1 {     
         from {      
             protocol rip;      
             route-filter 192.168.0.0/22 orlonger;  
         }     
 then accept; 
} 
 term 2 {     
         then reject; 
 }
}

policy-statement ospf-out { 
term 1  {     
         from {
             protocol aggregate;      
             route-filter 192.168.0.0/22 exact;  
         }     
         then accept;
} 
term 2 {     
         then reject;
}
}

policy-statement rip-out { 
term 1 {  
         from {      
             protocol ospf;
             route-filter 10.0.5.0/24 exact;  
         }
     then accept;
}
term 2 {
         then reject;
}
}

[edit]
ab@r6# show protocols
ospf { 
export ospf-out;
reference-bandwidth 1g;
area 0.0.0.20 {     
          interface fe-0/1/0.0;
          interface fe-0/1/1.0;
          interface fe-0/1/3.0 {
                              passive;
          }
}
}

rip {
group rip {  
     export rip-out;
     neighbor fe-0/1/3.0 {
                        import rip-in;
     }
}
}

Listing 3.14: r7 OSPF- and RIP-Related Configuration

lab@r7#
show routing-options aggregate
route 192.168.0.0/22;

[edit]
lab@r7# show policy-options
policy-statement rip-in {
 term 1 {
       from {
           protocol rip;
           route-filter 192.168.0.0/22 orlonger;  
       }     
       then accept; 
 } 
 term 2 {     
       then reject; 
 }
}

policy-statement ospf-out {
 term 1 {
       from {      
           protocol aggregate;      
           route-filter 192.168.0.0/22 exact;  
       }     
 then accept; 
 } 
term 2 {     
       then reject; 
}
}

policy-statement rip-out { 
term 1 {
      from {      
          protocol ospf;      
          route-filter 10.0.5.0/24 exact;  
      }     
      then accept; 
term 2 {     
      then reject;
}
}

[edit]
lab@r7# show protocols
ospf { 
export ospf-out;
reference-bandwidth 1g;
area 0.0.0.20 {     
            interface fe-0/3/0.0;     
            interface fe-0/2/1.0;  
            interface fe-0/3/3.0 {         
                    passive;  
            }
}
}

rip {
group rip {  
        metric-out 2;  
        export rip-out;     
        neighbor fe-0/3/3.0 {      
                          import rip-in;  
        }
}
}

OSPF LSA types

2008-12-23T15:31:00.000+07:00

1. Router LSA
2. Network LSA
3. Network summary LSA
4. ASBR summary LSA
5. AS external LSA
6. Group membership LSA
7. NSSA external LSA
8. External attributes LSA
9. Opaque LSA (link-local scope)
10. Opaque LSA (area-local scope)
11. Opaque LSA (AS-wide scope)

SecureCRT script for running MultiCast patch in Olive with VMware

2008-12-11T15:58:00.005+07:00

1. Create file named command. txt and auto.js. Put this files under C: \ temp directory
2. Open command.txt with your favorite editor and copy this text

"blank row"
boot -s
/bin/sh
cd /modules
kldload ./syscall11.ko
root
root123
sysctl dev.em.0.fix_em_multicast=1
sysctl dev.em.1.fix_em_multicast=1
sysctl dev.em.2.fix_em_multicast=1
sysctl dev.em.3.fix_em_multicast=1
cli

3. Open auto.js with your favorite editor and copy this text

# $Language = "JScript"
# $interface = "1.0"

function main()
{
var fso, f, r;
var ForReading = 1, ForWriting = 2;
fso = new ActiveXObject("Scripting.FileSystemObject");
f = fso.OpenTextFile("c:\\temp\\file.txt", ForReading);
crt.Screen.Synchronous = true;
var str; var str;

crt.Screen.WaitForString( "prompt." );
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "OK" );
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "/bin/sh: " );
str = f.Readline();str += "\015";crt.Screen.Send( str );
str = f.Readline();str += "\015";crt.Screen.Send( str );
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.screen.Send("\004");
crt.Screen.WaitForString( "login:" );
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "Password:" );
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
str = f.Readline();str += "\015";crt.Screen.Send( str );
crt.Screen.WaitForString( "%"); // Note: % is the promt
}

4. To use start VM right away, open SecureCRT-> Script->Run->auto.js
5. Enjoy

Alcatel-Lucent Announces Service Routing Certification Program Changes

2008-11-28T13:43:00.009+07:00

1. Introduction of a New Certification: Alcatel-Lucent Network Routing Specialist II

The Alcatel-Lucent Network Routing Specialist II (NRS II) certification builds on the strong foundation established by the NRS I (previously named NRS) and is a stepping stone to the more advanced, revenue-generating service opportunities that can be deployed with advanced IP and Ethernet technologies based on the Alcatel-Lucent Service Router portfolio.
The NRS II certification will be of great value to engineers and operations support staff who want to take the next step in their careers. On completion of the NRS II certification, participants will understand basic protocols and how Alcatel-Lucent IP solutions enable profitable new triple play residential services and mission-critical business services.
To obtain the Alcatel-Lucent NRS II certification, individuals need to successfully pass the following exams:
· 4A0-100: Alcatel-Lucent Scalable IP Networks
· 4A0-101: Alcatel-Lucent Interior Routing Protocols and High Availability
· 4A0-103: Alcatel-Lucent Multiprotocol Label Switching
· 4A0-104: Alcatel-Lucent Services Architecture
· *NEW* NRSII4A0: Alcatel-Lucent NRS II Lab Exam

2. Exam Prerequisite Changes
Written Exams: Alcatel-Lucent has removed the prerequisites for the SRC written exams (4A0-100 through 4A0-110). Effective today, there are no exam prerequisites for these exams. You can write these exams in any order. As a result, you no longer require a voucher to register to write these exams at Prometric.
Practical Lab Exams: With the introduction of the Alcatel-Lucent Network Routing Specialist II certification, the NRS II Lab exam (NRSII4A0) is now a prerequisite exam for the Alcatel-Lucent 3RP and SRA certifications.

3. What do these changes mean to you as an existing Alcatel-Lucent SRC Program participant?
With the removal of the prerequisites for the written exams, you can now write these exams in any order. We encourage you to visit Prometric's web site to register for Alcatel-Lucent SRC written exams: www.prometric.com/alcatel-lucent.
If you are working towards the SRA certification, the following rule applies: effective June 1, 2009, the NRS II Lab exam is a prerequisite to achieve the SRA certification. Therefore, you need to complete the SRA certification by May 31, 2009, if you want to be exempt from the NRS II Lab exam prerequisite.

4. What do these changes mean to you if you hold an existing Alcatel-Lucent NRS certification?
The NRS has been renamed to NRS I but there are no functional differences between the NRS I and NRS certifications. Your existing Alcatel-Lucent NRS certification is still valid, and you can build off of this certification to work towards the new Alcatel-Lucent NRS II certification.

BGP Decision Process

2008-11-28T13:41:00.000+07:00

For every prefix a BGP router receives, the first thing checked is the NEXT_HOP attribute. If the next hop is not accessible (not in the IP routing table), the prefix is rejected. For routes received from an IBGP peer, the next check after the next hop check is to see if the routes are synchronized. Unsynchronized routes are rejected only if synchronization is enabled. The following steps in the BGP decision process apply only if there is more than one route to a particular prefix:

Prefer the path with the highest weight
Prefer the path with the highest local preference
Prefer locally originated routes (Next Hop = 0.0.0.0)
Prefer the path with the shortest AS path
Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is lower than INCOMPLETE
Prefer the path with the lowest metric or MED
Prefer EBGP routes over IBGP routes
Prefer the lowest IGP metric to the next hop
Prefer the path from the router with the lowest router ID

Alcatel-Lucent Announces Service Routing Certification Program Changes

2008-08-14T13:19:00.010+07:00

Juniper Networks Certified Code Exam

2008-08-11T12:33:00.000+07:00

JN0-120 - Juniper Networks Certified Internet Associate, E-series (JNCIA-E)
JN0-130 - Juniper Networks Certified Internet Specialist, E-series (JNCIS-E)
JN0-140 - Juniper Networks Certified Internet Associate, UAC (JNCIA-AC)
JN0-201 - Juniper Networks Certified Internet Associate, M-series (JNCIA-M)
JN0-310 - Juniper Networks Certified Internet Associate, WX (JNCIA-WX)
JN0-320 - Juniper Networks Certified Internet Associate, DX (JNCIA-DX) retiring 12/1/07
JN0-321 - Juniper Networks Certified Internet Associate, DX (JNCIA-DX) NEW Exam
JN0-303 - Juniper Networks Certified Internet Specialist, M-series (JNCIS-M)
JN0-341 - Juniper Networks Certified Internet Associate, ER (JNCIA-ER)
JN0-350 - Juniper Networks Certified Internet Specialist, ER (JNCIS-ER)
JN0-521 - Juniper Networks Certified Internet Associate, FWV (JNCIA-FWV)
JN0-531 - Juniper Networks Certified Internet Specialist, FWV (JNCIS-FWV)
JN0-541 - Juniper Networks Certified Internet Associate, IDP (JNCIA-IDP)
JN0-561 - Juniper Networks Certified Internet Associate, SSL (JNCIA-SSL) retiring 12/1/07
JN0-562 - Juniper Networks Certified Internet Associate, SSL (JNCIA-SSL) NEW Exam

Routing Fundamentals

2008-06-12T16:09:00.002+07:00

Routing is the process of moving information across an internetwork from a source to a destination. Routers maintain routing tables that describe how to get to destinations in the
network. Routers use a routing protocol to exchange routing information with other routers to
update their routing tables.
Routing tables contain information such as:
• Protocol type
• Destination/next hop associations
• Routing metrics
• Outbound interface

Routing versus Switching
Routers and switches both move information from source to destination, but they use different
information to accomplish the task:
• Switching normally occurs at Layer 2 (data link layer) and routing occurs at Layer 3
(network layer)
• Switches act upon the MAC address and routers act upon the IP address
• Switches keep tables of MAC addresses and routers keep tables of IP networks

Static and Dynamic Routing
Static routes are entered into a routing table manually and do not change unless someone
manually changes them. Dynamic routing builds routing tables using routing protocols and
continuously updates the tables as the network topology changes.

Routing Design Goals
Routing algorithms have some of the following goals:
• Optimal Route Selection
• Simplicity
• Robustness and stability
• Rapid convergence
• Flexibility
• Delay
• Load
• Reliability
• Path Length
• Cost – some paths may cost more to use than others. Operators may prefer to use links that
they own because of lower costs.

Dynamic Routing Protocols
Interior Gateway Protocol (IGP)
• Used for exchanging routing information within an autonomous system (AS).
• Uses routing metrics such as hop count
• Commonly used: OSPF, RIP, IS-IS, iBGP

Exterior Gateway Protocol (EGP)
• Used for routing between autonomous systems
• Routing protocols may be different between ASs
• Chosen path may not be optimal since it can’t compare routing metrics from multiple ASs
• Commonly used: BGP-4

Note: An autonomous system (AS) is a network under a single administrative authority.

from Alcatel Lucent Doc.