<BODY><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/platform.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar/18755935?origin\x3dhttp://dmnvinod.blogspot.com', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>

Google IPv6 Conference 2008: IPv6 on Windows

Wednesday, November 25, 2009

Labels: ,

Virtualization 101

Thursday, October 22, 2009

Labels: ,

The World's Densest MMR (Internet Topology)

Wednesday, July 29, 2009

In the bowels of the world's most densely populated Meet-Me room -- a room where over 260 ISPs connect their networks to each other -- a phalanx of cabling spills out of its containers and silently pumps the world's information to your computer screen. One tends to think of the internet as a redundant system of remote carriers peppered throughout the world, but in order for the net to function the carriers have to physically connect somewhere. For the Pacific Rim, the main connection point is the One Wilshire building in downtown Los Angeles.

If this facility went down, most of California and parts of the rest of the world would not be able to connect to the internet. Tour one of the web's largest nerve centers, hidden in an otherwise nondescript office building.

Despite being the main hub of the internet for the entire Pacific Rim, One Wilshire looks like just another office tower in downtown Los Angeles. With the exception of the four floors devoted to law offices, the building is filled with servers and high-tech offices.



On the fourth floor of One Wilshire, hundreds of major network providers -- including AT&T, Sprint and Verizon -- all connect to one another and share traffic amongst their various worldwide networks. Networks have been connecting to each other in this room for more than 20 years.



A relatively new cable tray runs below the Meet-Me room ceiling. Cabling stewardship is a constant process at One Wilshire. Every time a connection is no longer needed, the connectors are cut, and the wire is pulled and recycled.


A network technician prunes cables from a tray in the never-ending quest to manage the Meet-Me room cross-connects. Every time a new carrier moves in to the room, it will invariably need to connect to many of the 260-plus other carriers. Ideally this is done through One Wilshire’s multiplexing system, thus limiting the amount of cabling.


The entire fourth-floor ceiling is densely packed with decades of cabling. Most of the cable trays are so full that the wiring spills out at every intersection.



This is what the Meet-Me room would look like without all the cables. Trays sit empty, waiting to be filled with copper and glass-fiber connections between various servers and switches.



This closet is filled with thousands of cross-connections. They allow the 260-plus network providers in the Meet-Me room to "peer" their networks. Without peering you would only be able to connect to websites hosted by your own service provider.



The copper-based connections within the building come here to get piped into fiber optics to run long distances. This hub allows all the carriers to cross-connect to different floors at One Wilshire and to other Meet-Me rooms in the United States.

Labels:

From Sand to CPU - How AMD does it ?

Wednesday, July 22, 2009

Labels:

From Sand to CPU - How Intel Makes I7

i7





Your CPU Came From Sand


Sand. Made up of 25 percent silicon, is, after oxygen, the second most abundant chemical element that's in the earth's crust.
Sand, especially quartz, has high percentages of silicon in the form of silicon dioxide (SiO2) and is the base ingredient for semiconductor manufacturing.


Purification and Growing

After procuring raw sand and separating the silicon, the excess material is disposed of and the silicon is purified in multiple steps to finally reach semiconductor manufacturing quality which is called electronic grade silicon. The resulting purity is so great that electronic grade silicon may only have one alien atom for every one billion silicon atoms. After the purification process, the silicon enters the melting phase. In this picture you can see how one big crystal is grown from the purified silicon melt. The resulting mono-crystal is called an ingot.

The big Ingot

A mono-crystal ingot is produced from electronic grade silicon. One ingot weighs approximately 100 kilograms (or 220 pounds) and has a silicon purity of 99.9999 percent.


Ingot Slicing

The ingot is then moved onto the slicing phase where individual silicon discs, called wafers, are sliced thin. Some ingots can stand higher than five feet. Several different diameters of ingots exist depending on the required wafer size. Today, CPUs are commonly made on 300 mm wafers.

Wafer Polishing

Once cut, the wafers are polished until they have flawless, mirror-smooth surfaces. Intel doesn't produce its own ingots and wafers, and instead purchases manufacturing-ready wafers from third-party companies. Intel’s advanced 45 nm High-K/Metal Gate process uses wafers with a diameter of 300 mm (or 12-inches). When Intel first began making chips, it printed circuits on 50 mm (2-inches) wafers. These days, Intel uses 300 mm wafers, resulting in decreased costs per chip.

Photo Resist Application

The blue liquid, depicted above, is a photo resist finish similar to those used in film for photography. The wafer spins during this step to allow an evenly-distributed coating that's smooth and also very thin.

UV Light Exposure

At this stage, the photo-resistant finish is exposed to ultra violet (UV) light. The chemical reaction triggered by the UV light is similar to what happens to film material in a camera the moment you press the shutter button.

Areas of the resist on the wafer that have been exposed to UV light will become soluble. The exposure is done using masks that act like stencils. When used with UV light, masks create the various circuit patterns. The building of a CPU essentially repeats this process over and over until multiple layers are stacked on top of each other.

A lens (middle) reduces the mask's image to a small focal point. The resulting "print" on the wafer is typically four times smaller, linearly, than the mask's pattern.



More Exposing

In the picture we have a representation of what a single transistor would appear like if we could see it with the naked eye. A transistor acts as a switch, controlling the flow of electrical current in a computer chip. Intel researchers have developed transistors so small that they claim roughly 30 million of them could fit on the head of a pin.


Photo Resist Washing

After being exposed to UV light, the exposed blue photo resist areas are completely dissolved by a solvent. This reveals a pattern of photo resist made by the mask. The beginnings of transistors, interconnects, and other electrical contacts begin to grow from this point.


Etching

The photo resist layer protects wafer material that should not be etched away. Areas that were exposed will be etched away with chemicals.


Photo Resist Removal

After the etching, the photo resist is removed and the desired shape becomes visible.


Reapplying More Photo Resist

More photo resist (blue) is applied and then re-exposed to UV light. Exposed photo resist is then washed off again before the next step, which is called ion doping. This is the step where ion particles are exposed to the wafer, allowing the silicon to change its chemical properties in a way that allows the CPU to control the flow of electricity.


Ion Doping

Through a process called ion implantation (one form of a process called doping) the exposed areas of the silicon wafer are bombarded with ions. Ions are implanted in the silicon wafer to alter the way silicon in these areas conduct electricity. Ions are propelled onto the surface of the wafer at very high velocities. An electrical field accelerates the ions to a speed of over 300,000 km/hour (roughly 185,000 mph)

More Photo Resist Removal

After the ion implantation, the photo resist will be removed and the material that should have been doped (green) now has alien atoms implanted.

A Transistor

This transistor is close to being finished. Three holes have been etched into the insulation layer (magenta color) above the transistor. These three holes will be filled with copper, which will make up the connections to other transistors.

Electroplating The Wafer

The wafers are put into a copper sulphate solution at this stage. Copper ions are deposited onto the transistor through a process called electroplating. The copper ions travel from the positive terminal (anode) to the negative terminal (cathode) which is represented by the wafer.


Ion Settling

The copper ions settle as a thin layer on the wafer surface.

Polishing Excess Material

The excess material is polished off leaving a very thin layer of copper.


Layering

Multiple metal layers are created to interconnects (think wires) in between the various transistors. How these connections have to be “wired” is determined by the architecture and design teams that develop the functionality of the respective processor (for example, Intel’s Core i7 processor). While computer chips look extremely flat, they may actually have over 20 layers to form complex circuitry. If you look at a magnified view of a chip, you will see an intricate network of circuit lines and transistors that look like a futuristic, multi-layered highway system.


Wafer Sort Test

This fraction of a ready wafer is being put through a first functionality test. In this stage test patterns are fed into every single chip and the response from the chip monitored and compared to "the right answer."

Wafer Slicing

After tests determine that the wafer has a good yield of functioning processor units, the wafer is cut into pieces (called dies).


The Good, The Bad, The Ugly

The dies that responded with the right answer to the test pattern will be put forward for the next step (packaging). Bad dies are discarded. Several years ago, Intel made key chains out of bad CPU dies.

Individual Die

This is an individual die, which has been cut out in the previous step (slicing). The die shown here is a die of an Intel Core i7 processor.

CPU Packaging

The substrate, the die, and the heatspreader are put together to form a completed processor. The green substrate builds the electrical and mechanical interface for the processor to interact with the rest of the PC system. The silver heatspreader is a thermal interface where a cooling solution will be applied. This will keep the processor cool during operation.


A Finished CPU

A microprocessor is the most complex manufactured product on earth. In fact, it takes hundreds of steps and only the most important ones have been visualized in this picture story.


CPU Testing

During this final test the processors will be tested for their key characteristics (among the tested characteristics are power dissipation and maximum frequency).

CPU Binning

Based on the test result of class testing processors with the same capabilities are put into the same transporting trays. This process is called binning. Binning determines the maximum operating frequency of a processor, and batches are divided and sold according to stable specifications.


Off To The Stores

The manufactured and tested processors either go to system manufacturers in trays or into retail stores in a box.


Source : Intel Chip Making
PDF Version :



Thanks You,
VINOD M

Labels:

Encrypting Gmail

Wednesday, June 17, 2009
Automatically encrypt Gmail connection

Gmail now can be set to encrypt communications between a browser and Google's servers by default, an option that makes the e-mail service harder to snoop on but also potentially slower.

The encryption comes through use of HTTPS, a secure version of the HTTP protocol that governs how Web browsers fetch information from servers.
It's not simple to snoop on somebody else's network traffic, but it can be done when the communications aren't encrypted.
HTTPS encrypts communications only between the browser and Gmail's servers.
It's not like PGP (nee Pretty Good Privacy) or GPG (GNU Privacy Guard) software that encrypts e-mail all the way from source to destination.
Note : The Gmail login process is always encrypted.


Open Gmail > Settings > Browser connection > Always use https > save changes

Labels:

Apple iPhone OS 3.0 - over 100 new features

Wednesday, March 18, 2009

System-wide Cut, Copy and Paste feature
Stereo A2DP Bluetooth streaming is on (not available to iPhone 2G)
System-wide landscape keyboard
A system-wide search Spotlight is added now including Mail, Calendar, Notes, iPod and web
There's now MMS support (not available to iPhone 2G)
Turn-by-turn navigation (but only with third-party maps)
You can forward and delete individual messages
Notes can now be synced with iTunes
WiFi auto-login for hotspots
Bluetooth peer-to-peer connection with file exchange and remote control (over Bonjour only)
Safari gets password login manager
Support for YouTube accounts and YouTube subscriptions
New action button in Photos lets you choose multiple pictures to attach to a mail message
There are Voice Memos, which can be edited, cropped and shared using email or MMS
Calendar gets Exchange support and will be able to sync with Google and Yahoo calendar services
Stocks app will be getting news stories and stock details
iPod gets shake-to-shuffle function
Anti-phishing tool in Mobile Safari
Increased number of supported languages
Parental Controls are extended to movies, TV shows and App Store content
Detailed Calls Log with call durations
iTunes store account creation
Proxy support
Live video and audio streaming
Tethering is now supported (but available optionally)
Voice recording
Camera displays last taken picture in lower left corner - just as in existing Snapture app












Source

-VINOD M

Labels:

Microsoft Future Vision Montage

Friday, March 06, 2009
<a href="http://video.msn.com/?mkt=en-GB&amp;playlist=videoByUuids:uuids:a517b260-bb6b-48b9-87ac-8e2743a28ec5&amp;showPlaylist=true&amp;from=shared" target="_new" title="Future Vision Montage">Video: Future Vision Montage</a>


For More Info Visit : http://www.istartedsomething.com/20090228/microsoft-office-labs-vision-2019-video/

-VINOD M

Labels:

Preferring MPLS VPN BGP Path with IGP Backup

Monday, March 02, 2009

Preferring MPLS VPN BGP Path with IGP Backup

Summary

Over the last few years MPLS VPN services have gained popularity as an alternative network connectivity transport option over legacy TDM networks. One of the most popular challenges with the MPLS VPN design is the Layer3 routing interaction between the customer network and the service provider routing. A common scenario is when there is a primary BGP path over the MPLS VPN network and a redundant routing path over a non MPLS VPN network. This is exposed in many networks that have an eBGP peering session with the MPLS VPN provider and routes are learned to remote locations but also have a backup path to those same locations over a redundant IGP path. Typically the IGP path learns the routes via a dynamic routing protocol such as EIGRP or OSPF. This TAC Tip describes how to configure the routing such that the preferred path is always selected in both the primary path failure condition as well as the reroute on primary path recovery. Typically with the default configuration the failover works to the backup IGP path. However, the problem comes when the primary recovers.

Sample Network

When an IGP (in this example OSPF) route is redistributed in to BGP it is considered locally generated by BGP and gets assigned a weight of 32768. By default, all routes received from a BGP peer are assigned a local weight of 0. When doing BGP path comparison weight is the first attribute compared. Therefore, if the same prefix must be compared, the locally originated prefix with the higher weight will be installed in the routing table based on the BGP best path selection process. Let's first walk through an example of how the problem surfaces.

Take this simple network example: http://supportwiki.cisco.com/ViewWiki/images/b/ba/Techtip_OSPF_2.jpg


R1 is the end customer (CPE) router that has two parallel paths to reach the remote 192.168.1.0/24 subnet. One path is an OSPF learned path and the other is an eBGP learned route from the MPLS PE router over the MPLS VPN network.

When the MPLS VPN network is up the eBGP route is selected as the best path based on the higher administrative distance (20 for eBGP and 110 for OSPF).

R1#show ip bgp 192.168.1.0 255.255.255.0

BGP routing table entry for 192.168.1.0/24, version 1562

Paths: (1 available, best #1, table default)

Flag: 0x820

Not advertised to any peer

65000

172.16.56.6 from 172.16.56.6 (192.168.8.1)

Origin IGP, metric 0, localpref 100, valid, external, best

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "bgp 65001", distance 20, metric 0

Tag 65000, type external

Last update from 172.16.56.6 00:08:14 ago

Routing Descriptor Blocks:

* 172.16.56.6, from 172.16.56.6, 00:08:14 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 65000

The OSPF learned route to 192.168.1.0/24 is there as a candidate path in the OSPF database.

R1#show ip ospf data router 3.3.3.3

OSPF Router with ID (5.5.5.5) (Process ID 1)

Router Link States (Area 0)

LS age: 225

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 3.3.3.3

Advertising Router: 3.3.3.3

LS Seq Number: 8000138E

Checksum: 0x3AF3

Length: 48

Number of Links: 2

Link connected to: a Transit Network

(Link ID) Designated Router address: 172.16.35.5

(Link Data) Router Interface address: 172.16.35.3

Number of MTID metrics: 0

TOS 0 Metrics: 10

Link connected to: a Stub Network

(Link ID) Network/subnet number: 192.168.1.0

(Link Data) Network Mask: 255.255.255.0

Number of MTID metrics: 0

TOS 0 Metrics: 1


Now assume the link to the MPLS VPN network fails and we lose the eBGP route. Under this condition the OSPF backup route will be installed in the routing table. Here is the routing table debug showing the backup OSPF route going in the routing table.

RT: del 192.168.1.0 via 172.16.56.6, bgp metric [20/0]

RT: delete network route to 192.168.1.0/24

RT: updating ospf 192.168.1.0/24 (0x0) via 172.16.35.3 Et1/0

RT: add 192.168.1.0/24 via 172.16.35.3, ospf metric [110/11]

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "ospf 1", distance 110, metric 11, type intra area

Redistributing via bgp 65001

Advertised by bgp 65001 match internal external 1 & 2

Last update from 172.16.35.3 on Ethernet1/0, 00:00:09 ago

Routing Descriptor Blocks:

* 172.16.35.3, from 3.3.3.3, 00:00:09 ago, via Ethernet1/0

Route metric is 11, traffic share count is 1

At this stage the routing has reconverged to the IGP backup path and everything is ok. However, notice that the output above shows the route is being redistributed in to BGP. This is because the router is doing OSPF to BGP redistribution to get the local OSPF learned routes in to BGP in order to be advertised over the MPLS VPN network.

Here is the entry in the BGP table showing it is now locally sourced with a weight of 32768.

R1#show ip bgp 192.168.1.0 255.255.255.0

BGP routing table entry for 192.168.1.0/24, version 1564

Paths: (1 available, best #1, table default)

Flag: 0x820

Not advertised to any peer

Local

172.16.35.3 from 0.0.0.0 (5.5.5.5)

Origin incomplete, metric 11, localpref 100, weight 32768, valid, sourced, best

Now let's say that the primary link to the MPLS VPN router comes back up and the eBGP session recovers such that we learn the 192.168.1.0/24 network over the eBGP session again.

BGP(0): 172.16.56.6 rcvd UPDATE w/ attr: nexthop 172.16.56.6, origin i, metric 0, path 65000

BGP(0): 172.16.56.6 rcvd 192.168.1.0/24

R1#show ip bgp 192.168.1.0 255.255.255.0

BGP routing table entry for 192.168.1.0/24, version 1564

Paths: (2 available, best #2, table default)

Flag: 0x820

Advertised to update-groups:

1

65000

172.16.56.6 from 172.16.56.6 (192.168.8.1)

Origin IGP, metric 0, localpref 100, valid, external

Local

172.16.35.3 from 0.0.0.0 (5.5.5.5)

Origin incomplete, metric 11, localpref 100, weight 32768, valid, sourced, best

Even though the AD of the eBGP path (20) is lower than OSPF path (110), we do not install the eBGP learned route into the routing table. Since this prefix is in the routing table via OSPF and is being redistributed into BGP, the BGP table will have both paths and must use the Best Path Selection Algorithm. Routes redistributed into BGP are considered locally originated and get a default weight of 32768. The BGP learned prefix is assigned a weight of 0 by default. Since weight is the first BGP attribute that we compare on Cisco routers, the route with the higher weight is considered the best.

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "ospf 1", distance 110, metric 11, type intra area

Redistributing via bgp 65001

Advertised by bgp 65001 match internal external 1 & 2

Last update from 172.16.35.3 on Ethernet1/0, 00:03:05 ago

Routing Descriptor Blocks:

* 172.16.35.3, from 3.3.3.3, 00:03:05 ago, via Ethernet1/0

Route metric is 11, traffic share count is 1

Now the problem is that, even though the BGP link is back up and we are learning prefixes, traffic is still routing over the backup path via OSPF. To resolve this, we need to force the eBGP path to be preferred.

Resolution

One common way to resolve this issue is to set the weight on routes learned from the eBGP peer higher than 32768. When the paths are compared by BGP, the path with the highest weight will be preferred and installed in the routing table.

router bgp 65001

bgp log-neighbor-changes

neighbor 172.16.56.6 remote-as 65000

!

address-family ipv4

no synchronization

redistribute ospf 1 match internal external 1 external 2

neighbor 172.16.56.6 activate

neighbor 172.16.56.6 weight 32769

no auto-summary

exit-address-family

To update the weight on the received update, we must force the peer to send the update again so that we can apply the change inbound.

R1#clear ip bgp 172.16.56.6 soft in

*Feb 10 00:32:01.279: BGP(0): 172.16.56.6 rcvd UPDATE w/ attr: nexthop 172.16.56.6, origin i, metric 0, path 65000

*Feb 10 00:32:01.279: BGP(0): 172.16.56.6 rcvd 192.168.1.0/24

*Feb 10 00:32:01.291: RT: closer admin distance for 192.168.1.0, flushing 1 routes

*Feb 10 00:32:01.291: RT: add 192.168.1.0/24 via 172.16.56.6, bgp metric [20/0]

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "bgp 65001", distance 20, metric 0

Tag 65000, type external

Last update from 172.16.56.6 00:01:06 ago

Routing Descriptor Blocks:

* 172.16.56.6, from 172.16.56.6, 00:01:06 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 65000

R1#show ip bgp 192.168.1.0

BGP routing table entry for 192.168.1.0/24, version 1565

Paths: (1 available, best #1, table default)

Flag: 0x820

Not advertised to any peer

65000

172.16.56.6 from 172.16.56.6 (192.168.8.1)

Origin IGP, metric 0, localpref 100, weight 32769, valid, external, best

To demonstrate how this works, let's assume that the BGP route has been lost and the OSPF route is installed in the routing table.

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "ospf 1", distance 110, metric 11, type intra area

Redistributing via bgp 65001

Advertised by bgp 65001 match internal external 1 & 2

Last update from 172.16.35.3 on Ethernet1/0, 00:00:08 ago

Routing Descriptor Blocks:

* 172.16.35.3, from 3.3.3.3, 00:00:08 ago, via Ethernet1/0

Route metric is 11, traffic share count is 1

R1#show ip bgp 192.168.1.0

BGP routing table entry for 192.168.1.0/24, version 1567

Paths: (1 available, best #1, table default)

Flag: 0x820

Not advertised to any peer

Local

172.16.35.3 from 0.0.0.0 (5.5.5.5)

Origin incomplete, metric 11, localpref 100, weight 32768, valid, sourced, best

Once the eBGP peer comes back up, we learn the 192.168.1.0/24 again. Now we can see that the eBGP path is immediately installed in the routing table as the best path.

*Feb 10 00:37:33.259: BGP(0): 172.16.56.6 rcvd UPDATE w/ attr: nexthop 172.16.56.6, origin i, metric 0, path 65000

*Feb 10 00:37:33.259: BGP(0): 172.16.56.6 rcvd 192.168.1.0/24

*Feb 10 00:37:33.271: BGP(0): Revise route installing 1 of 1 routes for 192.168.1.0/24 -> 172.16.56.6(global) to main IP table

*Feb 10 00:37:33.271: RT: updating bgp 192.168.1.0/24 (0x0) via 172.16.56.6

*Feb 10 00:37:33.271: RT: closer admin distance for 192.168.1.0, flushing 1 routes

*Feb 10 00:37:33.271: RT: add 192.168.1.0/24 via 172.16.56.6, bgp metric [20/0]

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "bgp 65001", distance 20, metric 0

Tag 65000, type external

Last update from 172.16.56.6 00:00:11 ago

Routing Descriptor Blocks:

* 172.16.56.6, from 172.16.56.6, 00:00:11 ago

Route metric is 0, traffic share count is 1

AS Hops 1

Route tag 65000

R1#show ip bgp 192.168.1.0

BGP routing table entry for 192.168.1.0/24, version 1568

Paths: (1 available, best #1, table default)

Flag: 0x820

Not advertised to any peer

65000

172.16.56.6 from 172.16.56.6 (192.168.8.1)

Origin IGP, metric 0, localpref 100, weight 32769, valid, external, best


If you do not want to apply the weight to all updates received from the neighbor, you can use a route-map to change the weight for only certain updates from the peer. Please see the configuration example below.

router bgp 65001

bgp log-neighbor-changes

neighbor 172.16.56.6 remote-as 65000

!

address-family ipv4

no synchronization

redistribute ospf 1 match internal external 1 external 2

neighbor 172.16.56.6 activate

neighbor 172.16.56.6 route-map set_weight in

no auto-summary

exit-address-family

route-map set_weight permit 10

match ip address 1

set weight 32769

access-list 1 permit 192.168.1.0 0.0.0.255

When the update is received, you can check the ACL for matches.

R1#show access-list 1

Standard IP access list 1

10 permit 192.168.1.0, wildcard bits 0.0.0.255 (2 matches)

Labels: , , ,