IKE Phase 1 Proposal:
* Method: indicates whether preshared key (“pre”) or digital certificates (using “RSA”-Sig or “DSA”-Sig) are used as the authentication method
* DH Group: Indicates the Diffie-Hellman group used for the key generation or exchange (“g1”, “g2” or “g5”)
* Encrypt: Indicates the encryption algorithm (“3DES”, “DES” or “AES”)
* Auth: Indicates the hash algorithm (“MD5” or “SHA-1”)
Values:
--------
(pre|dsa|rsa) (g1|g2|g5) (DES|3DES|AES) (MD5|SHA1)
Examples of a Phase 1 proposal include:
---------------------------------------
* pre-g1-des-md5
* dsa-g2-3des-sha1
* rsa-g5-aes128-md5
* or the current de-facto standard: pre-g2-3des-sha1
IPSEC Phase 2 Proposal:
* PFS: Indicates whether PFS is not being used (“nopfs”) or if it is, which DH group is being applied (“g1”, “g2” or “g5”).
* Encapsulation: Whether the ESP (“esp”) protocol is being used for encryption and authentication, or just the AH (“ah”) protocol.
* Encryption : Indicates the encryption algorithm (“DES”, “3DES” or “AES”)
* Authentication: Indicates the hash algorithm (“MD5” or “SHA1”)
Valeurs:
--------
(nopfs|g1|g2|g5) (ESP|AH) (DES|3DES|AES) (MD5|SHA1)
Examples of a Phase 2 proposal include:
---------------------------------------
* nopfs-esp-des-md5
* g1-ah-null-sha1
* And the defacto standard: g2-esp-3des-sha1
Tuesday, December 28, 2010
Cisco's top 10 rivals
A great "state of the union" article addressing Cisco's top rivals popped up on Network World. We knew you'd want to see the list:
Cisco vs. Juniper (core Internet routing, security/VPN)
Cisco vs. Alcatel-Lucent (carrier edge routing)
Cisco vs. HP (Ethernet switching)
Cisco vs. Aruba (wireless LANs)
Cisco vs. Polycom (videoconeferencing)
Cisco vs. Avaya (Unified communications and collaboration)
Cisco vs. Microsoft (unified communications)
Cisco vs. Check Point (network security)
Cisco vs. IBM (data center)
Cisco vs. Brocade (Fibre Channel storage-area networks)
What did Jim Duffy have to say about the Juniper vs. Cisco rivalry? Just the facts; take a read:
Cisco vs. Juniper
Juniper took one-third of Cisco's share in core routing shortly after coming onto the scene in 1997. The company remains Cisco's one and only rival in core Internet routing with a 30% share of the $643 million market in the second quarter, according to Dell'Oro Group. And the two companies seek to one up each other with every announcement of a higher speed, higher density system. Current entries in this race are Cisco's recently-announced CRS-3 and Juniper's 250Gbps per slot ASICs for its T series systems.
Juniper is also Cisco's closest competitor in a number of security markets, including the $2 billion VPN hardware and software market, and in the $7 billion overall security market, which includes firewalls, VPNs, unified threat management and intrusion detection and prevention systems, according to IDC. Juniper gained a big presence in firewall/VPN systems with its 2004 acquisition of NetScreen.
Cisco vs. Alcatel-Lucent
Juniper is also an adversary in carrier edge routing but so too is Alcatel-Lucent. Alcatel-Lucent and Juniper take turns trading the No. 2 position in edge routing, where Ethernet service delivery is a key requirement for applications such as IPTV, Ethernet VPNs and mobile backhaul. Both companies are targeting Cisco's aged 7600 series and new ASR 9000 routers as their key competitive targets. Cisco's advantage is its vast installed base – 43% of the $1.34 billion market in the second quarter, according to Dell'Oro. Alcatel-Lucent's challenging that and looking to grow beyond its 19% share with terabit ASICs for its Service Router 7750 optimized for traffic management and processing of IPTV, WebTV, mobile backhaul and business VPN traffic; and 100Gbps Ethernet interfaces for the edge router.
Earlier this month, Alcatel-Lucent even made some noise in the enterprise switching market with a 5Tbps OmniSwitch with 10/40/100G Ethernet support that takes aim at the enterprise core – and Cisco.
Cisco vs. HP
With a 72% share of the $16 billion market in 2009, Cisco is dominant in Ethernet switching. It would be hard to pinpoint a rival in a market where Cisco is essentially unrivaled. Yet HP is most active and vocal in taking on Cisco in enterprise switching. At 10% share, HP is the No. 2 vendor, thanks in large part to its $2.7 billion acquisition of 3Com earlier this year.
It verbally challenges Cisco every opportunity it gets at trade shows and conferences. Despite its dominant lead, Cisco is not standing pat. The company continues to unveil new platforms and enhance existing ones, all optimized for three key strategic markets: video, virtualization and collaboration.
Former partners HP and Cisco are also becoming bitter data center rivals. HP may have drawn first blood by pledging to revive its ProCurve networking division after Mark Hurd became CEO in 2007. Then Cisco invaded HP's, and IBM's, traditional turf by coming out with its own blade and rack mount data center servers. HP responded by acquiring 3Com to boost its switch market share and overall networking portfolio, and then bashing Cisco at every public opportunity. Finally, Cisco vanquished HP as a reseller; and HP banished Cisco from its data centers.
Cisco vs. Aruba
Similar to switching, Cisco has a close-to-dominant position in wireless LANs with a 58% share of the $1.6 billion market in 2009. Aruba's next with 9%. Though that gap is sizeable, Aruba gives Cisco all it can handle in North America sales, where it had a higher percentage penetration in the U.S. than Cisco had in the second quarter of this year. Aruba is especially strong in higher education, healthcare and other enterprise verticals, and is outpacing Cisco in 802.11n penetration, according to Dell'Oro Group. And over the last four quarters, Aruba's market share has grown from 8.7% to 11.9% while Cisco's has declined from 60.7% to 54.8%. Not that Aruba is the sole beneficiary of that decline but it undoubtedly played a leading role.
But Cisco recently came out with an "entry level" 802.11n access point that could help boost its share of that specific market. And it took pains to take the pain out of 11n deployments.
Meanwhile Aruba's been lining up top-shelf OEM partners, like Dell; and expanding into new markets through acquisition.
Cisco vs. Polycom
Cisco's keen on video, noting – by its own research -- that it will exceed 91% of global consumer IP traffic by 2014.This will drive sales of switches and routers on the back end of service provider networks to handle all that hefty traffic. On the front end? Cisco rolled out TelePresence virtual conferencing systems for the business and home, and acquired both Pure Digital, the maker of Flip pocket video cameras, and Polycom rival Tandberg to fill out the low-end and mid-range enterprise videoconferencing portfolio. Tandberg was the market leader on videoconeferencing, so now Cisco is with a roughly 40% share of a $2 billion market, according to Wainhouse Research.
Polycom isn't taking this lying down: it aligned itself with Cisco rivals IBM and Juniper to drive sales of its own videoconferencing systems along with IBM servers and storage systems, and Juniper routers.
Productwise, Cisco and Polycom match up fairly evenly, with conference room- and office-sized, and personal Telepresence and videoconferencing systems, and associated equipment and applications. Cisco recently debuted a home TelePresence system called Umi to work with consumer HDTVs but its price is being criticized. Can you see me now?
Cisco vs. Avaya
Unified communications and collaboration are hot target markets for Cisco, perhaps the most strategic after its core routing and switching businesses. But while Cisco plays in scores of markets with another 30 or so adjacent ones in its sights, Avaya's sole raison d’etre is UC and collaboration. Indeed, Avaya and Cisco are Nos. 1 and 2 in enterprise telephony, according to Dell'Oro Group, with 17% and 14.6% shares, respectively, of the $12 billion market in 2009. The companies were early entrants and decade-long competitors in IP PBXs and handsets.
The most recent battlefield for the two is tablet computers tailored specifically for enterprise collaboration and unified communications. Avaya introduced Flare last month, a mobile/dockable 11.6-inch touchscreen tablet that supports hi-def video, and Avaya's unified communications software for pulling together ad hoc meetings, including hi-def conferences. Cisco's Cius is a 7-inch dockable or mobile touchscreen that also supports Cisco's unified communications software and telepresence platforms. Both Cius and Flare run the Android operating system which enables both to support a wealth of existing or easily developed applications. Flare demonstrates that Avaya will not take kindly to any share gains in its one and only market from a determined and aggressive behemoth that plays in tens of others.
Cisco vs. Microsoft
Microsoft and Cisco are in that gray area referred to as "coopetition." They compete and collaborate on unified communications. After Microsoft entered into the Innovative Communications Alliance with Nortel in 2006, Microsoft and Cisco stated their intentions to continue working together as well as compete.
But after Nortel imploded and the ICA died, Microsoft took its UC partnership to Cisco's chief switching and data center rival HP. The companies pledged to fund the effort with $180 million and announced it to the world during an HP keynote at the Interop conference in the spring of 2009. As part of the partnership, the two will collaborate on product development around Microsoft's SharePoint, Exchange, OCS and HP's ProCurve networking hardware, as well as interoperability between OCS conferencing capabilities and HP's Halo Telepresence audio visual and conferencing technology.
Cisco vs. Check Point
Cisco is far and away the leading vendor in the $7 billion overall network security market – which includes firewall/VPN, unified threat management, intrusion detection and prevention, and standalone VPNs, according to IDC. The company leads in each market except for unified threat management. But in the largest sub-segment – the $2.6 billion firewall/VPN hardware and software market – CheckPoint is No.2.
CheckPoint is a pioneer in stateful inspection firewalls and, like Avaya and unified communications, is focused solely on the security business with products dedicated to firewalling, VPNs, unified threat management and intrusion prevention. Cisco also has standalone appliances dedicated for these tasks, but in addition integrates many of these capabilities into the operating system software of its routers and switches, which are ubiquitous through the Internet and enterprise networks.
Cisco vs. IBM
IBM has been getting tighter with Cisco rivals Juniper and Brocade ever since Cisco set its sights on data center servers and virtualization, an opportunity that Cisco says is $350 billion annually. IBM is OEMing switches and routers from both companies and, though much quieter than HP, distancing itself from Cisco at every opportunity.
IBM acquired blade switch specialist BLADE Network Technologies which competes with Cisco for data center switching mind- and market share; and next year will unveil the "Stratus" data center fabric architecture with Juniper to compete directly with Cisco's Unified Fabric for the data center.
Cisco rolled out the so-called Unified Computing System a year-and-a-half ago, which is intended to re-architect legacy data centers by consolidating servers, switching, virtualization and storage access. Cisco has sold UCS to 1,700 customers to date. Cisco also rolled out Ethernet switches dedicated to data center fabric switching two years ago with the Nexus line. Nexus is now on an annualized run rate of $2 billion. Over the past two years, Cisco has also enhanced existing Catalyst switches with 10G modules and virtualization support for data center applications, and has tightly aligned itself with storage titan EMC and virtualization software specialist VMware to accelerate the adoption of Cisco products into the data center.
Cisco vs. Brocade
Brocade and Cisco are 1 and 2, respectively, in Fibre Channel storage-area networks. Brocade has the lion's share of the Fibre Channel SAN market at 64% and Cisco's attempting to take the industry to Fibre Channel-over-Ethernet, a converged SAN/LAN switching fabric dependent on Ethernet switches – an area where Cisco is dominant.
Brocade's not totally resisting the move to Ethernet: the company acquired Cisco competitor Foundry Networks for Ethernet switching in an effort to integrate its own FCoE development and converged data center fabric. Brocade also recently proposed a unified data center fabric architecture, called Brocade One, as an alternative to those from Cisco and IBM/Juniper.
Even so, Brocade continues to invest in, develop and aggressively market its native Fibre Channel technology to its deep installed base and cash cow. Cisco entered the Fibre Channel SAN business in 2002 and, after initially taking half of the modular SAN switch market in 2007, has fallen to 36% share of the $843 million market in 2009, according to Dell'Oro. In that time, Brocade's share rose from 50% in 2007 to its current 64%, according to Dell'Oro.
Cisco vs. Juniper (core Internet routing, security/VPN)
Cisco vs. Alcatel-Lucent (carrier edge routing)
Cisco vs. HP (Ethernet switching)
Cisco vs. Aruba (wireless LANs)
Cisco vs. Polycom (videoconeferencing)
Cisco vs. Avaya (Unified communications and collaboration)
Cisco vs. Microsoft (unified communications)
Cisco vs. Check Point (network security)
Cisco vs. IBM (data center)
Cisco vs. Brocade (Fibre Channel storage-area networks)
What did Jim Duffy have to say about the Juniper vs. Cisco rivalry? Just the facts; take a read:
Cisco vs. Juniper
Juniper took one-third of Cisco's share in core routing shortly after coming onto the scene in 1997. The company remains Cisco's one and only rival in core Internet routing with a 30% share of the $643 million market in the second quarter, according to Dell'Oro Group. And the two companies seek to one up each other with every announcement of a higher speed, higher density system. Current entries in this race are Cisco's recently-announced CRS-3 and Juniper's 250Gbps per slot ASICs for its T series systems.
Juniper is also Cisco's closest competitor in a number of security markets, including the $2 billion VPN hardware and software market, and in the $7 billion overall security market, which includes firewalls, VPNs, unified threat management and intrusion detection and prevention systems, according to IDC. Juniper gained a big presence in firewall/VPN systems with its 2004 acquisition of NetScreen.
Cisco vs. Alcatel-Lucent
Juniper is also an adversary in carrier edge routing but so too is Alcatel-Lucent. Alcatel-Lucent and Juniper take turns trading the No. 2 position in edge routing, where Ethernet service delivery is a key requirement for applications such as IPTV, Ethernet VPNs and mobile backhaul. Both companies are targeting Cisco's aged 7600 series and new ASR 9000 routers as their key competitive targets. Cisco's advantage is its vast installed base – 43% of the $1.34 billion market in the second quarter, according to Dell'Oro. Alcatel-Lucent's challenging that and looking to grow beyond its 19% share with terabit ASICs for its Service Router 7750 optimized for traffic management and processing of IPTV, WebTV, mobile backhaul and business VPN traffic; and 100Gbps Ethernet interfaces for the edge router.
Earlier this month, Alcatel-Lucent even made some noise in the enterprise switching market with a 5Tbps OmniSwitch with 10/40/100G Ethernet support that takes aim at the enterprise core – and Cisco.
Cisco vs. HP
With a 72% share of the $16 billion market in 2009, Cisco is dominant in Ethernet switching. It would be hard to pinpoint a rival in a market where Cisco is essentially unrivaled. Yet HP is most active and vocal in taking on Cisco in enterprise switching. At 10% share, HP is the No. 2 vendor, thanks in large part to its $2.7 billion acquisition of 3Com earlier this year.
It verbally challenges Cisco every opportunity it gets at trade shows and conferences. Despite its dominant lead, Cisco is not standing pat. The company continues to unveil new platforms and enhance existing ones, all optimized for three key strategic markets: video, virtualization and collaboration.
Former partners HP and Cisco are also becoming bitter data center rivals. HP may have drawn first blood by pledging to revive its ProCurve networking division after Mark Hurd became CEO in 2007. Then Cisco invaded HP's, and IBM's, traditional turf by coming out with its own blade and rack mount data center servers. HP responded by acquiring 3Com to boost its switch market share and overall networking portfolio, and then bashing Cisco at every public opportunity. Finally, Cisco vanquished HP as a reseller; and HP banished Cisco from its data centers.
Cisco vs. Aruba
Similar to switching, Cisco has a close-to-dominant position in wireless LANs with a 58% share of the $1.6 billion market in 2009. Aruba's next with 9%. Though that gap is sizeable, Aruba gives Cisco all it can handle in North America sales, where it had a higher percentage penetration in the U.S. than Cisco had in the second quarter of this year. Aruba is especially strong in higher education, healthcare and other enterprise verticals, and is outpacing Cisco in 802.11n penetration, according to Dell'Oro Group. And over the last four quarters, Aruba's market share has grown from 8.7% to 11.9% while Cisco's has declined from 60.7% to 54.8%. Not that Aruba is the sole beneficiary of that decline but it undoubtedly played a leading role.
But Cisco recently came out with an "entry level" 802.11n access point that could help boost its share of that specific market. And it took pains to take the pain out of 11n deployments.
Meanwhile Aruba's been lining up top-shelf OEM partners, like Dell; and expanding into new markets through acquisition.
Cisco vs. Polycom
Cisco's keen on video, noting – by its own research -- that it will exceed 91% of global consumer IP traffic by 2014.This will drive sales of switches and routers on the back end of service provider networks to handle all that hefty traffic. On the front end? Cisco rolled out TelePresence virtual conferencing systems for the business and home, and acquired both Pure Digital, the maker of Flip pocket video cameras, and Polycom rival Tandberg to fill out the low-end and mid-range enterprise videoconferencing portfolio. Tandberg was the market leader on videoconeferencing, so now Cisco is with a roughly 40% share of a $2 billion market, according to Wainhouse Research.
Polycom isn't taking this lying down: it aligned itself with Cisco rivals IBM and Juniper to drive sales of its own videoconferencing systems along with IBM servers and storage systems, and Juniper routers.
Productwise, Cisco and Polycom match up fairly evenly, with conference room- and office-sized, and personal Telepresence and videoconferencing systems, and associated equipment and applications. Cisco recently debuted a home TelePresence system called Umi to work with consumer HDTVs but its price is being criticized. Can you see me now?
Cisco vs. Avaya
Unified communications and collaboration are hot target markets for Cisco, perhaps the most strategic after its core routing and switching businesses. But while Cisco plays in scores of markets with another 30 or so adjacent ones in its sights, Avaya's sole raison d’etre is UC and collaboration. Indeed, Avaya and Cisco are Nos. 1 and 2 in enterprise telephony, according to Dell'Oro Group, with 17% and 14.6% shares, respectively, of the $12 billion market in 2009. The companies were early entrants and decade-long competitors in IP PBXs and handsets.
The most recent battlefield for the two is tablet computers tailored specifically for enterprise collaboration and unified communications. Avaya introduced Flare last month, a mobile/dockable 11.6-inch touchscreen tablet that supports hi-def video, and Avaya's unified communications software for pulling together ad hoc meetings, including hi-def conferences. Cisco's Cius is a 7-inch dockable or mobile touchscreen that also supports Cisco's unified communications software and telepresence platforms. Both Cius and Flare run the Android operating system which enables both to support a wealth of existing or easily developed applications. Flare demonstrates that Avaya will not take kindly to any share gains in its one and only market from a determined and aggressive behemoth that plays in tens of others.
Cisco vs. Microsoft
Microsoft and Cisco are in that gray area referred to as "coopetition." They compete and collaborate on unified communications. After Microsoft entered into the Innovative Communications Alliance with Nortel in 2006, Microsoft and Cisco stated their intentions to continue working together as well as compete.
But after Nortel imploded and the ICA died, Microsoft took its UC partnership to Cisco's chief switching and data center rival HP. The companies pledged to fund the effort with $180 million and announced it to the world during an HP keynote at the Interop conference in the spring of 2009. As part of the partnership, the two will collaborate on product development around Microsoft's SharePoint, Exchange, OCS and HP's ProCurve networking hardware, as well as interoperability between OCS conferencing capabilities and HP's Halo Telepresence audio visual and conferencing technology.
Cisco vs. Check Point
Cisco is far and away the leading vendor in the $7 billion overall network security market – which includes firewall/VPN, unified threat management, intrusion detection and prevention, and standalone VPNs, according to IDC. The company leads in each market except for unified threat management. But in the largest sub-segment – the $2.6 billion firewall/VPN hardware and software market – CheckPoint is No.2.
CheckPoint is a pioneer in stateful inspection firewalls and, like Avaya and unified communications, is focused solely on the security business with products dedicated to firewalling, VPNs, unified threat management and intrusion prevention. Cisco also has standalone appliances dedicated for these tasks, but in addition integrates many of these capabilities into the operating system software of its routers and switches, which are ubiquitous through the Internet and enterprise networks.
Cisco vs. IBM
IBM has been getting tighter with Cisco rivals Juniper and Brocade ever since Cisco set its sights on data center servers and virtualization, an opportunity that Cisco says is $350 billion annually. IBM is OEMing switches and routers from both companies and, though much quieter than HP, distancing itself from Cisco at every opportunity.
IBM acquired blade switch specialist BLADE Network Technologies which competes with Cisco for data center switching mind- and market share; and next year will unveil the "Stratus" data center fabric architecture with Juniper to compete directly with Cisco's Unified Fabric for the data center.
Cisco rolled out the so-called Unified Computing System a year-and-a-half ago, which is intended to re-architect legacy data centers by consolidating servers, switching, virtualization and storage access. Cisco has sold UCS to 1,700 customers to date. Cisco also rolled out Ethernet switches dedicated to data center fabric switching two years ago with the Nexus line. Nexus is now on an annualized run rate of $2 billion. Over the past two years, Cisco has also enhanced existing Catalyst switches with 10G modules and virtualization support for data center applications, and has tightly aligned itself with storage titan EMC and virtualization software specialist VMware to accelerate the adoption of Cisco products into the data center.
Cisco vs. Brocade
Brocade and Cisco are 1 and 2, respectively, in Fibre Channel storage-area networks. Brocade has the lion's share of the Fibre Channel SAN market at 64% and Cisco's attempting to take the industry to Fibre Channel-over-Ethernet, a converged SAN/LAN switching fabric dependent on Ethernet switches – an area where Cisco is dominant.
Brocade's not totally resisting the move to Ethernet: the company acquired Cisco competitor Foundry Networks for Ethernet switching in an effort to integrate its own FCoE development and converged data center fabric. Brocade also recently proposed a unified data center fabric architecture, called Brocade One, as an alternative to those from Cisco and IBM/Juniper.
Even so, Brocade continues to invest in, develop and aggressively market its native Fibre Channel technology to its deep installed base and cash cow. Cisco entered the Fibre Channel SAN business in 2002 and, after initially taking half of the modular SAN switch market in 2007, has fallen to 36% share of the $843 million market in 2009, according to Dell'Oro. In that time, Brocade's share rose from 50% in 2007 to its current 64%, according to Dell'Oro.
Monday, December 27, 2010
BGP at 18 - Lessons in Protocol Design
Meet Mr.Yakov Rekhter (Inventor of RFC 1918), walks us though his experience on how he has build BGP - Simply Awesome. Njoi
Sunday, December 26, 2010
MPLS, GMPLS, MPLS-TP
What is MPLS ?
MPLS stands for "Multiprotocol Label Switching". In an MPLS network, incoming packets are assigned a "label" by a "label edge router (LER)". Packets are forwarded along a "label switch path (LSP)" where each "label switch router (LSR)" makes forwarding decisions based solely on the contents of the label. At each hop, the LSR strips off the existing label and applies a new label which tells the next hop how to forward the packet.
Label Switch Paths (LSPs) are established by network operators for a variety of purposes, such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for network-based virtual private networks. In many ways, LSPs are no different than circuit-switched paths in ATM or Frame Relay networks, except that they are not dependent on a particular Layer 2 technology.
An LSP can be established that crosses multiple Layer 2 transports such as ATM, Frame Relay or Ethernet. Thus, one of the true promises of MPLS is the ability to create end-to-end circuits, with specific performance characteristics, across any type of transport medium, eliminating the need for overlay networks or Layer 2 only control mechanisms.
MPLS evolved from numerous prior technologies including Cisco's "Tag Switching", IBM's "ARIS", and Toshiba's "Cell-Switched Router".
What is GMPLS ?
Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber)." GMPLS represents a natural extension of MPLS to allow MPLS to be used as the control mechanism for configuring not only packet-based paths, but also paths in non-packet based devices such as optical switches, TDM muxes, and SONET/ADMs.
GMPLS (Generalized Multiprotocol Label Switching), also known as Multiprotocol Lambda Switching.
Components of GMPLS
GMPLS introduces a new protocol called the "Link Management Protocol" or LMP. LMP runs between adjacent nodes and is responsible for establishing control channel connectivity as well as failure detection. LMP also verifies connectivity between channels.
Additionally, the IETF's "Common Control and Measurement Plane" working group (ccamp) is working on defining extensions to interior gateway routing protocols such as OSPF and IS-IS to enable them to support GMPLS operation.
Features of GMPLS
GMPLS supports several features including:
MPLS-TP is a set of MPLS protocols that are being defined in IETF. It is a simplified version of MPLS for transport networks with some of the MPLS functions turned off, such as Penultimate Hop Popping (PHP), Label-Switched Paths (LSPs) merge, and Equal Cost Multi Path (ECMP). MPLS-TP does not require MPLS control plane capabilities and enables the management plane to set up LSPs manually. Its OAM may operate without any IP layer functionalities.
MPLS stands for "Multiprotocol Label Switching". In an MPLS network, incoming packets are assigned a "label" by a "label edge router (LER)". Packets are forwarded along a "label switch path (LSP)" where each "label switch router (LSR)" makes forwarding decisions based solely on the contents of the label. At each hop, the LSR strips off the existing label and applies a new label which tells the next hop how to forward the packet.
Label Switch Paths (LSPs) are established by network operators for a variety of purposes, such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for network-based virtual private networks. In many ways, LSPs are no different than circuit-switched paths in ATM or Frame Relay networks, except that they are not dependent on a particular Layer 2 technology.
An LSP can be established that crosses multiple Layer 2 transports such as ATM, Frame Relay or Ethernet. Thus, one of the true promises of MPLS is the ability to create end-to-end circuits, with specific performance characteristics, across any type of transport medium, eliminating the need for overlay networks or Layer 2 only control mechanisms.
MPLS evolved from numerous prior technologies including Cisco's "Tag Switching", IBM's "ARIS", and Toshiba's "Cell-Switched Router".
What is GMPLS ?
Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber)." GMPLS represents a natural extension of MPLS to allow MPLS to be used as the control mechanism for configuring not only packet-based paths, but also paths in non-packet based devices such as optical switches, TDM muxes, and SONET/ADMs.
GMPLS (Generalized Multiprotocol Label Switching), also known as Multiprotocol Lambda Switching.
Components of GMPLS
GMPLS introduces a new protocol called the "Link Management Protocol" or LMP. LMP runs between adjacent nodes and is responsible for establishing control channel connectivity as well as failure detection. LMP also verifies connectivity between channels.
Additionally, the IETF's "Common Control and Measurement Plane" working group (ccamp) is working on defining extensions to interior gateway routing protocols such as OSPF and IS-IS to enable them to support GMPLS operation.
Features of GMPLS
GMPLS supports several features including:
- Link Bundling - the grouping of multiple, independent physical links into a single logical link
- Link Hierarchy - the issuing of a suite of labels to support the various requirements of physical and logical devices across a given path
- Unnumbered Links - the ability to configure paths without requiring an IP address on every physical or logical interface
- Constraint Based Routing - the ability to automatically provision additional bandwidth, or change forwarding behavior based on network conditions such as congestion or demands for additional bandwidth
MPLS-TP is a set of MPLS protocols that are being defined in IETF. It is a simplified version of MPLS for transport networks with some of the MPLS functions turned off, such as Penultimate Hop Popping (PHP), Label-Switched Paths (LSPs) merge, and Equal Cost Multi Path (ECMP). MPLS-TP does not require MPLS control plane capabilities and enables the management plane to set up LSPs manually. Its OAM may operate without any IP layer functionalities.
Pseudowires and LSPs
Breaking down the differences between MPLS and MPLS-TP
When it comes to the major differences between MPLS and MPLS-TP, here's what you need to know.
Bidirectional Label Switched Paths (LSPs). MPLS is based on the traditional IP routing paradigm -- traffic from A to B can flow over different paths than traffic from B to A. But transport networks commonly use bidirectional circuits, and MPLS-TP also mandates the support of bidirectional LSPs (a path through an MPLS network). In addition, MPLS-TP must support point-to-multipoint paths.
Management plane LSP setup. Paths across MPLS networks are set up with control-plane protocols (IP routing protocols or Resource Reservation Protocol (RSVP) for MPLS Traffic Engineering (MPLS-TE). MPLS-TP could use the same path setup mechanisms as MPLS (control plane-based LSP setup) or the traditional transport network approach where the paths are configured from the central network management system (management plane LSP setup).
Control plane is not mandatory. Going a step farther, MPLS-TP nodes should be able to work with no control plane, with paths across the network computed solely by the network management system and downloaded into the network elements.
Out-of-band management. MPLS nodes usually use in-band management or at least in-band exchange of control-plane messages. MPLS-TP network elements have to support out-of-band management over a dedicated management network (similar to the way some transport networks are managed today).
Total separation of management/control and data plane. Data forwarding within an MPLS-TP network element must continue even if its management or control plane fails. High-end routers provide similar functionality with non-stop forwarding, but this kind of functionality was never mandatory in traditional MPLS.
No IP in the forwarding plane. MPLS nodes usually run IP on all interfaces because they have to support the in-band exchange of control-plane messages. MPLS-TP network elements must be able to run without IP in the forwarding plane.
Explicit support of ring topologies. Many transport networks use ring topologies to reduce complexity. MPLS-TP thus includes mandatory support for numerous ring-specific mechanisms.
The essential features of MPLS-TP defined by IETF and ITU-T are:
• MPLS forwarding plane with restrictions
• PWE3 Pseudowire architecture
• Control Plane: static or dynamic Generalized MPLS (G-MPLS)
• Enhanced OAM functionality
• OAM monitors and drives protection switching
• Use of Generic Associated Channel (G-ACh) to support fault, configuration, accounting, performance, and security (FCAPS) functions
• Multicasting is under further study
MPLS-TP is a subset of the MPLS technology. Therefore, it's possible to build parallel IP+MPLS and MPLS-TP networks on the same physical infrastructure, one offering IP and MPLS-based VPN transport and the other one offering traditional circuit-based services. Don't expect to see many providers using this approach. Those that are embracing IP+MPLS wholeheartedly are already offering legacy services across their new MPLS networks.
More conservative service providers might opt to upgrade their existing SONET/SDH/DWDM transport network to MPLS-TP. Those providers will probably retain the separation between tightly-managed transport network (where every action is triggered by the central management software) and the more dynamic IP+MPLS network, which will be just one of many clients of the MPLS-TP network. I suspect that these service providers will be left with a single client of their MPLS-TP network in the long run, as most end-user traffic (including voice) will be migrated to IP anyway … unless, of course, they choose to focus on the fixed-bandwidth-reselling business, where the static nature of MPLS-TP will definitely be beneficial.
Breaking down the differences between MPLS and MPLS-TP
When it comes to the major differences between MPLS and MPLS-TP, here's what you need to know.
Bidirectional Label Switched Paths (LSPs). MPLS is based on the traditional IP routing paradigm -- traffic from A to B can flow over different paths than traffic from B to A. But transport networks commonly use bidirectional circuits, and MPLS-TP also mandates the support of bidirectional LSPs (a path through an MPLS network). In addition, MPLS-TP must support point-to-multipoint paths.
Management plane LSP setup. Paths across MPLS networks are set up with control-plane protocols (IP routing protocols or Resource Reservation Protocol (RSVP) for MPLS Traffic Engineering (MPLS-TE). MPLS-TP could use the same path setup mechanisms as MPLS (control plane-based LSP setup) or the traditional transport network approach where the paths are configured from the central network management system (management plane LSP setup).
Control plane is not mandatory. Going a step farther, MPLS-TP nodes should be able to work with no control plane, with paths across the network computed solely by the network management system and downloaded into the network elements.
Out-of-band management. MPLS nodes usually use in-band management or at least in-band exchange of control-plane messages. MPLS-TP network elements have to support out-of-band management over a dedicated management network (similar to the way some transport networks are managed today).
Total separation of management/control and data plane. Data forwarding within an MPLS-TP network element must continue even if its management or control plane fails. High-end routers provide similar functionality with non-stop forwarding, but this kind of functionality was never mandatory in traditional MPLS.
No IP in the forwarding plane. MPLS nodes usually run IP on all interfaces because they have to support the in-band exchange of control-plane messages. MPLS-TP network elements must be able to run without IP in the forwarding plane.
Explicit support of ring topologies. Many transport networks use ring topologies to reduce complexity. MPLS-TP thus includes mandatory support for numerous ring-specific mechanisms.
Cisco Configuration Partitioning
The Configuration Partitioning feature provides modularization ("partitioning") of the running configuration state to provide granular access to the running configuration in Cisco IOS software.
This feature is enabled by default in Cisco IOS software images that include this feature.
The configuration state of a device is retrieved dynamically whenever a user issues the show running-config command. When the Configuration Partitioning feature is enabled, the system groups the configuration state of the device into parts (called "partitions") so that only the configuration state the user wishes to review is retrieved when generating a displayed list of commands in the running configuration. This feature improves performance for high-end systems with complex configurations because only a part of the running configuration state is processed when generating the running configuration command list, as opposed to the existing method of processing the entire system configuration state.
Default configuration partitions are provided by the introduction of this feature; other Cisco IOS software features may define their own command partitions in later releases.
This feature was introduced in software images for the Cisco 7600 series in Release 12.2(33)SRB.
Benefits of Partitioning the Running Configuration
The Configuration Partitioning feature is the latest in a series of Configuration Generation Performance Enhancement Features for Cisco IOS software. This feature improves the system's response time by providing a method for querying only the system component you wish to review when issuing the show running-config command.
When the Configuration Partitioning feature is enabled, the system groups the configuration state of the device into parts (called "partitions") for the purpose of generating the virtual running configuration file (the list of configuration commands). A new command, show running-config partition, allows you to display only the part of the running configuration that you want to examine, rather than having to display the entire running configuration at once, or displaying only lines that match a certain string.
The key benefit of this feature is that it increases system performance by allowing the system to run the NVGEN process for only the collection of system components (such as specific interfaces) that you need to display. This is in contrast to other existing extensions to the show running-config command, which only filter the generated list after all system components have been processed.
The selective processing of the system's configuration state for the purpose of generating a partial running configuration is called "configuration partitioning."
More granular access to configuration information offers important performance benefits for high-end routing platforms with very large configuration files, while also enhancing configuration management by allowing advanced configuration features to be implemented at a more granular level. Advanced configuration options include Cisco IOS software support for provisioning of customer services, Config Rollback, Config Locking, and configuration access control.
Example
show running-config partition ?
Issuing this command will show you the list of running configuration parts available for display on your system.
If the Configuration Partitioning feature is supported on your system and is enabled, you will see the string "config partition is TRUE" as the first line of help output.
If you receive an error message when entering the command syntax shown here, this feature is not supported on your system. See the command documentation for the show running-config command for existing extensions of that command in other releases that allow you to show only part of the running configuration.
Router# show running-config partition ?
config partition is TRUE
access-list All access-list configurations
boot All boot configurations
class-map All class-map configurations
common All remaining unregistered configurations
global-cdp All global cdp configurations
interface All Interface specific Configurations
ip-as-path All IP as-path configurations
ip-community All IP community list configurations
ip-domain-list All ip domain list configurations
ip-prefix-list All ip prefix-list configurations
ip-static-routes All IP static configurations
line All line mode configurations
policy-map All policy-map configurations
route-map All route-map configurations
router All routing configurations
snmp All SNMP configurations
tacacs All TACACS configurations
As an example, to have the system perform the NVGEN process on only the components associated with the access-list parts of the running configuration state, and display only the access-list related configurations, you would enter the show running-config partition access-list command:
Router# show running-config partition access-list
Building configuration...
Current configuration : 127 bytes
!
Configuration of Partition access-list
!
!
!
access-list 90 permit 0.0.0.0 1.2.3.5
access-list 100 permit 10 any any
!
end
Disabling the Configuration Partitioning Feature
Because this feature offers improved performance for existing commands, this feature is enabled by default for Cisco IOS software images that support this feature. However, you may want to disable this feature if you determine that it is not needed, as this feature does use a small amount of system resources (memory and CPU utilization). To disable configuration partitioning, perform the following task, which assumes you are starting in user EXEC mode.
Router(config)# no parser config partition
Disabling config partitioning
Router(config)#
Saturday, December 25, 2010
Difference between IP and MPLS
IP uses hop-by-hop destination-only forwarding paradigm. When forwarding IP packets, each router in the path has to look up the packet's destination IP address in the IP routing table and forward the packet to the next-hop router.
MPLS uses a variety of protocols to establish Label Switched Paths (LSP) across the network. LSPs are almost like Frame Relay or asynchronous transfer mode (ATM) permanent virtual circuit (PVC), with two major differences: they are unidirectional and they can merge (all LSPs toward the same egress router could merge somewhere in the network). One of the protocols used in MPLS networks is Label Distribution Protocol (LDP), which builds the LSPs based on IP routing table, making an MPLS network automatically functionally equivalent to a pure IP network.
In theory, MPLS forwarding might be marginally faster than IP forwarding (due to simpler label lookup).
MPLS uses a variety of protocols to establish Label Switched Paths (LSP) across the network. LSPs are almost like Frame Relay or asynchronous transfer mode (ATM) permanent virtual circuit (PVC), with two major differences: they are unidirectional and they can merge (all LSPs toward the same egress router could merge somewhere in the network). One of the protocols used in MPLS networks is Label Distribution Protocol (LDP), which builds the LSPs based on IP routing table, making an MPLS network automatically functionally equivalent to a pure IP network.
After the web of LSPs has been established, it can be used to forward IP packets: the first (ingress) router inserts a label (or a stack of them) in front of the IP header and forwards the packet. All the subsequent Label Switch Routers (LSR) ignore the IP headers and perform packet forwarding based on the labels in front of them. Finally, the egress router removes the label and forwards the original IP packet toward its final destination.
In theory, MPLS forwarding might be marginally faster than IP forwarding (due to simpler label lookup).
Friday, December 24, 2010
Juniper targets cloud, mobile Internet in 2011
Juniper's strategic initiatives in 2011 and beyond are cloud computing and the mobile Internet.
In cloud computing, Juniper next year will unleash products to support its Project Stratus plan to deliver a flat, unified fabric for data centers and cloud computing environments. The products will include switches and routers designed to be able to be linked together into a virtual chassis.
Juniper has also lined up IBM to help it develop the Stratus fabric. Stratus is designed to flatten and scale data center and cloud switching fabrics for high-performance, low latency, resiliency and support for LAN and storage convergence.
In the mobile Internet, Juniper is acquiring companies to fill out its portfolio in several areas of this market. Most recently, it acquired WLAN pioneer Trapeze Networks from Trapeze parent Belden to fill a yawning gap in its mobile enterprise offerings. And earlier this year, Juniper acquired SMobile, a maker of security software for mobile handsets supporting an array of operating systems.
Juniper CEO Kevin Johnson recently prepared analysts for major thrusts in cloud computing and mobile Internet in 2011:
"We are beginning to add key sales and marketing resources ahead of several planned launches in 2011," Johnson said during Juniper's third quarter conference call in mid-October. "We are positioning for the opportunities we see in 2011."
Overarching the cloud computing and mobile Internet initiatives is Juniper's software strategy. Juniper is also bolstering its software prowess by lining up third-party development partners for its three platforms: JUNOS, JUNOS Space and JUNOS Pulse. In this effort, Juniper is looking to emulate the success Microsoft and Apple have had in recruiting hundreds of software partners to their products and platforms.
And the foundation of them is Juniper's 30% share of the service provider router market and burgeoning enterprise business. After shipping its first product in 1997, Juniper is now a $4 billion company with a 65%-to-35% split between service provider and enterprise, respectively. The company is targeting annual growth of 20%.
Juniper is second to Cisco in router market share. The company just unveiled its newest Internet core router, the T4000, which aims to double the performance and capacity of Cisco's largest machine, the CRS-3. In addition to technical agility, Juniper, Cisco and everyone will be challenged by regulations and recent regulatory ambiguity.
"Content monetization is hostage to net neutrality issues," says Tom Nolle, president of consultancy CIMI Corp. "They, like everybody else, have got to try and navigate their messages through an uncertain regulatory and business framework. We don't really know how all of that is going to shake out."
In the enterprise, the road is a bit tougher. Cisco virtually owns the Ethernet switching market with a 72% share of the $19.4 billion in worldwide revenue for 2010. Juniper owns less than 2% but that's from 0% 30 months ago.
The challenge is growing that business beyond a half billion dollars, which many over the years have found hard to do against Cisco and HP. It will require a receptive channel, analysts say.
" Almost all (switching companies) have a difficult time breaking over the $100 million/quarter wall," says Zeus Kerrvala of The Yankee Group. "A lot of the channel is saturated by Cisco and HP. How does Juniper manage to capture some of the channel from the two big heavyweights in that space?"
Another is being too reliant on partners for lucrative new opportunities, like virtual data centers and cloud computing. Messages can get mixed if there are too many messengers.
"Juniper relies very heavily on its relationships with IBM and Dell," Nolle says. "It's always hard to sing a song through a third party."
Nolle also notes the possibility that IBM may have to get into the networking business. IBM did recently buy BLADE Network Technologies, a company that makes blade switches for data center racks. BLADE is also a technology partner of Juniper's and has some products that overlap a bit in top-of-rack applications.
In enterprise routers, Juniper is second to Cisco in high-end router market share, according to Dell'Oro Group. In the third quarter of 2010, Juniper had a 19% share of the $139 million in revenue generated for the quarter. But this is down from a 26% share a year ago.
In access routers, Juniper has a 2% share of the $705 million market in the third quarter. Cisco had an 87% share of that market. HP was No. 2 with 3%, according to Dell'Oro.
"In many ways, they're viewed by the enterprise as that cool alternative vendor to Cisco," Kerravala says. "Cisco is the pervasive, de facto standard; Juniper tends to be the Mac, the cool, viable, technically superior alternative to Cisco."
Thursday, December 23, 2010
Project Stratus - Juniper lays out flat network roadmap
From its position in the switching trenches, Juniper Networks has planned not one, but two ways to flatten legacy three-tier data center networks.
Cisco vs. Juniper
Juniper calls its approach the 3-2-1 data center network architecture, promoting the idea that enterprises can cut one tier out of their data center networks today and, ultimately, another.
The result will be the flattest of all flat networks - a single layer operating as one giant switch.
Juniper shared that ultimate vision, called Project Stratus, almost two years ago, but products aren't expected till 2011.
A two-tier fabric
In the meantime, enterprise network planners who see value in a flatter architecture can take advantage of a two-tier fabric using Juniper's Virtual Chassis technology.
Applied at the access layer, Virtual Chassis technology allows up to 10 EX 4200 top-of-rack switches to operate and be managed as a single logical switch comprising hundreds - 480 in the case of the EX 4200 - of Gigabit Ethernet ports.
Juniper also will have Virtual Chassis technology available on the EX 4500, a 48-port 10G Ethernet switch that will be available later this year or early next, says Calvin Chai, a director of enterprise marketing at Juniper.
Enterprises can mix and match EX 4200 and 4500s, which also will support Converged Enhanced Ethernet and Fibre Channel over Ethernet (FCoE) for storage convergence, in the same Virtual Chassis fabric.
"You still have your physical devices, but instead of using the traditional chassis-based model with a single chassis sitting in a rack and slotting in modules for ports, you can have these one-rack unit servers distributed throughout the data center. You can extend the Virtual Chassis fabric across floors, buildings or in the same rack using fiber connections," says Chai, noting a distance limitation of 50 kilometers.
"And, you don't have to have 10 different uplinks from each of those switches. You just need one uplink because it behaves as one logical switch, so you're saving on port density and can collapse the core and aggregation layers - you simplify the network as you scale it up," he adds.
"Juniper does have this nice, interesting twist with how it's pulling off this two-tier architecture by making it look like one machine," says Robin Layland, head of Layland Consulting, which specializes in network architecture and strategy for enterprise customers.
A single network hop
Further reducing complexity and bolstering performance would come with even more streamlining of the data center network architecture, Chai says. Juniper hasn't disclosed Stratus project details, but the goal is to collapse to a single layer that will provide connectivity from any point to any other point in a data center with one processing hop, he says.
And don't be fooled by the "3-2-1" name, Chai says. Enterprises do not need to flatten the network progressively. An enterprise running a large three-tier data center network could go straight from there into a Stratus fabric, he says.
"I don't dare use the word 'FDDI,' but it does sound like Juniper is planning to interconnect all these machines together and, in effect, form a super bus loop over the data center. Data would travel around the bus until the right machine pulls it off," says Layland, referring to an obsolete token-based networking technology. "We definitely don't want to say 'FDDI,' but you can ask all the same sorts of questions and bring up the same issues using new terms if we're essentially talking about a ring architecture."
"One tier, two tier - are we talking 10-minute abs or seven-minute abs? It's really all up to the flexibility of the customer," says John Turner, director of networks and systems at Brandeis University, in Waltham, Mass., which is currently evaluating how best to handle a data center network refresh coming in 2011.
Juniper has made Brandeis' short list of choices, as has Cisco. But Turner says he's made no final decision on how best to flatten the network in support of increased virtualization. Storage convergence is on his mind, too, but not a burning issue at this point.
Cisco vs. Juniper
Juniper calls its approach the 3-2-1 data center network architecture, promoting the idea that enterprises can cut one tier out of their data center networks today and, ultimately, another.
The result will be the flattest of all flat networks - a single layer operating as one giant switch.
Juniper shared that ultimate vision, called Project Stratus, almost two years ago, but products aren't expected till 2011.
A two-tier fabric
In the meantime, enterprise network planners who see value in a flatter architecture can take advantage of a two-tier fabric using Juniper's Virtual Chassis technology.
Applied at the access layer, Virtual Chassis technology allows up to 10 EX 4200 top-of-rack switches to operate and be managed as a single logical switch comprising hundreds - 480 in the case of the EX 4200 - of Gigabit Ethernet ports.
Juniper also will have Virtual Chassis technology available on the EX 4500, a 48-port 10G Ethernet switch that will be available later this year or early next, says Calvin Chai, a director of enterprise marketing at Juniper.
Enterprises can mix and match EX 4200 and 4500s, which also will support Converged Enhanced Ethernet and Fibre Channel over Ethernet (FCoE) for storage convergence, in the same Virtual Chassis fabric.
"You still have your physical devices, but instead of using the traditional chassis-based model with a single chassis sitting in a rack and slotting in modules for ports, you can have these one-rack unit servers distributed throughout the data center. You can extend the Virtual Chassis fabric across floors, buildings or in the same rack using fiber connections," says Chai, noting a distance limitation of 50 kilometers.
"And, you don't have to have 10 different uplinks from each of those switches. You just need one uplink because it behaves as one logical switch, so you're saving on port density and can collapse the core and aggregation layers - you simplify the network as you scale it up," he adds.
"Juniper does have this nice, interesting twist with how it's pulling off this two-tier architecture by making it look like one machine," says Robin Layland, head of Layland Consulting, which specializes in network architecture and strategy for enterprise customers.
A single network hop
Further reducing complexity and bolstering performance would come with even more streamlining of the data center network architecture, Chai says. Juniper hasn't disclosed Stratus project details, but the goal is to collapse to a single layer that will provide connectivity from any point to any other point in a data center with one processing hop, he says.
And don't be fooled by the "3-2-1" name, Chai says. Enterprises do not need to flatten the network progressively. An enterprise running a large three-tier data center network could go straight from there into a Stratus fabric, he says.
"I don't dare use the word 'FDDI,' but it does sound like Juniper is planning to interconnect all these machines together and, in effect, form a super bus loop over the data center. Data would travel around the bus until the right machine pulls it off," says Layland, referring to an obsolete token-based networking technology. "We definitely don't want to say 'FDDI,' but you can ask all the same sorts of questions and bring up the same issues using new terms if we're essentially talking about a ring architecture."
"One tier, two tier - are we talking 10-minute abs or seven-minute abs? It's really all up to the flexibility of the customer," says John Turner, director of networks and systems at Brandeis University, in Waltham, Mass., which is currently evaluating how best to handle a data center network refresh coming in 2011.
Juniper has made Brandeis' short list of choices, as has Cisco. But Turner says he's made no final decision on how best to flatten the network in support of increased virtualization. Storage convergence is on his mind, too, but not a burning issue at this point.
Cisco/Juniper Commands
Part - 1
| Cisco Command | Juniper Command | Co-Ordinating Definition |
|---|---|---|
| show run | sh configuration | Show running configuration |
| sh ver | sh ver | Show version |
| show ip interface brief | show interface terse | displays the status of interfaces configured for IP |
| show interface [intfc] | show interfaces [intfc] detail | displays the interface configuration, status and statistics. |
| show controller intfc | show interfaces intfc extensive | displays information about a physical port device |
| show interface | incl (proto|Desc) | show interfaces description | displays the interface configuration, status and statistics |
| show ip route | show route | displays summary information about entries in the routing table |
| show ip bgp summary | show bgp summary | displays the status of all Border Gateway Protocol (BGP) connections |
| show ip bgp net mask | show route protocol bgp prefix | will show you how that route is being advertised, look for the first line |
| show ip bgp net mask longer-prefixes | show route range prefix | will show you how that route is being advertised, look for the first line |
| show ip bgp regexp AS-regexp | show route aspath-regexp "AS-regexp" | displays routes matching the autonomous system (AS) path regular expression |
| show ip bgp neighbors neigh received-routes | show route receive-protocol bgp neigh show route source-gateway neigh protocol bgp | Shows whether a neighbor supports the route refresh capability |
| show ip bgp neighbor neigh advertised-routes | show route advertising-protocol bgp neigh | Shows whether a neighbor supports the route refresh capabilty |
| show clns neighbors | show isis adjacency | displays both ES and IS neighbors |
| show clns interface | show isis interface | shows specific information about each interface |
| show ip route isis | show isis routes | displays the current state of the the routing table |
| show isis topology | show isis spf | displays a list of all connected routers in all areas |
| show ip ospf interface | show ospf neighbor | shows neighbor ID, Priority, IP, & State if the neighbor router, dead time. |
| show ip ospf interface | show ospf interface | shows neighbor id, pri, state, dead time, address and interface |
| show ip route ospf | show ospf route | display the current state of the routing table |
| show ip ospf database | show ospf database | display list of information related to the OSPF database for a specific communication server |
| show version | show version, show system uptime | display the system hardware config., software version, and name and source of configuration files and boot images |
| show diags | show chasis hardware | displays power-on diagnostics status |
| show processes cpu | show system process | displays utilization statistics |
| show tech-support | request support info | displays the current software image, configuration, controllers, counters, stacks, interfaces, memory and buffers |
| show logging | show log messages | display the state of logging to the syslog |
| show route-map name | show policy name | displayall route-maps configured or only the one specified |
| show ip prefix-list name | show policy name | display information about a prefix list or prefix list entries |
| show ip community-list list | configure, show policy-options community name | display routes that are permitted by BGP community list |
| show environment all | show chassis environment | displays temperature and voltage information on the console |
| ping dest | ping dest rapid (for cisco like output) ping dest (for unix like output) | to check to see if a destination is alive |
| ping (setting source int) | ping dest bypass-routing | to check to see if a destination is alive |
| terminal monitor | monitor start messages | Change console terminal settings |
| terminal no monitor | monitor stop | Change console terminal settings |
| terminal length 0 | set cli screen-length 0 | sets the length for displaying command output |
What are the config files and where are they located on a JUNOS router?
juniper.conf.gz
It is THE config. It is used for rollback 0.
Note that juniper.conf, juniper.conf.gz and juniper.conf.gz.jc
are morally equivalent.
Lives in: /config
juniper.db
This is the shared candidate database
Lives in: /var/run/db
juniper.data
This is the committed config database (i.e., the active configuration).
Lives in: /var/run/db
juniper.data+
A copy of the candidate db, used during commit check, and
during commit, becomes juniper.data if all is well.
Lives in: /var/run/db
juniper.conf+.gz
This is the candidate configuration and only exists during commit.
Lives in: /config
junper.save
juniper.data may contain the results of expanding groups and applying
transient changes from commit scripts, in either case, juniper.save
represents the committed db before those changes are applied.
This is needed for seeding private edit sessions and looking at the committed config without inheritance etc.
Lives in: /var/run/db
juniper.conf.1.gz through juniper.conf.3.gz
Rollback configurations 1 through 3.
Live in: /config
juniper.conf.4.gz through juniper.conf.49.gz
Rollback configurations 4 through 49.
Also, on JSeries at least the balance of configs in /config and
/var/db/config is configurable.
Live in: /var/db/config
rescue.conf.gz
A copy of a known good and working configuration that you can load in case of an emergency without having to remember which rollback number to use.
Lives in: /config
It is THE config. It is used for rollback 0.
Note that juniper.conf, juniper.conf.gz and juniper.conf.gz.jc
are morally equivalent.
Lives in: /config
juniper.db
This is the shared candidate database
Lives in: /var/run/db
juniper.data
This is the committed config database (i.e., the active configuration).
Lives in: /var/run/db
juniper.data+
A copy of the candidate db, used during commit check, and
during commit, becomes juniper.data if all is well.
Lives in: /var/run/db
juniper.conf+.gz
This is the candidate configuration and only exists during commit.
Lives in: /config
junper.save
juniper.data may contain the results of expanding groups and applying
transient changes from commit scripts, in either case, juniper.save
represents the committed db before those changes are applied.
This is needed for seeding private edit sessions and looking at the committed config without inheritance etc.
Lives in: /var/run/db
juniper.conf.1.gz through juniper.conf.3.gz
Rollback configurations 1 through 3.
Live in: /config
juniper.conf.4.gz through juniper.conf.49.gz
Rollback configurations 4 through 49.
Also, on JSeries at least the balance of configs in /config and
/var/db/config is configurable.
Live in: /var/db/config
rescue.conf.gz
A copy of a known good and working configuration that you can load in case of an emergency without having to remember which rollback number to use.
Lives in: /config
NetFlow or sFlow:
NetFlow or sFlow
Most Network Admins keep traffic analysis on the top ten of their responsibility list, but they aren’t using packet analyzers as much.
Why?
Because NetFlow and sFlow now provide the majority of the information they are generally looking for without deploying probes.
NetFlow?
sFlow?
What is the difference?
Most SNMP manageable switches and routers shipping today support either NetFlow or sFlow.
NetFlow or a derivative called NetStream, IPFIX or Jflow are more often supported on routers.
sFlow appears to be more popular on switches.
NetFlow
NetFlow developed by Cisco Systems aggregates conversations between hosts (i.e. flows) with potentially thousands of packets into a single entry among 29 other conversations in a single NetFlow v5 packet.
In other words, a single NetFlow packet can represent tens of thousands of packets between over two dozen hosts.
However the majority of the data field is lost in the aggregation.
The source and destination IP addresses, protocols, type, QoS, autonomous systems and a few other fields are all that are saved.
The rest of the packet is dumped in NetFlow v5 which is over 80% of the market.
NetFlow v9 can save the first 1200 bytes of the packet, however, few if any collectors can report on the data intuitively.
"The beauty of NetFlow is, because it is a standard, you can look at data from different vendors and still apply the correct level of forensics or traffic analysis to it," said Cliff Meltzer - Senior Vice President of the Cisco Network Management Technology Group.
SFlow
SFlow developed by InMon is a packet sampling technology where the switch captures every 100th packet (configurable) per interface and sends it off to the collector.
The sFlow specification does not preclude "sampling" every packet - this is a sampling rate of 1 in 1.
It is up to the specific chip vendor and specific sFlow implementation to limit the maximum frequency of packet sampling.
I am not aware of any vendor which will sample every packet.
Foundry Networks offers a switch which will sample every other packet.
Because of sFlows sampling nature, accurate readings of traffic volumes per hosts is nearly impossible without complicated algorithms which attempt to guess at accurate conversation byte volumes.
Unlike the normally software based architecture of NetFlow, sFlow requires a chip.
The sFlow.org consortium includes most of the leading network equipment and network traffic analysis vendors, who have contributed to the specification of the standard.
sFlow is licensed free of charge.
Unlike Flexible NetFlow which is limited to the first 1200 bytes of the sampled packet, with sFlow any amount of the sampled packet can be exported by sFlow, subject to any hardware limitations of a specific implementation.
Since sFlow runs over UDP, the UDP datagram can exceed the MTU of the layer 2 medium and the IP layer will handle any fragmentation and reassembly.
"By including sFlow technology in our wireless platform, we are making it easier for enterprises to monitor network devices, enforce security and analyze traffic flows across both a wired and wireless infrastructure," said Paul Congdon - Chief Technology Officer of ProCurve Networking by HP.
So which is the open standard: NetFlow or sFlow?
Both are open.
IPFIX is a flow standard which is based on NetFlow v9.
However, vendors have been slow to implement it.
Nortel supports IPFIX on their 5500 & 8600 series switches, however, they only support sampling (i.e. similar to sFlow).
Very important and definitely worth bringing to your attention again, the sFlow.org consortium includes most of the leading network equipment and network traffic analysis vendors.
These vendors have contributed to the specification of the standard. sFlow is licensed free of charge from InMon Corporation.
Among router vendors, NetFlow v5 appears to be more popular over sFlow.
Outside of Cisco and Enterasys, most switch vendors have implemented sFlow.
Enterasys supports NetFlow v9 on their switches because of a special chip they developed.
"The Enterasys Matrix N-Series switches collect NetFlow statistics for every packet in every flow without sacrificing performance based on the nTERA ASIC capabilities," said Trent Waterhouse - Marketing VP for Enterasys.
So which is better: NetFlow or sFlow?
In extremely high traffic volume environments, sFlow's sampling architecture probably prevails over NetFlows aggregation method.
The processing power to implement NetFlow on the routers and switches isn’t the problem.
The issue is the packet volume created by NetFlow which can be enormous and collectors can become overwhelmed.
Most routers outside of those used by service providers send between .5 to 50 NetFlow packets per second.
Although there are many routers in the world that will send over several hundred per second, they are not the norm.
Even so, some flow collectors can still handle 1000+ packets per second.
Why do most switch vendors support sFlow if it is only a sample, versus NetFlow's more accurate aggregation method for measuring IP traffic between hosts?
Well, since sFlow comes on a chip, one could be lead to believe it’s because sFlow takes less engineering to properly implement than NetFlow.
Note:-From Junos 9.5 you do not need a license or NetFlow (which is the same as J-Flow).
Most Network Admins keep traffic analysis on the top ten of their responsibility list, but they aren’t using packet analyzers as much.
Why?
Because NetFlow and sFlow now provide the majority of the information they are generally looking for without deploying probes.
NetFlow?
sFlow?
What is the difference?
Most SNMP manageable switches and routers shipping today support either NetFlow or sFlow.
NetFlow or a derivative called NetStream, IPFIX or Jflow are more often supported on routers.
sFlow appears to be more popular on switches.
NetFlow
NetFlow developed by Cisco Systems aggregates conversations between hosts (i.e. flows) with potentially thousands of packets into a single entry among 29 other conversations in a single NetFlow v5 packet.
In other words, a single NetFlow packet can represent tens of thousands of packets between over two dozen hosts.
However the majority of the data field is lost in the aggregation.
The source and destination IP addresses, protocols, type, QoS, autonomous systems and a few other fields are all that are saved.
The rest of the packet is dumped in NetFlow v5 which is over 80% of the market.
NetFlow v9 can save the first 1200 bytes of the packet, however, few if any collectors can report on the data intuitively.
"The beauty of NetFlow is, because it is a standard, you can look at data from different vendors and still apply the correct level of forensics or traffic analysis to it," said Cliff Meltzer - Senior Vice President of the Cisco Network Management Technology Group.
SFlow
SFlow developed by InMon is a packet sampling technology where the switch captures every 100th packet (configurable) per interface and sends it off to the collector.
The sFlow specification does not preclude "sampling" every packet - this is a sampling rate of 1 in 1.
It is up to the specific chip vendor and specific sFlow implementation to limit the maximum frequency of packet sampling.
I am not aware of any vendor which will sample every packet.
Foundry Networks offers a switch which will sample every other packet.
Because of sFlows sampling nature, accurate readings of traffic volumes per hosts is nearly impossible without complicated algorithms which attempt to guess at accurate conversation byte volumes.
Unlike the normally software based architecture of NetFlow, sFlow requires a chip.
The sFlow.org consortium includes most of the leading network equipment and network traffic analysis vendors, who have contributed to the specification of the standard.
sFlow is licensed free of charge.
Unlike Flexible NetFlow which is limited to the first 1200 bytes of the sampled packet, with sFlow any amount of the sampled packet can be exported by sFlow, subject to any hardware limitations of a specific implementation.
Since sFlow runs over UDP, the UDP datagram can exceed the MTU of the layer 2 medium and the IP layer will handle any fragmentation and reassembly.
"By including sFlow technology in our wireless platform, we are making it easier for enterprises to monitor network devices, enforce security and analyze traffic flows across both a wired and wireless infrastructure," said Paul Congdon - Chief Technology Officer of ProCurve Networking by HP.
So which is the open standard: NetFlow or sFlow?
Both are open.
IPFIX is a flow standard which is based on NetFlow v9.
However, vendors have been slow to implement it.
Nortel supports IPFIX on their 5500 & 8600 series switches, however, they only support sampling (i.e. similar to sFlow).
Very important and definitely worth bringing to your attention again, the sFlow.org consortium includes most of the leading network equipment and network traffic analysis vendors.
These vendors have contributed to the specification of the standard. sFlow is licensed free of charge from InMon Corporation.
Among router vendors, NetFlow v5 appears to be more popular over sFlow.
Outside of Cisco and Enterasys, most switch vendors have implemented sFlow.
Enterasys supports NetFlow v9 on their switches because of a special chip they developed.
"The Enterasys Matrix N-Series switches collect NetFlow statistics for every packet in every flow without sacrificing performance based on the nTERA ASIC capabilities," said Trent Waterhouse - Marketing VP for Enterasys.
So which is better: NetFlow or sFlow?
In extremely high traffic volume environments, sFlow's sampling architecture probably prevails over NetFlows aggregation method.
The processing power to implement NetFlow on the routers and switches isn’t the problem.
The issue is the packet volume created by NetFlow which can be enormous and collectors can become overwhelmed.
Most routers outside of those used by service providers send between .5 to 50 NetFlow packets per second.
Although there are many routers in the world that will send over several hundred per second, they are not the norm.
Even so, some flow collectors can still handle 1000+ packets per second.
Why do most switch vendors support sFlow if it is only a sample, versus NetFlow's more accurate aggregation method for measuring IP traffic between hosts?
Well, since sFlow comes on a chip, one could be lead to believe it’s because sFlow takes less engineering to properly implement than NetFlow.
Note:-From Junos 9.5 you do not need a license or NetFlow (which is the same as J-Flow).
Difference between logical router and virtual router?
Difference between logical router and virtual router?
- Logical router (called now logical system ... from 9.3) and virtual router exists in M and T series.
- In J series you only have virtual routers.
The main difference between them is that logical router configuration activate a new routing deamon in the router, birual router doesn't. Saying that if you activate a logical router that have a problem , if it crashes , there will be no impact on the other ones (the main one ... regular config, or others logical routers.
The other difference is in the way to configure them.
The logical router is configured exactly like the main router but under the [edit logical-systems Name] logical interfaces included.
The virtual router is configured under [edit routing-instances Name] you add a ref to the interfaces ther but the logical configuration of the interfaces itself is done under the main router.
You can find two different examples there:
- In J series you only have virtual routers.
The main difference between them is that logical router configuration activate a new routing deamon in the router, birual router doesn't. Saying that if you activate a logical router that have a problem , if it crashes , there will be no impact on the other ones (the main one ... regular config, or others logical routers.
The other difference is in the way to configure them.
The logical router is configured exactly like the main router but under the [edit logical-systems Name] logical interfaces included.
The virtual router is configured under [edit routing-instances Name] you add a ref to the interfaces ther but the logical configuration of the interfaces itself is done under the main router.
You can find two different examples there:
Routing-instance:
You can do a configuration this way with routing-instances on a Jseries router:
# Config Base 2 router's in point to point#
# WAN Addresses in 10.0.0.X/30
#
# .1 id1 .2
# R1--------------------R2
#
#
# OSPF enabled on all interfaces
# Loopback address respectively on router's R1, R2
# in 1.1.1.1, 2.2.2.2
#
set interfaces ge-0/0/0 vlan-tagging
set interfaces ge-0/0/0 unit 0 vlan-id 1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 0 vlan-id 1
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 1 family inet address 1.1.1.1/32
set interfaces lo0 unit 2 family inet address 2.2.2.2/32
set routing-instances R1 instance-type virtual-router
set routing-instances R1 interface ge-0/0/0.0
set routing-instances R1 interface lo0.1
set routing-instances R1 protocols ospf area 0.0.0.0 interface all
set routing-instances R2 instance-type virtual-router
set routing-instances R2 interface ge-0/0/1.0
set routing-instances R2 interface lo0.2
set routing-instances R2 protocols ospf area 0.0.0.0 interface all
# Config Base 2 router's in point to point#
# WAN Addresses in 10.0.0.X/30
#
# .1 id1 .2
# R1--------------------R2
#
#
# OSPF enabled on all interfaces
# Loopback address respectively on router's R1, R2
# in 1.1.1.1, 2.2.2.2
#
set interfaces ge-0/0/0 vlan-tagging
set interfaces ge-0/0/0 unit 0 vlan-id 1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30
set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 0 vlan-id 1
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.2/30
set interfaces lo0 unit 1 family inet address 1.1.1.1/32
set interfaces lo0 unit 2 family inet address 2.2.2.2/32
set routing-instances R1 instance-type virtual-router
set routing-instances R1 interface ge-0/0/0.0
set routing-instances R1 interface lo0.1
set routing-instances R1 protocols ospf area 0.0.0.0 interface all
set routing-instances R2 instance-type virtual-router
set routing-instances R2 interface ge-0/0/1.0
set routing-instances R2 interface lo0.2
set routing-instances R2 protocols ospf area 0.0.0.0 interface all
Logical-router:
But in this case the guy who did this used an ASPIC card to interconnect the logical routers !
You can do it without ASPIC but with just two interfaces plugged "back to back"
Here is an other sample example with the drawing:
fe-1/3/0 and fe-1/3/1 plugged together
# Config Base 4 router's in square
#
# Adresses WAN in 10.0.0.X/30
#
# .1 id1 .2
# R1--------------------R2
# | |
# .14| |.5
# | |
# id4 | | id2
# | |
# | |
# .13| |.6
# | |
# R4--------------------R3
# .10 id3 .9
#
#
# OSPF enabled on all interfaces
# Loopback address respectively on router's R1, R2, R3, R4
# in 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4
#
set logical-routers R1 interfaces fe-1/3/0 unit 1 vlan-id 1
set logical-routers R1 interfaces fe-1/3/0 unit 1 family inet address 10.0.0.1/30
set logical-routers R1 interfaces fe-1/3/1 unit 4 vlan-id 4
set logical-routers R1 interfaces fe-1/3/1 unit 4 family inet address 10.0.0.14/30
set logical-routers R1 interfaces lo0 unit 1 family inet address 1.1.1.1/32
set logical-routers R1 protocols ospf area 0.0.0.0 interface all
set logical-routers R2 interfaces fe-1/3/0 unit 2 vlan-id 2
set logical-routers R2 interfaces fe-1/3/0 unit 2 family inet address 10.0.0.5/30
set logical-routers R2 interfaces fe-1/3/1 unit 1 vlan-id 1
set logical-routers R2 interfaces fe-1/3/1 unit 1 family inet address 10.0.0.2/30
set logical-routers R2 interfaces lo0 unit 2 family inet address 2.2.2.2/32
set logical-routers R2 protocols ospf area 0.0.0.0 interface all
set logical-routers R3 interfaces fe-1/3/0 unit 3 vlan-id 3
set logical-routers R3 interfaces fe-1/3/0 unit 3 family inet address 10.0.0.9/30
set logical-routers R3 interfaces fe-1/3/1 unit 2 vlan-id 2
set logical-routers R3 interfaces fe-1/3/1 unit 2 family inet address 10.0.0.6/30
set logical-routers R3 interfaces lo0 unit 3 family inet address 3.3.3.3/32
set logical-routers R3 protocols ospf area 0.0.0.0 interface all
set logical-routers R4 interfaces fe-1/3/0 unit 4 vlan-id 4
set logical-routers R4 interfaces fe-1/3/0 unit 4 family inet address 10.0.0.13/30
set logical-routers R4 interfaces fe-1/3/1 unit 3 vlan-id 3
set logical-routers R4 interfaces fe-1/3/1 unit 3 family inet address 10.0.0.10/30
set logical-routers R4 interfaces lo0 unit 4 family inet address 4.4.4.4/32
set logical-routers R4 protocols ospf area 0.0.0.0 interface all
set interfaces fxp0 unit 0 family inet address 192.168.63.7/24
set interfaces fe-1/3/0 vlan-tagging
set interfaces fe-1/3/1 vlan-tagging
Additional Notes
Think of logical routers as a super-set of a virtual router. ie: You can run routing-instances in each logical router.In general, most tasks are efficiently handled by routing-instances (virtual routers) in JUNOS.
However, LRs add a couple features:
Note:Both LR and routing-instances have exactly the same hardware separation at the data-plane, the difference is 100% control plane. Both LR and VR share the same FIB resources, so a LR will not help control scalability of the number of prefixes or next-hops in hardware.
LR offers:
- a separate copy of RPD, so if there is an issue in one LR, the RPD in another is not affected (process separation)
- CLI partition with user access control: a LR has a different hierarchy in the CLI, and you can restrict users to one or another
- MPLS core protocol separation requires an LR, not just a routing-instance. If you want one Juniper router to behave as two MPLS nodes (ie: separate P and PE functions between two routers), you will need logical routers
LR need-to-know:
- Logical routers are only supported on the M/T/MX series. You cannot use an LR in the J series. I'm also not sure if it's fully supported in the SRX series currently.
- JUNOS feature support in LRs versus the root routing instance is not 100%. There are some things that aren't supported in an LR context. Although this has been a strong focus of development recently, so the gap is narrowing with many releases
- JUNOS requires you to /purchase/ a logical-router right-to-use license per chassis.
* routing-instances are free in JUNOS, logical routers are /NOT/
Also, it's worth pointing out that earlier this year, Juniper renamed the "Logical Router" to the "Logical System" in JUNOS. It's the same feature, but the name has been expanded to support JUNOS devices that aren't necessarily "routers" (such as the EX series, SRX, etc).
Finally, there is a third form of system virtualization called the Hardware Logical Router, or "Protected System Domain". This is something that is only supported on the T series currently, and requires an external control plane chassis called the JCS, or "Juniper Control System". This allows for both data-plane and control-plane separation between logical routers, and also dedicates a separate routing-engine (CPU complex, route-processor) for each protected system domain (PSD). One of the biggest advantages of a PSD is that each PSD has its own scaling numbers, and is also a descrete maintenance domain. For instance, you can upgrade the version of JUNOS in one PSD, while the other PSDs remain unaffected (this includes updating the firmware on the associated linecards and PICs).
In terms of applications:
Simple routing-instances (virtual routers) are normally used for most tasks when you need to separate routing, such as MPLS L3VPN (private IP services), or simply mutiple route table support (what cisco calls VRF-lite, or Multi-VRF).
Logical routers are normally used when you are taking the functions of two descrete routers, and collapsing them into a single chassis. Think of a provider PoP where you may have one pair of routers for external peering, and another pair of routers for backbone connectivity to the provider's core network. In this case, you could leverage the Logical Router (aka: Logical System) support to make one instance of an internal core router and one instance of an edge peering router in the same chassis. The advantage is that they are still run as two separate processes and can have different user permissions.
You can do it without ASPIC but with just two interfaces plugged "back to back"
Here is an other sample example with the drawing:
fe-1/3/0 and fe-1/3/1 plugged together
# Config Base 4 router's in square
#
# Adresses WAN in 10.0.0.X/30
#
# .1 id1 .2
# R1--------------------R2
# | |
# .14| |.5
# | |
# id4 | | id2
# | |
# | |
# .13| |.6
# | |
# R4--------------------R3
# .10 id3 .9
#
#
# OSPF enabled on all interfaces
# Loopback address respectively on router's R1, R2, R3, R4
# in 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4
#
set logical-routers R1 interfaces fe-1/3/0 unit 1 vlan-id 1
set logical-routers R1 interfaces fe-1/3/0 unit 1 family inet address 10.0.0.1/30
set logical-routers R1 interfaces fe-1/3/1 unit 4 vlan-id 4
set logical-routers R1 interfaces fe-1/3/1 unit 4 family inet address 10.0.0.14/30
set logical-routers R1 interfaces lo0 unit 1 family inet address 1.1.1.1/32
set logical-routers R1 protocols ospf area 0.0.0.0 interface all
set logical-routers R2 interfaces fe-1/3/0 unit 2 vlan-id 2
set logical-routers R2 interfaces fe-1/3/0 unit 2 family inet address 10.0.0.5/30
set logical-routers R2 interfaces fe-1/3/1 unit 1 vlan-id 1
set logical-routers R2 interfaces fe-1/3/1 unit 1 family inet address 10.0.0.2/30
set logical-routers R2 interfaces lo0 unit 2 family inet address 2.2.2.2/32
set logical-routers R2 protocols ospf area 0.0.0.0 interface all
set logical-routers R3 interfaces fe-1/3/0 unit 3 vlan-id 3
set logical-routers R3 interfaces fe-1/3/0 unit 3 family inet address 10.0.0.9/30
set logical-routers R3 interfaces fe-1/3/1 unit 2 vlan-id 2
set logical-routers R3 interfaces fe-1/3/1 unit 2 family inet address 10.0.0.6/30
set logical-routers R3 interfaces lo0 unit 3 family inet address 3.3.3.3/32
set logical-routers R3 protocols ospf area 0.0.0.0 interface all
set logical-routers R4 interfaces fe-1/3/0 unit 4 vlan-id 4
set logical-routers R4 interfaces fe-1/3/0 unit 4 family inet address 10.0.0.13/30
set logical-routers R4 interfaces fe-1/3/1 unit 3 vlan-id 3
set logical-routers R4 interfaces fe-1/3/1 unit 3 family inet address 10.0.0.10/30
set logical-routers R4 interfaces lo0 unit 4 family inet address 4.4.4.4/32
set logical-routers R4 protocols ospf area 0.0.0.0 interface all
set interfaces fxp0 unit 0 family inet address 192.168.63.7/24
set interfaces fe-1/3/0 vlan-tagging
set interfaces fe-1/3/1 vlan-tagging
Additional Notes
Think of logical routers as a super-set of a virtual router. ie: You can run routing-instances in each logical router.In general, most tasks are efficiently handled by routing-instances (virtual routers) in JUNOS.
However, LRs add a couple features:
Note:Both LR and routing-instances have exactly the same hardware separation at the data-plane, the difference is 100% control plane. Both LR and VR share the same FIB resources, so a LR will not help control scalability of the number of prefixes or next-hops in hardware.
LR offers:
- a separate copy of RPD, so if there is an issue in one LR, the RPD in another is not affected (process separation)
- CLI partition with user access control: a LR has a different hierarchy in the CLI, and you can restrict users to one or another
- MPLS core protocol separation requires an LR, not just a routing-instance. If you want one Juniper router to behave as two MPLS nodes (ie: separate P and PE functions between two routers), you will need logical routers
LR need-to-know:
- Logical routers are only supported on the M/T/MX series. You cannot use an LR in the J series. I'm also not sure if it's fully supported in the SRX series currently.
- JUNOS feature support in LRs versus the root routing instance is not 100%. There are some things that aren't supported in an LR context. Although this has been a strong focus of development recently, so the gap is narrowing with many releases
- JUNOS requires you to /purchase/ a logical-router right-to-use license per chassis.
* routing-instances are free in JUNOS, logical routers are /NOT/
Also, it's worth pointing out that earlier this year, Juniper renamed the "Logical Router" to the "Logical System" in JUNOS. It's the same feature, but the name has been expanded to support JUNOS devices that aren't necessarily "routers" (such as the EX series, SRX, etc).
Finally, there is a third form of system virtualization called the Hardware Logical Router, or "Protected System Domain". This is something that is only supported on the T series currently, and requires an external control plane chassis called the JCS, or "Juniper Control System". This allows for both data-plane and control-plane separation between logical routers, and also dedicates a separate routing-engine (CPU complex, route-processor) for each protected system domain (PSD). One of the biggest advantages of a PSD is that each PSD has its own scaling numbers, and is also a descrete maintenance domain. For instance, you can upgrade the version of JUNOS in one PSD, while the other PSDs remain unaffected (this includes updating the firmware on the associated linecards and PICs).
In terms of applications:
Simple routing-instances (virtual routers) are normally used for most tasks when you need to separate routing, such as MPLS L3VPN (private IP services), or simply mutiple route table support (what cisco calls VRF-lite, or Multi-VRF).
Logical routers are normally used when you are taking the functions of two descrete routers, and collapsing them into a single chassis. Think of a provider PoP where you may have one pair of routers for external peering, and another pair of routers for backbone connectivity to the provider's core network. In this case, you could leverage the Logical Router (aka: Logical System) support to make one instance of an internal core router and one instance of an edge peering router in the same chassis. The advantage is that they are still run as two separate processes and can have different user permissions.
Monday, May 31, 2010
Silly Mistakes in Network documentations
Whats the Difference Between Kbps and kBps ?
There is a big difference between 56 kbps or 56 kBps. If you are writing a technical paper and you are a programmer from SAP, make sure you get it right because the difference between bits and bytes is huge.
The correct convention is to use a small “b” for bits, and capital “B” for bytes and there are eight bits to a byte.
There is a big difference between 56 kbps or 56 kBps. If you are writing a technical paper and you are a programmer from SAP, make sure you get it right because the difference between bits and bytes is huge.
The correct convention is to use a small “b” for bits, and capital “B” for bytes and there are eight bits to a byte.
56 kbps = 56000 bits per second56 kBps = 8 * 56000 = 448000 bits per second