Past news, I know, but we still have to rep’ the amazing music our local Russian DJs bring to Minneapolis.  DJs Ian Russ, Alik (YouTube, LastFM), and Tranceaddict brought an amazing and unique fest of music for one night at Envy Nightclub at their annual Euro Holiday Party last Friday.  The scene these guys bring is so unique it even attracted local Dmitry Chaplin, finalist from ABC’s Dancing With The Stars, into attending the event. The night started out with some of the best new, melodic, techy trance and ended with a blast from the past of classic melodic hard trance and eurodance straight from the other side of the pond. Look forward to more events from these guys to come!

Songs played for the night:

Ian Russ
Mat Zo – Default
Tocadisco – You better run
BT – Every Other Way (Armin Van Buuren Rmx)
Dash Berlin – Waiting (Vocal Mix)
Faithless – Sun To Me (Alex MORPH rmx)
Barry Jay – Infused
Bobina – More Than Love (Heatbeat Mix)
Kyau and Albert – Be there 4 U (Rafael frost Rmx)
Paul van Dyk – Home (Cosmic gate Rmx)
Giuseppe Ottaviani – Changing Ways
John O’Callaghan – Take it All the way

DJ Alik
Moonbeam Feat Avis Vox – About You (Russian Original Mix)
Omen feat Boris Breden – Skuchayu (Original Mix)
Armin van Buuren feat VanVelzen – Broken Tonight (Original Mix)
Smyslovye Gallucinacii – Vechno molodoy (DJ Netrin Extended Mix)
Cerf, Mitiska & Jaren – Beggin’ You (Original Club Mix)
Editors – Papillon (Tiesto Remix)
Infinity – Ne Ischezay (Alex Menco Remix)
Dennis Sheperd & Cold Blue – Freefalling (Cold Blue Mix)
Be Gold – Sun Stroke (Original Mix)
Oksana Pochepa – Kislotny DJ (DJ Stas Tritus Remix)
Basshunter – Russia Privjet

Tranceaddict
Sveta x- nam na dvoih
Infinity- ostnovites
cerf & metiska- you never said (randy boyer remix)
dj aligator vs variant k- mne mnogo nenuzhno
D.I.P project- leto stoboy
Tiesto- traffic
Blank & Jones- DJ culture
Lange- Out of the sky (kayu and albert remix)
Warp bros. vs. Aquagen- phat bass
Basshunter- now your gone (dj alex remix)
Alphazone- revelation
Tiesto- adagio for strings
Ummet Oczan- Time Wave Zero
4 strings- take me away (reward remix)
Richard Durand- Always the Sun

Their next big move….Scott Charter and Mike Hollander, co-founders of  IT services company, WBS Connect recently announced an acquisition by Global Telecom & Technology (www.gt-t.net).  Combining WBS Connect’s premium services such as cloud computing and high-definition video conferencing with GTT’s global network, the newly combined company will host more than 1000 customers across 80 countries world-wide.  Scott Charter and Mike Hollander will both serve on GTT’s leadership team.

For the complete press release, please read below:

GLOBAL TELECOM & TECHNOLOGY COMPLETES ACQUISITION OF WBS CONNECT

Transaction Combines Large Customer Base With Strong Operations Platform For Future Growth

McLean, VA, December 16, 2009 — Global Telecom & Technology, Inc. (“GTT”) (OTCBB: GTLT), a leading global network integrator that provides its clients with a broad portfolio of wide-area network and IP transit services, today announces the completion of its acquisition of privately held WBS Connect, LLC. (“WBS Connect”).

This news comes on the heels of the parties’ receipt of the regulatory approval for the acquisition from the Federal Communications Commission. With this acquisition, GTT adds over 400 customers and a broader IP transit and Ethernet product suite.  Additionally the company’s network infrastructure now spans over 60 points of presence in major metro markets throughout North America, Asia and Europe.

The final purchase consideration consisted of 500,870 shares of GTT common stock, $1.3 million in cash, seller notes, an earn out opportunity for the sellers, and the assumption of certain WBS Connect liabilities and its working capital.

WBS Connect co-founders and managing directors Scott Charter and Mike Hollander will remain with the organization and serve on the Global Telecom & Technology leadership team. “It’s a truly rewarding opportunity to bring value through our products and technology to an organization of this caliber, while enhancing the experience for our customers,” states Scott Charter, the newly-assigned Chief Marketing Officer at GTT.

“We’re thrilled to welcome Scott Charter and Mike Hollander to the GTT team,” states Rick Calder, President and Chief Executive Officer of GTT. “We believe that adding WBS’ talents, resources and complementary product set into our robust GTT company portfolio further enhances our ability to deliver additional value to our customers.”

“With the close of this transaction, GTT reaches an important milestone in its evolution as a leading global network integrator,” continues Calder. “This acquisition leverages our past financial successes and positions the company for the next level of growth.  By layering WBS Connect’s services onto our existing operational platform, we can expand our EBITDA and enhance our financial profile.”

About Global Telecom & Technology

GTT is a global network integrator providing a broad portfolio of Wide-Area Network (WAN) and IP transit services. With over 800 supplier relationships worldwide, GTT combines multiple networks and technologies such as traditional OC-x, MPLS and Ethernet, to deliver cost-effective solutions specifically designed for each client’s unique requirements. GTT enhances its client performance through its proprietary Content Management Database (CMD), providing customers with an integrated support system for all of its services.  GTT is committed to providing comprehensive solutions, project management and 24×7 global operations support. Headquartered in McLean, Virginia, GTT now has offices in Denver, London and Dusseldorf, and provides services to more than 700 enterprise, government, and carrier clients in over 80 countries worldwide. For more information visit the GTT website at www.gt-t.net.

Forward-Looking Statements:

This release may contain “forward-looking statements” or other information related to the company’s future growth, expenditures, personnel, product and service enhancements and deployments, strategy or other materials GTT releases to the public or files with the United States Securities & Exchange Commission (“SEC”). You should consult any further disclosures on related subjects in our annual reports on Form 10-K, our quarterly reports on Form 10-Q and current reports on Form 8-K filed with the SEC. Such forward-looking statements are and will be subject to many risks, uncertainties and factors relating to our operations and the business environment that may cause our actual results to be materially different from any future results. Additional information concerning these and other important factors can be found under the heading “Risk Factors” in GTT’s annual reports on Form 10-K and quarterly reports on Form 10-K filed with the Securities and Exchange Commission. Statements in this release should be evaluated in light of these important factors.

# # #

For GTT Investor Relations Inquiries, please contact:

Eric Swank

Chief Financial Officer

1.703.442.5529

Eric.Swank@gt-t.net

Edge-LSR support 32 routing processes

Hello everyone faithful enough to believe I’ll keep this thing going. That’s the plan, but you’ve likely noticed it’s been more-than-spotty. Hell! Just keep checking back and “one fine morning…”

So you won’t believe what I came across this early afternoon coming around snowy Lake Harriet in the Jeep…two American Bald Eagles perched atop a tree on the west shore not far from “upper lake” (44th/45th sts.) stunning!

Apparently there have been several recent sightings around Harriet & Calhoun. And to think they were endangered not all that long ago. Marvelous! I’ll never forget it, especially as it becomes my first blog post from a phone. Man o man, Eagles in the city and telling the world from handheld device…(I’m easily astounded).

Sorry about the marginal iPhone pic…shouldvd learned long ago to take my camera everywhere.

See you back here soon…yes YOU!

Peace,
DVE

Hello and welcome to all Twin-City Dance Music fans! It is a privilege to present to you our very own website. All of us affiliated with the TranscenDance project are excited to have this opportunity. As you know, we have been sharing our favorite Electronic Dance Music with you every Sunday night for the past three weeks. Thank you all for the support! Now, we would like to further our vision by providing transcendancempls.com as a resource and a forum. Here, you may find information on an array of genres and artists (we will research tirelessly!), DJ mixes (including the show and its guest-mixes), links to other sites/blogs/shows, and much more. It is also encouraged that you as listeners use this site as a way to become more involved in the show. We want to hear what you think as well as whatever feedback you may have… remember: this is for YOU!

So… together… let’s transcend through the world of Dance Music.

The show airs Sunday nights from 9-11pm on 91.7FM (in Minneapolis) or you can catch it from anywhere on the globe at www.augsburg.edu/kaug (click “listen now”). We hope to speak to you soon!

-Jason Magnon

“It’s not love for music, it’s a passion, and it goes beyond liking, and beyond a hobby, it’s about a way of living. Music is essential for my life.” Armin van Buuren (voted #1 DJ in the world in 2009 and 2008).

“After silence, that which comes nearest to expressing the inexpressible is music.” Aldous Huxley (not by any means a DJ… but the quote is cool).

sometimes
it’s the second day
or the third
when it hits you
that someone is gone
and that they won’t
be back
ever

he was taken too young
he wasn’t finished
with his music
we weren’t
ready to let go of
his song

my new rescue cat is curled around me
like a fur stole keeping me warm
and I wonder who is rescuing who

and I am thinking about
loss

and why

L. K. Thayer

Art Collage Tribute by

Janson Michael Steffan

All Rights Reserved

© 2009

AToM stands for Any Transport over MPLS, a quite reassuring technology which, provided you have a MPLS enabled network and some good gears, let you set up L2 circuits across your IP backbone.

This lab offers a very simple topology with 2 AToM links; an ethernet with an 802.1q trunk and a frame-relay link.

Core

Core (P) routers configuration is pretty simple; we only enable MPLS switching on interfaces toward PE routers and setup LDP for labels exchange. A good core doesn’t care about what kind of traffic it switches!

P1:

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 description PE1 facing interface
 mpls ip
!
interface FastEthernet1/0
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0 force

PE routers

The hard work is done on PE routers. PE routers face CE routers, which they receive L2 traffic from, and network core P routers, which they have to send MPLS encapsulated traffic to.
In order to build up a L2 circuit, PE routers have to setup a pseudowire connection between them, so they know how to switch traffic. Each pseudowire uses a virtual-circuit ID (VC ID), which is locally significant on each PE pair and is used to identify the pseudowire itself and to bind it to a specific MPLS label.

First off, they must be MPLS aware:

PE2

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.2.2 255.255.255.255
!
interface FastEthernet0/1
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0

Now, we have to set up pseudowires between PE and L2 connections with CEs.

Let’s start with the Ethernet 802.1q trunk.

Port mode Ethernet over MPLS (EoMPLS)

In port mode EoMPLS every frame received on a PE interface is forwarded to the other PE almost unchanged (just preamble and FCS are removed).

Basic configuration is very simple:

PE2

interface FastEthernet0/0
 description CE_Switch2 facing interface
 no ip address
 duplex auto
 speed auto
 xconnect 1.1.2.1 10 encapsulation mpls

The xconnect command does all the work! This command tells the PE router to encapsulate every frame in a MPLS packet and to forward it to the peer 1.1.2.1 using VC ID 10.
It also allow Label Distribution Protocol (LDP) to exchange informations about the pseudowire circuit between PEs (VC ID / label mapping, VC type, MTU).

Once we have applied this configuration to both PE routers (on PE1 we have to change the xconnect peer address!), we can verify if LDP did its work and if pseudowire is up:

PE2#show mpls l2transport vc 10 detail
Local interface: Fa0/0 up, line protocol up, Ethernet up
  Destination address: 1.1.2.1, VC ID: 10, VC status: up
    Output interface: Fa0/1, imposed label stack {18 16}
    Preferred path: not configured
    Default path: active
    Next hop: 172.16.2.0
  Create time: 01:16:07, last status change time: 01:15:44
  Signaling protocol: LDP, peer 1.1.2.1:0 up
    MPLS VC labels: local 16, remote 16
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    [cut]

Now, setup and test VLAN connectivity on customer side:

Net1_H1#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
end
Net1_H2#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
end
Net1_H1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/168/192 ms

Frame-relay over MPLS, DLCI-to-DLCI mode

Frame-relay over MPLS requires a few more lines of configuration, but the pseudowire setup is the same as EoMPLS.

We have to enable frame-relay switching on the PE router, configure the Serial interface as DCE and setup the switching path for the DLCI:

PE2

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR2-FR1 Serial1/0 201 l2transport
 xconnect 1.1.2.1 20 encapsulation mpls

PE1

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR1-FR2 Serial1/0 102 l2transport
 xconnect 1.1.2.2 20 encapsulation mpls

Let’s verify everything is ok:

PE2#show mpls l2transport vc 20

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Se1/0          FR DLCI 201                1.1.2.1         20         UP

With this configuration we have DLCI 102 for FR1-to-FR2 traffic, and DLCI 201 for FR2-to-FR1 traffic.

Customer side configuration:

FR1

interface Serial0/0
 no ip address
 encapsulation frame-relay IETF
!
interface Serial0/0.1 point-to-point
 ip address 172.16.0.1 255.255.255.252
 frame-relay interface-dlci 102

Similar configuration on FR2:

interface Serial0/0.1 point-to-point
 ip address 172.16.0.2 255.255.255.252
 frame-relay interface-dlci 201

Some tests…

FR1#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 615              Num Status msgs Rcvd 573
  Num Update Status Rcvd 0              Num Status Timeouts 42
  Last Full Status Req 00:00:24         Last Full Status Rcvd 00:00:24
FR1#
FR1#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

  input pkts 115           output pkts 120          in bytes 32266
  out bytes 33844          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 100       out bcast bytes 31764
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 01:43:39, last time pvc status changed 01:10:26
FR1#
FR1#ping 172.16.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/185/220 ms

Please note how the subnet 172.16.0.0/32 on the FR routers does not conflict with 172.16.0.0/31 between P routers; it’s on a totally different L3 domain and it is not routed by the network, but transparently encapsulated in L2 over MPLS packets.

Packet captures

You can find some nice packet captures about this lab at PacketLife.net Captures section, under the MPLS category; they have been taken on P1-P2 link, with inner (pseudowire) and outer MPLS label on top of every packet. They are “LDP_Ethernet_FrameRelay”, which shows how LDP setup the pseudowire circuit, “EoMPLS_802.1q” and “Frame-Relay over MPLS”, which show an ICMP ping encapsulated in Ethernet and Frame-relay respectively.

Anyway, if you don’t know PacketLike.net you must take a tour of that great website, really worth it!

Conclusion and download

This post only shows a little basic configuration of some AToM solutions; there are many more capabilities than which I wrote on this blog. A good starting point is to read documents you can find using links below.

If you want to download this GNS3/Dynamips lab, you can find it here.

References

Cisco.com: MPLS AToM Technical Overview

Cisco.com: Any Transport over MPLS

Was doing a lab for FRoMPLS and thought it would be a good idea to have either PE as a different platform. I chose the “C3640-JSX-M” and “C7200-K91P-M” which are both images listed for the lab. When doing the basic setup for mpls during the verification I saw OSPF as up but LDP was not, even after some time;

PE1-7206#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DR         00:00:32    10.0.12.2       FastEthernet0/0
PE1-7206#show mpls ldp neighbor

PE1-7206#show mpls ldp discovery
Local LDP Identifier:
10.0.0.1:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit

You can see from the above verification that yes MPLS is turned on for the interface for which the OSPF neighbor is on. The same output was shown on the alternate PE with one minor difference;

PE2-3640#show mpls ldp discovery
Local LDP Identifier:
10.0.0.2:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (tdp): xmit

Although for show commands it doesn’t seem to matter whether you use the mpls or tag-switching version it does for the actual communication over the link. This is due to the fact that they use different ports for communication (646 / 711 for LDP / TDP respectivly). A debug reveals that the packets actually use the same source and destination port.

PE2-3640#debug ip packet detail
IP packet debugging is on (detailed)
*Mar  1 00:15:24.315: IP: s=10.0.12.2 (local), d=255.255.255.255 (FastEthernet0/0), len 48, sending broad/multicast
*Mar  1 00:15:24.319:     UDP src=711, dst=711

This is important for two reasons, one if you are configuring access-lists the best practice answer would be “permit udp any eq 711 any eq 711″ and two similar to BGP a router will not even listen on a given port unless the port is opened by turning the protocol on.

*Mar  1 00:19:51.527: IP: s=10.0.12.1 (FastEthernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
PE2-3640(config)#mpls label protocol ldp
*Mar  1 00:19:54.591: IP: s=10.0.12.1 (FastEthernet0/0), d=224.0.0.2, len 62, rcvd 0
*Mar  1 00:19:54.591:     UDP src=646, dst=646

From the above it can be seen that until UDP 646 is opened by changing the label protocol to LDP (which is non-default for this IOS/platform), the packets are not even inspected at layer four (it seems).

All in all, I will be watching out for this one as it is an easy way to kill your score if you don’t verify as you go. I hope someone reads this and it does the same for them some day!

I have environment with MPLS, MP BGP with customer running ospf protocol.

I have CustomerA located in two locations and its vrf routing table is populated with all the routes. But still the end to end ping doesnot work

Any one has ideas

By TerryAnn Fitzgerald

I’ve noticed a recent rash of newspaper and magazine articles that tout the promises and potential of telemedicine.  The articles focus on patient benefits, particularly as populations around the globe age and chronic conditions increase.  They cite the advantages of in-home monitoring that allows patients to maintain their independence or minimize hospital stays.    The articles also refer to the opportunity to work with healthcare specialists around the globe or to access to medical resources from rural locations.

For healthcare organizations, telemedicine holds the promise of providing a better quality of patient care, allowing clinicians to monitor and intervene before issues become critical.  Other advantages include reductions in medical costs, freeing staff for more urgent patient care and providing a new source of revenue or unique service in an increasingly competitive global healthcare market.

But what are the challenges that healthcare organizations must address to reap the benefits of widespread adoption of telemedicine?  Gartner’s “Hype Cycle for Telemedicine 2009″  mentions several, including reimbursements, legal liability, new models of staffing and care coordination, EMR and CPR integration and lack of sufficient bandwidth or Internet connectivity in some areas.  Despite the issues, the same report states “there is a clear business need.”

HIMSS provides a nice summary of both the benefits and inhibitors in a Vantage Point report on Telemedicine.

While most telemedicine applications are still struggling for mainstream adoption, the demand will increase as restrictions ease and awareness grows. Research from Datamonitor, “2009 Trends to Watch: Healthcare Technology,” shows that 27% of the healthcare organizations surveyed consider telehealth a priority in the next six months.

It seems that now is the best time to start planning for telemedicine initiatives – while you are planning for and addressing the increased demands on your network infrastructure from other healthcare technologies such as EMRs.   By doing so, your healthcare IT organization will be positioned to deliver organizational agility, adaptability and superior value.

By its very nature, telemedicine often requires very large files to travel over long distances from remote locations to a healthcare facility, so there are several key items you’ll want to consider.

Image clarity:  Accurate diagnostics in telemedicine is dependent on image quality.   Tools that provide end-to-end network visibility and network traffic prioritization are an absolute must to assure the required quality of service and low-latency.   Delivery of digital images, voice and video between locations can be accelerated by network services such as MPLS, WAN optimization and application acceleration.

Patient privacy:  Telemedicine adds a layer of complexity to the challenge of securing data and maintaining patient privacy and regulatory compliance that can be addressed most effectively by a multi-layer strategy. For a more detailed discussion of this topic, visit 3Com’s blog on Secure Network Fabric.

Flexible IT foundation:  The Boy Scouts said it best – be prepared.  With the constant state of change in the healthcare environment, plan for a network infrastructure that can easily scale to rapidly adapt to support new initiatives.  Consider a network infrastructure that allows you to embed network services such as security, Voice over IP, WAN optimization and application acceleration, saving both time and money.

Is your healthcare organization actively pursuing telemedicine initiatives?  Are there other issues you’ve had to address for successful deployment?

If you have already implemented a telemedicine solution, what was your biggest challenge?

The Irish League of Credit Unions (ILCU) and Interfusion Networks today (Monday 19th October 2009) signed a deal to deploy a new, private and secure Wide Area Network communications infrastructure to the Credit Union Movement in Ireland.

The next-generation Multi Protocol Label Switching (MPLS) network will offer secure connectivity to credit unions, sub offices and 3rd party service providers throughout the Republic and Northern Ireland. The ILCUnet, requested by the Credit Unions and made possible with Interfusion Networks technology, provides the core backbone upon which services desired by Credit Unions of all sizes may be effectively and efficiently delivered. 

Earlier this year the ILCU commissioned independent agency Amárach Research to survey 1,200 adults throughout Ireland to gain insight into members’ and non-members’ views of current Credit Union services, and their willingness to use additional financial services if they were provided by Credit Unions.

Jimmy Johnstone, Vice-President of the ILCU and Chairperson of the National Technology Committee, said of the Amárach Research report, “The detail within the report clearly indicates that Credit Unions are pillars of the community, have members’ best interests at heart, and can be trusted. Member satisfaction with their credit union is extraordinarily high as Credit Unions have friendly staff, provide a good service, and are seen as helpful, safe, secure and trustworthy.  Members and non members alike would like to use credit unions for more of their financial needs as there is very strong interest in Insurance products, current accounts, debit cards, ATM’s, laser cards, pensions, receipt of government payments and online banking.”

Commenting on the ILCUnet agreement with Interfusion Networks, ILCU CEO Kieron Brennan stated: “Credit Unions will now have a common, secure, Credit Union owned communications platform which will serve as the foundation for credit unions to continue to work with their own IT Supplier to develop and offer many new services to their members.  With membership increasing every day, now is the time for us to take advantage of economies of scale, and leverage technology to offer the financial products and services members throughout the Credit Union Movement want.”

The ILCU represents 505 Credit Unions throughout the island of Ireland. Credit Unions in Ireland today support 2.9 million credit union members with savings approaching €11.9 billion.

“We are looking forward to building and managing ILCUnet across the 32 counties, and again this contract confirms Interfusion as the leading challenger in the Business markets to the traditional Telecoms operators”. Steve Mac Nicholas Managing Director of Interfusion Networks goes on to describe the company as “a specialist telecoms provider in the provision of MPLS based Wide Area Network solutions for the Business and Government markets using a range of access technologies”.

The company has previously been awarded Best Network Infrastructure in the ICT awards and also have been listed in the Deloitte Technology Fast 50 and the European Fast 500 in 2006, 2007, 2008 & 2009.

Done!

This exam is the hardest that i ever done!

TE is simple. Labs are tricky.

QoS is next.

Meeting hari senin kemarin ternyata membawa berkah yang luar biasa buat aq (alah,,hahha). Selain dapet kue2 yang maknyus, pengetahuan tentang karakteristik modul GBE ALU pun semakin terbuka. Untuk pengetesan BB PE IP MPLS yang sudah menghabiskan badget puluhan juta itu ternyata blm berhasil sodara2. Jalur transmisi yang dibuat via SDH ALU dengan kapasitas 1 G, ternyta belum tmbus.

Kami memakai card tipe ISA-ES16, dan untuk di aksesnya (yg bkalan di colokin ke router) adalah modul GETH-AGR. ISA-ES16 sendiri bisa mendelivere trafik sebesar 16 x STM 1 alias sekitar 2.5 G. GETH-AGR punya 4 port akses dan bisa mengeluarkan trafik sesuai cross conent yang dibuat, tergantung desainnya. Kombinasi2 yang bisa diterapkan adalah sebagai berikut:

1. Port 1 & 2 kapasitas 1 G dimana ini setara dgn 7 VC4 / STM-1 –> berarti 2 port dah ngabisin 14 VC4, so tinggal 2 VC4 lagi kan.. (sesuai kapasitas ISA-ES16 td). nah 2 VC4 itu bisa kita keluarin di port 3 & 4 dengan masing2 BW nya 100 Mbps (1 VC4)
2. Kombinasi yang laen sesuai kebutuhan, yang pasti prinsipnya ke -4 port tersebut cuma dijatah BW sebesar 16 VC4 ato 2.5 G. Apabila kita memaksakan mengkonfigure ke tiga port sebesar 1 G, maka port yg ke-3 tidak akan bisa mengeluarkan trafik 1 G, tp hanya 2 VC4 = 288 Mbps

Kemudian untuk pembuatan cross connect nya juga membutuhkan teknik tambahan, tidak seperti jika kita mendeliver service TDM. Setelah kita selesai buat XC di sisi SDH nya, kita juga harus membuat crosconnect di card GBE nya. InsyA laen kali klo ad waktu aq share ya caranya gmn.

Okay…moga bermanfaat ya…caooo…

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

I have been  trying to master and speed up my approach to the MPLS VPN Section which I did not do my 1st time around – here is an abridged tasklist based on the relevant IOS Configuration Guides providing me with a roadmap to navigate through this crucial section. HTH.

Stephen Bowes – How to Configure MPLS Layer 3 VPNs:

Step 1: Configuring the Core Network (required)

            1a. Assessing the Needs of MPLS VPN Customers (not required in CCIE Lab as details provided)

• Identify the size of the network.
• Identify the routing protocols.
• Determine if you need MPLS High Availability support.
• Determine if you need BGP load sharing and redundant paths.

            1b. Configuring Routing Protocols in the Core (required – For SP Lab this will be OSPF or ISIS for scalability reasons)

            Configuring OSPF in the core:

• enable
• configure terminal
• router ospf process-id
• Router(config-router)# network ip-address wildcard-mask area area-id

            Configuring ISIS in the core:

• enable
• configure terminal
• router isis [area-tag]
• net network-entity-title
• end

            Enabling IS-IS as an IP Routing Protocol on the Interface (required)

• enable
• configure terminal
• interface type number
• ip address ip-address mask [secondary]
• ip router isis [area-tag]
• end

                        Monitoring IS-IS (optional)

                        Not listed here – various show commands

                        Shutting Down IS-IS to Make Changes to Your IS-IS Network (optional)

                        Not listed here

            1c. Configuring MPLS in the Core (required)

• enable
• configure terminal
• mpls ip
• mpls label protocol {ldp | tdp | both}
• interface type number
• mpls ip
• exit
• exit
• show mpls interfaces [interface] [detail]
• show mpls ldp discovery [all | vrf vpn-name] [detail]
• show mpls ldp neighbor [[vrf vpn-name] [address | interface] [detail] | [all]]

            LDP used as the example here – obviously could be TDP, etc.

            1d. Determining if CEF Is Enabled in the Core (required)

• sh run
• sh ip cef

            1e. Configuring Multiprotocol BGP on the PE Routers and Route Reflectors (required)

• enable
• configure terminal
• router bgp as-number
• no bgp default ipv4-unicast
• neighbor {ip-address | peer-group-name} remote-as as-number
• neighbor {ip-address | peer-group-name} activate
• address-family vpnv4 [unicast]
• neighbor {ip-address | peer-group-name} send-community extended
• neighbor {ip-address | peer-group-name} activate
• end

Step 2: Connecting the MPLS VPN Customers (required)

            2a. Defining VRFs on the PE Routers to Enable Customer Connectivity (required)

• enable
• configure terminal
• ip vrf vrf-name
• rd route-distinguisher
• route-target {import | export | both} route-target-ext-community
• import map route-map
• exit

            2b. Configuring VRF Interfaces on PE Routers for Each VPN Customer (required)

• enable
• configure terminal
• interface type number
• ip vrf forwarding vrf-name
• end

            2c. Configuring Routing Protocols Between the PE and CE Routers (required)

We can run BGP, RipV2, OSPF, Static Routes or EIGRP as the PE-CE Routing Protocol – here are the configuration tasks for all.

            Configuring BGP as the Routing Protocol Between the PE and CE Routers

• enable
• configure terminal
• router bgp as-number
• address-family ipv4 [multicast | unicast | vrf vrf-name]
• neighbor {ip-address | peer-group-name} remote-as as-number
• neighbor {ip-address | peer-group-name} activate
• exit-address-family
• end

            Configuring RIPv2 as the Routing Protocol Between the PE and CE Routers

• enable
• configure terminal
• router rip
• version {1 | 2}
• address-family ipv4 [multicast | unicast | vrf vrf-name]
• network ip-address
• redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]
• exit-address-family
• end

            Configuring Static Routes Between the PE and CE Routers

• enable
• configure terminal
• ip route vrf vrf-name
• address-family ipv4 [multicast | unicast | vrf vrf-name]
• redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]
• redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]
• exit-address-family
• end

            Configuring OSPF as the Routing Protocol Between the PE and CE Routers

• enable
• configure terminal
• router ospf process-id [vrf vpn-name]
• network ip-address wildcard-mask area area-id
• address-family ipv4 [multicast | unicast | vrf vrf-name]
• redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map map-tag] [subnets]
• exit-address-family
• end

            Configuring EIGRP as the Routing Protocol Between the PE and CE Routers

• enable
• configure terminal
• router bgp as-number
• no synchronization
• neighbor ip-address remote-as as-number
• neighbor ip-address update-source loopback interface-number
• address-family vpnv4
• neighbor ip-address activate
• neighbor ip-address send-community extended
• exit-address-family
• address-family ipv4 vrf vrf-name
• redistribute eigrp as-number [metric metric-value][route-map map-name]
• no synchronization
• exit-address-family
• end

            Configuring EIGRP Redistribution in the MPLS VPN

• enable
• configure terminal
• router eigrp as-number
• address-family ipv4 [multicast | unicast | vrf vrf-name]
• network ip-address wildcard-mask
• redistribute bgp {as-number} [metric bandwidth delay reliability load mtu] [route-map map-name]
• autonomous-system as-number
• exit-address-family
• end

Step 3: Verifying Connectivity between MPLS VPN Sites (optional)

            3a. Verifying the VPN Configuration

• show ip vrf

            3b. Verifying IP Connectivity from CE Router to CE Router Across the MPLS Core

• enable
• ping [protocol] {host-name | system-address}
• trace [protocol] [destination]
• show ip route [ip-address [mask] [longer-prefixes]] | [protocol [process-id]] | [list access-list-number access list number
• disable

            3c. Verifying that the Local and Remote CE Routers are in the Routing Table

• enable
• show ip route vrf vrf-name [prefix]
• show ip cef vrf vrf-name [ip-prefix]
• exit

References:

Cisco IOS IP Routing: ISIS Configuration Guide, Release 12.4

Cisco IOS IP Routing: OSPF Configuration Guide, Release 12.4

Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4

When a person gets extremely angry, they are said to be “seeing red.” While etymologists, sociologists and conspiracy theorists ascribe the expression to your blood rising when you get agitated or even to the anger a bull supposedly experiences when it sees a toreador’s red cape, I have my own thoughts on the matter. I think it means the anger, stress, volatility and explosive vocabulary most of us experience when we see the endless red sea of brake lights as cars idle in traffic in front of us, impeding our ability to get where we’re going.

Frustrating, isn’t it? Your blood is probably rising right now, just thinking about it. Yet most of us subject ourselves to seeing red at least twice a day—our commute to work and our commute back home. This level of repeat, sustained anger is not good for you. It makes your blood pressure go up. It makes the veins in your forehead pop. It makes you look ridiculous to the people in the car next to you as they see you raise your fist in the air and cry out loud (or swear a blue streak, whatever works for you). And it makes you spend seemingly more time on the road than at work or at home. Seeing red sucks.

Here’s a solution to your crimson crisis—stay home. I know, you have to go to work, make a living, earn money to pay for your house and your kids’ braces, but you can still get all that done…from home. TelePacific’s 1Net IP VPN gives you remote access to your office network and files, allowing you to work from the luxury of your home, where the only idle car is the one parked in your garage. Throw in Conference Central and you don’t even have to leave the house to meet with clients or coworkers. It makes it simple and easy to reduce your levels of stress and anger. You may even be more productive, without people wandering over to your office to chat.

And those are good things. Really good things. Your boss will love you even more. Plus, as an added value, you’re not adding another car to traffic jams or smog to the environment. All things that will help you see blue…clear blue skies. Calm blue seas. Because blue is a calming color—and that’s good too.

Yesterday we had a customer network migration from IPsec VPN to MPLS. Customer’s headquarter network wanted to be the point of internet sharing so that all branch offices use that point for internet browsing. OSPF was chosen to be the dynamic routing protocol between CE and PE, as ASA is deaf to BGP. We configured everything on CE side and contacted customer’s service provider to check their configuration, everything was fine, but the default route. We had injected a default route at HQ but the branch offices were unable to get that particular 0.0.0.0/0 route through MPLS.

The service provider (DU) told me that OSPF is not able to inject default route from one CE to another CE… and you have to migrate to BGP! what!? It’s not true… I’ve sent them a sample configuration to set on their PE LSRs, now it’s time to explain the problem in detail:

1. Customer 1 is injecting default-information via OSPF by “default-information originate” command to the service provider’s PE router.
2. Service provider receives LSA type 5 and should “redistribute ospf x vrf Customer1 match external” into MP-BGP to other PE.
3. BGP will not redistribute default-information unless we configure “default-information originate” under bgp address-family ipv4 vrf Customer1 (Tricky)
4. The other PE receives 0.0.0.0/0 via BGP from the first PE and should redistribute it to OSPF but it won’t unless we configure “default-information originate” under OSPF process.

In our example R7 is connected to internet using a static route. R7 injects internet to PE (R3) by “redistribute static subnets”. R3 redistribute that to BGP by “default-information originate” to the other PE (R2). Now R2 has 0.0.0.0/0 in the BGP and should redistribute it into OSPF and use “default-information originate” to send it to its own connected CE.

So I sent the following diagram to the provider for their reference:

Example (based on the first topology):

R7 (CE-Internet):
router ospf 1
redistribute static subnets
network 172.16.37.7 0.0.0.0 area 0
 default-information originate
!
ip route 0.0.0.0 0.0.0.0 172.16.69.68
!

R3 (PE):
router ospf 147 vrf VPN1
redistribute bgp 666 subnets
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 666
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 666
neighbor 2.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
exit-address-family
!
address-family ipv4 vrf VPN1
  redistribute ospf 147 vrf VPN1 match internal external 1 external 2
  default-information originate
  no synchronization
exit-address-family
!

R2 (PE):

router ospf 147 vrf VPN1
redistribute bgp 666 subnets
network 0.0.0.0 255.255.255.255 area 0
 default-information originate
!
router bgp 666
no synchronization
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 666
neighbor 3.3.3.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family ipv4 vrf VPN1
  redistribute ospf 147 vrf VPN1 match internal external 1 external 2
  no synchronization
exit-address-family

Verification:

R3#show ip ospf 147 database

            OSPF Router with ID (172.16.37.3) (Process ID 147)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq# 
172.16.37.3     172.16.37.3     1047        0×8000
172.16.37.7     172.16.37.7     1021        0×8000

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq# 
172.16.37.3     172.16.37.3     1047        0×8000

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq# 
172.16.24.0     172.16.37.3     1047        0×8000

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq# 
0.0.0.0         172.16.37.7     482         0×8000
47.47.47.4      172.16.37.3     1047        0×8000
47.47.47.7      172.16.37.7     1021        0×8000

R3#show ip route vrf VPN1

Routing Table: VPN1
Gateway of last resort is 172.16.37.7 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.37.0 is directly connected, Ethernet0/2
B       172.16.24.0 [200/0] via 2.2.2.2, 01:27:35
     47.0.0.0/32 is subnetted, 2 subnets
O E2    47.47.47.7 [110/20] via 172.16.37.7, 01:24:49, Ethernet0/2
B       47.47.47.4 [200/20] via 2.2.2.2, 01:27:35
O*E2 0.0.0.0/0 [110/1] via 172.16.37.7, 00:09:39, Ethernet0/2

R2#show ip bgp vpnv4 vrf VPN1
BGP table version is 41, local router ID is 2.2.2.2
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 172.16.12.2:1 (default for vrf VPN1)
*>i0.0.0.0          3.3.3.3                  1    100      0 ?
*> 47.47.47.4/32    172.16.24.4             20         32768 ?
*>i47.47.47.7/32    3.3.3.3                 20    100      0 ?
*> 172.16.24.0/24   0.0.0.0                  0         32768 ?
*>i172.16.37.0/24   3.3.3.3                  0    100      0 ?

R4#show ip route
Gateway of last resort is 172.16.24.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 2 subnets
O IA    172.16.37.0 [110/11] via 172.16.24.2, 03:32:41, Ethernet0/0
C       172.16.24.0 is directly connected, Ethernet0/0
     47.0.0.0/32 is subnetted, 2 subnets
O E2    47.47.47.7 [110/20] via 172.16.24.2, 01:27:21, Ethernet0/0
C       47.47.47.4 is directly connected, Loopback0
O*E2 0.0.0.0/0 [110/1] via 172.16.24.2, 00:12:15, Ethernet0/0

Note that branch offices still have their own internet as backup, so whenever MPLS goes down, they can use their own internet with IPsec capability to connect to the headquarter automatically, if I would use “default-information originate always” then CE would always advertise default route regardless of it’s existence in the routing table but in our case we have IP SLA monitored static route to the internet, and whenever it goes down OSPF will take back default-route advertisement (default-information originate – without always!) and branch office will use the higher administrative distance static route to its own internet (floating route). Then it will use IPsec to HQ as the crypto-map on internet interface will be triggered.

With HSPA, EVDO maturing, WiMax getting deployed and LTE getting ready to buzz around, it is soon changing the way mobile phones will access the networks. The bandwidth hungry new services, applications and the non-stop touch clicks on your smart handhelds are eventually going to obsolete these mature 3G networks. Whereas, the 4G access networks are definitely envisioned to control this ever-increasing wireless broadband traffic but what bout the evolution of backhaul?? Is it ready? or is it going to be a major bottleneck analogous to the traffic jams seen if only one lane was operating out of a four lane expressway.

So, let’s have a closer look on how the mobile backhaul network is currently positioned.

The trend below depicts the exponential growth in asynchronous data demand for next 5 years.

Mobile Traffic Projections for the next 5 years

Over the next few years, “user experience” will still continue to rely on 3G (and in some regions on 2G) technology.But for the mobile operator, LTE/WiMax is already part of the game plan. Operators have to learn the technology, and its impact on their networks, applications and service offering. Though, service providers are seeking revenue and profit growth through new differentiated packet-based services. Many of these services, such as mobile Internet and mobile TV, require high bandwidth—and the current backhaul infrastructure is not optimized for handling such traffic. Hence, providers have to add backhaul capacity while keeping operational costs under control, a situation that is forcing carriers to migrate their access and core networks to the new 3G and 4G infrastructure.

There are three main transport technologies in the backhaul arena – fiber, copper and wireless point-to-point microwave.

The costs of backhaul form a significant part of service providers’ revenue accounting for three quarters of mobile transport costs and 25-30% of total operating expenses. The 2G infrastructure carried voice traffic through switched TDM (T1/E1 or SDH/SONET) or ATM. As with 3G/4G services, already  the bandwidth requirements have shot exponentially and to transport voice and data efficiently has been the need of the hour.

Basic requirements for a 4G Backhaul network:

1. Capacity: A single tail site should be scalable to 100Mbps+ capacities to avoid bottlenecks

2. Latency: A solution that supports 10msec or less end-to-end latency

3. All IP: Support IP traffic from head to tail.

Current migrating strategy is transporting Ethernet packets over point-to-point Microwave. Over 50% of all mobile backhaul deployments worldwide (and nearly 70% outside the U.S.A.), point-to-point microwave systems offer simple and cost efficient backhauling for voice and high-speed data services. That’s because point-to-point microwave supports higher data rates than traditional copper T1/E1 lines, it delivers between 25% and 60% more bits compared with similar TDM based systems, and easily overcomes the high cost and limited availability associated with fiber. Thus, operators can connect the TDM ports today, and gradually shift traffic to the Ethernet ports in the future. This shift can be done from remote, so no additional CAPEX or OPEX are needed. The industry has already established that the end game of next generation mobile backhaul networks is all-IP/Ethernet. Ethernet is not only more scalable, it also offers huge cost savings across the entire network value chain.

Ethernet cost savings per 1 Million subscribers

Also migrating to high capacity and lower latency Ethernet/All IP network, the systems should also support QoS aware Adaptive Coding and Modulation and Statistical Multiplexing. The former helps optimizing network for spectrum efficiency, increasing the radio capacity and  thus reducing cost/bit and latter in optimizing traffic management over the network reducing congestion and improving efficiency. An IP over Ethernet infrastructure has the advantage of the bandwidth growth curve of Ethernet moving from 10 Megabits per second (Mbps) to 10 Gigabits per second (Gbps) today and 100 Gbps in future. This coupled with the decreasing cost of Ethernet ports provides growth opportunities with increasing economies of scale.

Ethernet microwave Vs. TDM microwave equipment cost comparison

Thus, of the three backhaul technology options operators can choose from, wireless point-to-point microwave can deliver the best cost-performance features, bringing faster ROI and driving forward the proliferation of advanced mobile services in the LTE/WiMax era. But in the longer run a hybrid  solution of microwave, optical or IP/MPLS core might be seen as a balanced solution that might reduce the OPEX with improved scalability, higher bandwidth, lower latency and better efficiency. So operators pull up the socks and get ready for the great migration.Also, a point to note with CISCO’s recent acquisition of Starnet Networks which makes it now one of the most dominant player in mobile backhaul solutions market.

- Neil Shah