tools dump

Multi-Layer WAN SDN use case

2018-02-01T16:23:00.001+07:00

Good article about Multi-Layer WAN SDN use case.

SDN Based Traffic Engineering

2018-01-19T15:47:00.000+07:00

In my previous post i mention one of WAN SDN use case is Traffic Engineering (TE). This post will reveal what improvement that SDN based TE can offer compared to classical TE.

Classical Traffic Engineering in many WAN network, RSVP based TE is commonly used to accommodate a data path that not following the calculation of routing protocol.

However RSVP-TE also have shortcoming, hence not optimal solution.

The CSFP alogrithm contained in oane IGP area.
N-Squared, RSVP requires to established complete full mesh LSP between all PE
Hold the state of RSVP session in the node, consume more CPU and memory resources
Relatively complex control plane, small router could have an issue if it joining a big network.

Although many workaround is provided to overcome the issues mentioned, but it just introduce more complexity inter term of network design as well as operation. Hence all this problem lead the birth of new simpler protocol, Segment Routing.

Segment Routing is tunneling protocol which based on the Source Routing paradigm, the source node know the path to tail-end node, encode the segments (which form the path) in packet header and use OSPF/ISIS extension to carried segment information.

The segment is encoded as:

MPLS label or an ordered list of hops represent by a stack of MPLS labels, similar like regular MPLS data plane.
IPv6 address or an ordered list of hops represent by a number of IPv6 addresses in the IPv6 extension header.

We can think a segment as a set of information from ingress PE to dictate how is the packet is going, whether follow the shortest path to node N, follow the shortest path for prefix P, or explicitly define which link/node/ to go node N. The application of Segment Routing for Shortest path application is illustrate below

PE2 advertises Node Segment into IGP (Prefix-SID Sub-TLV Extension to IS-IS/OSPF) then all routers in SR domain install the node segment to PE2 in the MPLS data-plane - a segment is actually an LSP, in this process no LDP or RSVP control-plane involved. Traffic that going from PE1 to PE2, PE1 pushes on node segment {800} and uses shortest IGP path to reach PE2. Active segment is the top of the stack for MPLS, P1 and P2 implement CONTINUE (swap) action in MPLS data-plane, P3 implements NEXT (pop) action. No state held in network with the exception of segment list for tunnel held at PE1.

For the Traffic Engineering application, the path can be computed either distributed in each router involved along the path - similar like classic RSVP-TE or centralised by external computation engine.

Path Computation Element, One of WAN Controller component is The Path Computation Element (PCE) which has the concept to separates between path computation and path signaling function which will gives operators more control of their networks, adds ability to apply network operator policies, address multi-vendor integration considerations.

Before PCE can compute the path it has to understand the view network topology to built Traffic-Engineering Database (TED) in which WAN controller can ease this by establishing BGP sessions to one or more router or path computation Client (PCC). Through this sessions PCE receives link-state prefixes via BGP-LS NLRI.

After the network topology can be discovered, WAN Controller can perform path computation and asked routers of the network to established, re-signal or tear-down where Path Computation Element Protocol (PCEP) facilitated this.

All in all, the protocols explained are introduced to addressing the problem space happed in most of WAN network, become a building block for SDN Based Traffic Engineering. Segment Routing, which expected to replace RSVP-TE because its comes with low overhead. And with PCEP, the calculation of path is off-loaded to WAN SDN Controller which in turn can reduce manual path provisioning also provide also the abstraction of network resources hence more complex path calculation objective and constraint can applied easily.

WAN SDN Controller Deep Dive

2018-01-06T18:30:00.000+07:00

My previous post, the overview of WAN SDN Controller is explained. So, in current post i will describe the functional element of WAN SDN Controller and it's correlation with some use-cases.

If we refer to Verizon SDN NFV Reference Architecture

Service Management

The Service management function for all aspect of service installation and management. It is hiding the complexity of the network since the resources are been abstracted, hence the northbound application/orchestration function can call to Service management API to create a complex services, which WAN connectivity only one of its component. let's say an orchestrator want to create DC interconnect which spanning from one DC to another. The orchestrator can call API to DC SDN controller to spin-up the VMs and create interDC connectivity with VXLAN. In parallel orchestrator tell WAN SDN Controller to prepare WAN connectivity from IP and Optical networks between the DCs

Resource Management and Optimization

This function enables northbound systems to create, modify or delete resources. It provides functions like optimal path selection, tunnel load balancing, bulk optimization, traffic reroute for maintenance actions, etc. The Resource Management function can use the statistics collected by the SDN Controller itself or it can interface with standalone analytics solutions that may trigger optimization actions.

The use case example are:

Path(could be MPLS LSP or Optical Cross-Connect) creation and modification
Optimised the path based on certain algorithm, hence not following IGP mechanism normally based on cost, this could unlock stranded bandwidth form underutilized link connection which neglected by normal IGP path selection mechanism.
Path optimization based on certain internal or external trigger. ie: if the link utilisation of certain link reach certain threshold the path that using this particular link is become subject to be optimised.
FireBlanket, the WAN SDN controller can push a certain network policies to all IP devices in network perimeter based on external system intelligence that detected potential anomaly like DDoS attack.

Statistics and Topology

An SDN Controller provides several basic functions, such as statistics collection (per service and/or resource) and topology discovery. This information is used as input to the Resource Management function and can also be exposed to northbound systems via ReSTful APIs.

Some of use case that can use this functional elements are:

Network Statistic Data Warehouse, the statistic of the network can be exported to external data warehouse to be used for certain analytics.
Offline Traffic Engineering, A tools can be developed to simulate certain scenario in the network by taking the advantage of statistic and topology information from this element

Forwarding Rules Manager

When the network contains white boxes, a Forwarding Rules Function is required to define the exact set of forwarding rules to be pushed to those white boxes. The Forwarding Rules Manager takes into account topology information and the service and resource related inputs from the Service Management and Resource Management functions.

Adaptation

The adaption function translates abstract, device-independent data models that are used by the Service Management and Resource Management functions to device-specific data models. These device independent data models are service-oriented models that are rendered in YANG.

South-bound protocol stacks

Depending on the network element and the required action, different protocols may be used. OpenFlow is one of the protocols of choice for managing white boxes. The choice of the south bound protocol depends on the use case and will also require additional adaptations / extensions. NETCONF (RFC 6241) is emerging is the primary candidate for provisioning network functions in general. PCE Protocol (PCEP, RFC 5440) is the primary protocol for path setup in RSVP-TE MPLS networks. PCEP, OF, and NETCONF are also being leveraged for Segment Routing-based MPLS networks. BGP-LS (still in the Internet Draft stage) can be used for topology discovery. In addition, certain network functions may require proprietary protocols.

Most of south-bound protocol stacks are relatively new, for example Segment Routing this protocol is created to address the limitation of IP/MPLS technology.

WAN SDN Controller

2018-01-03T16:26:00.004+07:00

Intro

Right now we don't need to spend much to realize an idea. With Cloud service delivery we don't need to setup server stack just to test an application prototype instead we can use cloud service like AWS lamda.

Cloud service delivery models also impacting the Communication Service Provider (CSP)'s services offering outlook. Enterprise demand CSP to be more agile turning up the service. Previously the service delivery model was CSP providing fixed pipe of bandwidth to enterprise in turn, enterprise will pay fixed price for the service.

The service model looks simple fixed bandwidth for fixed price, actually it is like that because the difficulty that CSP face to provide value added services ie: bandwidth calendaring, bandwidth on-demand with the legacy MPLS infrastructure which normally deployed by CSP. The difficulty lies on manual labor to align multiple CSP's organizations from planning, operation and customer service not to mention the IT/OSS departement to provide proper billing for such service.

By allowing applications to consume IT resources on-demand, cloud technologies have fundamentally changed the way datacenters (DCs) are being designed and operated. Software Defined Networking (SDN) extends the cloud model to the network by allowing applications to consume network connections as quickly and as easily as they consume virtualized compute and storage. In an SDN-based DC network, connections are not permanent entities; they are initiated by virtual machines in seconds, and are dismantled when no longer required.

As the cloud expands to encompass multiple DCs and users across metro and wide area networks (MANs and WANs), applications will expect the carrier network connections that underpin this new, distributed cloud fabric to leverage SDN and be just as easy to set up and consume.

As mentioned before Cloud service delivery change the way the CSP design and operate its network fundamentally. Software Defined Networking (SDN) initially introduced in Data Center (DC) environment by allowing the applications to quickly consume the resources like networks connections, virtualized compute and storage. Hence, the services can be build in seconds and collapsed in seconds. When the cloud service expanded to multiple DCs across WAN, the application will expect the carrier network connections that underpin this new, distributed cloud fabric to leverage SDN and be just as easy to set up and consume.

What is WAN SDN Controller?

Achieving SDN in the WAN is no trivial task. While DCs are simple, homogeneous and can count on essentially limitless bandwidth, carrier networks are complex, multi-vendor, and are subject to many technology and bandwidth constraints. Any attempt to introduce a faster and more automated way of provisioning the WAN must work in concert with provisioning systems for existing services. The dynamic consumption nature of distributed clouds and their users will put significant pressure on operational models designed for static and predictable traffic patterns. SPs will need to augment existing traffic engineering processes with a dynamic resource management capability that can ensure network efficiency, resiliency and availability in the face of rapidly changing cloud connectivity needs.

The industry has already begun the process of evolving SDN for carrier networks with proposals to abstract and open the proprietary packet/optical layer to external control using OpenFlow. While this is a good starting point, little value can be realized without a broader SDN framework that can provision and correlate topology, resource and constraint information across multiple layers – including packet/optical, Ethernet, IP and IP VPNs. Only a multi-layer SDN framework has the global visibility and universal control necessary to deliver on the SDN promise of increased network agility, efficiency and scale.

Verizon's SDN & NFV Reference Architecture, has realized the vision to provide. it is Published is Published early 2016 by Collaboration between Verizon, Alcatel-Lucent, Nokia, Ericsson, Cisco, HP, Samsung, Intel and Red Hat which capture following Key points:

Captured NFV MANO and SDN in a single architecture
Recognized the end-to-end orchestration is more than just NFVO
Recognized the difference between DC SDN and WAN SDN
Showed an evolution of traditional EMSs to new management systems

WAN SDN Control entity - in general, a WAN SDN controller must accomplish the following objectives:

Northbound APIs for network abstraction and programmability to be used by customer facing orchestration systems and third-party applications
Model-driven Adaptation Layer that allows network service models to help drive north bound and south bound mappings
Multi-layer and multi-vendor control
Automated management of end-to-end services
Resource optimization
Topology discovery and rectification
Statistics collection and processing
Provide a control interface to hybrid/classical control mechanisms

The following figure depicts the functional elements of WAN SDN Controller

WAN SDN Controller Use Case

The following are the use cases that is possible by the framework.

Optimal Path-Selection:

Flow steering
Egress peer engineering
Enhanced quality of experience
Enhanced ECMP

Automated Service Fulfillment:

Simplified OSS and operation
Cross layer correlation
Zero touch configuration

Bandwidth and Link Management:

Tactical path provisioning
Tactical bandwidth provisioning
Run the network hotter, unlock the stranded bandwidth

Assurance:

Analytics driven optimization
Telemetry
Fault and alarm correlation
Offline traffic engineering tool

Appify

2015-01-25T18:44:00.002+07:00

appify — create the simplest possible Mac app from a shell script

https://gist.github.com/mathiasbynens/674099#!/bin/bash

if [ "$1" = "-h" -o "$1" = "--help" -o -z "$1" ]; then cat <
appify v3.0.1 for Mac OS X - http://mths.be/appify
Creates the simplest possible Mac app from a shell script.
Appify takes a shell script as its first argument:
`basename "$0"` my-script.sh
Note that you cannot rename appified apps. If you want to give your app
a custom name, use the second argument:
`basename "$0"` my-script.sh "My App"
Copyright (c) Thomas Aylott
Modified by Mathias Bynens
EOF
exit; fi

APPNAME=${2:-$(basename "$1" ".sh")}
DIR="$APPNAME.app/Contents/MacOS"

if [ -a "$APPNAME.app" ]; then
echo "$PWD/$APPNAME.app already exists :("
exit 1
fi

mkdir -p "$DIR"
cp "$1" "$DIR/$APPNAME"
chmod +x "$DIR/$APPNAME"

echo "$PWD/$APPNAME.app"

Reinventing Copper

2013-07-03T21:36:00.000+07:00

Today, for broadband access technology everybody talking which is the better technologies for wireless.. LTE, TD-LTE, FD-LTE, LTE-Advance, but soon it will be SHIFT to wireline, because nonetheless, the speed and bandwidth battle is always won by the Cable Broadbad.

There are two different medium for wireline access fiber or copper. For greenfield deployment fiber technology such as PON is the best solution. But... big telco provider tend to use existing twisted copper investment while gradually deploy their fiber network, how much copper technology can deliver the speed? following graphic is the answer.

With VDSL2 as the base line, bonding is like bundling two pair of cable to get more bandwidth. headphone.While DSL Phantom Mode technology is a bit of magic for the copper network. It creates a third (phantom or virtual) channel over 2 regular copper pairs. Vectoring is canceling crosstalk between two pair of copper, the idea is same like noise-canceling technology in your headphone.

And the state of the-art-technology is ITU-T pre-standard, G.Fast. The main requirement of this standard is to achieve high peak rate 500 Mb/s at 100 m. By combining VDSL+, bonding, phantom-mode, vectoring and G.Fast its field-proven we can achieve more than 1 Gb/s at 70 m.

High Availability Network-Level Redudancy

2012-08-03T13:49:00.001+07:00

• IEEE 802.3ah Ethernet In The First Mile
• BFD
• MC-LAG, MC-APS, ML-PPP
• MC-RING
• G.8032 Ethernet Ring Protection
• ECMP
• MPLS FRR
• (hot) standby secondary LSP’s
• VRRP
• SRRP
• tweak IGP timers
• ‘overload on boot’ flag
• tweaks in BGP (next-hop and peer tracking, multiple RD for same address…)
• PW status bits
• ICB (inter-chassis backup)
• MAC-flush in VPLS

IP CORE ROUTER

2012-05-23T10:35:00.004+07:00

IP CORE ROUTER

MPLS-TP Introduction and Overview

2011-10-04T14:41:00.003+07:00

For some time now, transport network operators have been striving to migrate gracefully from circuit-switched modes of operations to include more packet-switching technology, for the potential bandwidth utilization and network performance gains that can be achieved. As IP/MPLS and Ethernet technologies have become the de-facto packet-based technologies of choice, transport network operators have sought to evolve their networks with either the implementation of or interoperation with these technologies (or both).

However, the operations of packet-based and circuit-based architectures differ greatly. IP/MPLS-based networks have developed over time a planning and engineering tool set required to manage the more dynamic resiliency capabilities available in packet networks. Yet transport networks tend to be more static in their configuration, with re-engineering typically undertaken much less frequently. This has resulted in a significantly different skill set owned by transport network operations staff, one more attuned to the capabilities of the transport network. The objective of the MPLS-Transport Profile is to bridge this gap, from a technological as well as an operational perspective.

MPLS-TP provides a harmonizing paradigm spanning IP/MPLS-based and optical transport networks. While based on the IP/MPLS forwarding paradigm, MPLS-TP extends IP/MPLS capabilities by adding transport-based OAM enhancements more like those of SONET/SDH and OTN. MPLS-TP pursues the goal of providing resiliency and OAM capabilities similar to SONET/SDH and OTN networks, while maintaining the benefits associated with packet-based networking.

MPLS-TP is therefore a profile – or a specific subset – of an MPLS functionality set that is being extended to meet the key design parameters identified. The diagram shown below illustrates the relationship between the Transport Profile and the existing and expanded MPLS toolset.

Prior to the definition of the MPLS-TP requirements in RFC5654, there existed a set of MPLS functions that have been widely deployed in IP networks. Some of these meet the requirements in RFC5654 and are thus suitable for a transport network operational environment. These include the MPLS and PWE3 (pseudowire emulation edge-to-edge) architectures, the MPLS forwarding paradigm, and the Generalized MPLS (GMPLS) and pseudowire control planes. Hence these form a part of the transport profile. However, some functions do not meet these requirements, and are thus excluded. These include Equal Cost Multi-Path (ECMP), the mandatory use of IP forwarding in the data path, and LDP signaling that specifically creates multipoint-to-point paths (which thus causes LSPs to arbitrarily merge and lose the association of a label to an individual source).

In addition to these existing functions, some of the requirements outlined above will be met by adding a limited range of new functions to MPLS. These new functions also fall within the transport profile and form an inherent part of an extended set of MPLS functions – specifically the OAM, protection, and provisioning capabilities listed.

MPLS-TP is being standardized by the Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T). Many MPLS-TP standards already have been ratified, while the bulk of the work remaining revolves around the OAM toolset. Upon full ratification of all related standards, MPLS-TP will enable connection-oriented, packet-optical transport, based on widely deployed MPLS protocols with the performance and operations characteristic of today’s transport networks, while also ensuring compatibility with today’s IP/MPLS-based networks.

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 applications used 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 requires methods to efficiently deploy and scale distributed group applications across the network. This is accomplished by using protocols that reduce the network load associated with sending the same data to multiple receivers and that alleviate the high host/router processing requirements for serving individual connections.

Internet Group Management

Protocol (IGMP)

IGMP is a protocol that allows end stations to join what is known as a multicast group. Joining a multicast 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 multicast 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 periodically send out queries to discover which groups are active or inactive on particular LANs. Routers communicate with each other using one or more protocols to build multicast routes for each group.

Multicast Distribution Trees

Multicast-capable routers create 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 distribution 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 preceding 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 network (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 switch forwards 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 message allows Layer 2forwarding decisions to be made. IGMP Snooping IGMP snooping improves 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 message to the rendezvous point. An Anycast Rendezvous Point (RP) provides load balancing, redundancy, and fault tolerance by assigning the same IP address to multiple 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 message from a host, the switch removes the host’s table entry. IGMP requires a switch to examine all multicast packets and therefore should be implemented only on high-end switches. Multicast Forwarding In unicast routing, traffic is routed from the source to the destination host. The router scans its routing table for the destination address and then forwards 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 packet. 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