RP | BM | BM | TRWG | HI | MWD | MFB | TZ | CU | I2U | PH | TAW | ID | AAB | FSB | RR | TCU | TAW | PH | Q | QTC | MYD | BBBS | BBS | Network Advisor: router
Showing posts with label router. Show all posts
Showing posts with label router. Show all posts

Wednesday, October 17, 2007

Juniper unveils giant router

Juniper claims router surpasses Cisco offering

Juniper Networks Monday announced a eight-slot core router for service providers that boasts bandwidth of 1.6Tbps, more than twice that of the company’s previous high-end system.

The vendor’s T1600, in a half-rack configuration, blows past the 5-year-old T640, which tops out at 640Gbps. Juniper claims its new box provides 2.5 times the capacity of Cisco’s CRS-1 router with 30% less power and cooling requirements.

T640 customers can upgrade to the new router in 90 minutes without service interruption, Juniper says.

Given that the T640 came out in 2002, they might be eager to do just that.

“The T640 is old,” says Mark Seery, an analyst at Ovum. “Five years is a long time in this business.”

Service-aware routers
The T1600 is also “service aware,” according to Juniper, meaning that it can provide content-specific transmission quality depending on the traffic type – voice and video, in addition to data. Core networks that are not service aware delay new service introduction, lead to inefficient use of resources, force the construction of complex network architectures, and ultimately limit an operator’s competitiveness, according to Juniper.

Service awareness is achieved through in-depth packet processing and policy control. Policy is enabled by Juniper’s recently announced Session Resource Control products, hardware-based controllers running applications which mange subscribers and network resources.

The T1600 also supports the recently introduced point-to-multipoint MPLS (P2MP) feature in the JUNOS operating system. P2MP is intended to provide efficient core video distribution and enhanced optical network integration at 10G and 40Gbps.

A potential downside to the T1600 is its initial lack of support on Juniper’s TX switching matrix, a centralized fabric designed to connect T-series routers into a multiterabit-per-second virtual megarouter. Juniper says customers are demanding higher density and capacity in individual elements for scale rather than connecting multiple lower density systems together.

Juniper also says TX will require an upgrade to support the 100Gbps-per-slot capacity of the T1600. Company officials did not say when this upgrade would be unveiled.

What carriers think
Ovum’s Seery says carriers are not yet confident in the multichassis interconnect options from their vendors.

“I believe all carriers are trying to assess whether they are comfortable with multichassis configurations,” he says. Some carriers are looking for redundancy features, such as the ability to deploy dual distributed switch fabrics, to eliminate the single point of failure current offerings present, Seery says.

Juniper’s hoping carriers won’t wait for the TX support before buying the T1600. Juniper’s deployed 2,500 T640s to date but the company’s share in the core router market slipped from 37% to 30% over the past year.

And Cisco, which announced Monday that it shipped 900 CRS-1s since the product’s launch in 2004, stole some thunder when AT&T picked the CRS-1 to replace its Avici Systems installation after Avici announced it was exiting the core router market.

“The T1600 will help defend Juniper against [Cisco’s] CRS-1,” Seery says. “But it’s not in a strong position until it’s in a TX configuration.”

The T1600 is slated for fourth quarter availability.

The vendor’s T1600, in a half-rack configuration, blows past the 5-year-old T640, which tops out at 640Gbps. Juniper claims its new box provides 2.5 times the capacity of Cisco’s CRS-1 router with 30% less power and cooling requirements.

Wednesday, March 21, 2007

frame-relay static route problem

FAQ

the problem occur when two routers connected via frame-relay switch (2522 router), the configuration on switch is correct as well as on both routers, the loop back interface has been made on RB router i.e RB has 20.0.0.0/8, while at RA router the static router is defined as
ip route 20.0.0.0 0.255.255.255 serial 0

it was not able to send packets to 20.0.0.0/8 when run debug, it got error like encapsulation failed, now when it replaced the static route with next hop ip it was working fine, why ????

When a layer3 packet is going to be sent out, the router must know the layer 2 header to encapsulate the Layer3 packet.In this case, it must know which dlci number (as well as other layer2 information) to encap the IP packet. If you only indicate a connected interface for the static route, and there are many dlci numbers on this interface, the router will not know which dlci number to use and thus gives you a encapsulation failure message.

On the other hand, if you indicate a next-hop address on the static route and there is a frame-relay map which maps a dlci number to this next-hop address , the router will know the exact dlci number to encapsulate the ip packet and the packet will be sent out successfully.