http://www.mellanox.com/
12/02/2012
11/25/2012
Examples: Configuring PIM RPT and SPT Cutover
reminder to read this article:
http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-pim-rpt-spt-cutover.html
10/27/2012
IPv6 on LT interfaces
I got this strange behaviour where the IPv6 doesn't work correctly or not working at all on LT interfaces.
http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/logical-systems-restrictions.html
Logical systems have the following operations and restrictions:
* You can configure only Frame Relay interface encapsulation on a logical tunnel interface (lt-) when it is configured with an IPv6 address.
So if you are using Logical Systems on Juniper and you have to do IPv6 labs avoid encapsulation ethernet.
Example
root@jnlab# show
interfaces {
lt-2/2/0 {
unit 46 {
encapsulation frame-relay;
dlci 100;
peer-unit 45;
family inet {
address 172.27.0.58/30;
}
family inet6 {
address 2008:4489:0:0::1/64;
}
}
}
}
root@jnlab# run ping 2008:4489::2 logical-system c1
PING6(56=40+8+8 bytes) 2008:4489::1 --> 2008:4489::2
16 bytes from 2008:4489::2, icmp_seq=0 hlim=64 time=0.427 ms
16 bytes from 2008:4489::2, icmp_seq=1 hlim=64 time=0.281 ms
^C
--- 2008:4489::2 ping6 statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.281/0.354/0.427/0.073 ms
http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/logical-systems-restrictions.html
Logical systems have the following operations and restrictions:
* You can configure only Frame Relay interface encapsulation on a logical tunnel interface (lt-) when it is configured with an IPv6 address.
So if you are using Logical Systems on Juniper and you have to do IPv6 labs avoid encapsulation ethernet.
Example
root@jnlab# show
interfaces {
lt-2/2/0 {
unit 46 {
encapsulation frame-relay;
dlci 100;
peer-unit 45;
family inet {
address 172.27.0.58/30;
}
family inet6 {
address 2008:4489:0:0::1/64;
}
}
}
}
root@jnlab# run ping 2008:4489::2 logical-system c1
PING6(56=40+8+8 bytes) 2008:4489::1 --> 2008:4489::2
16 bytes from 2008:4489::2, icmp_seq=0 hlim=64 time=0.427 ms
16 bytes from 2008:4489::2, icmp_seq=1 hlim=64 time=0.281 ms
^C
--- 2008:4489::2 ping6 statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.281/0.354/0.427/0.073 ms
10/22/2012
IGP-TE
Configuring Node-Link Protection for OSPF
You can configure node-link protection on any interface for which OSPF is enabled. Node-link protection establishes an alternate path through a different routing device altogether for all destination routes that traverse a protected interface. Node-link protection assumes that the entire routing device, or node, has failed. The Junos OS therefore calculates a backup path that avoids the primary next-hop routing device.
Node-link protection is supported on:
- OSPFv2 and OSPFv3 interfaces
- OSPFv3 unicast realms
- OSPFv2 unicast topologies
- All routing instances supported by OSPFv2 and OSPFv3
- Logical systems
To configure node-link protection for an OSPF interface:
- Include the node-link-protection statement at the [edit protocols (ospf | ospf3) area area-idinterface interface-name] hierarchy level.
Best Practice: You must also configure a per-packet load-balancing routing policy to ensure that the routing protocol process installs all the next hops for a given route in the routing table.
|
In the following example, the OSPF interface so-0/0/0.0 in area 0.0.0.0 is configured for node-link protection. If a link for a destination route that traverses this interface becomes unavailable, the Junos OS creates a loop-free backup path through a different routing device altogether, thus avoiding the primary next-hop routing device.
[edit]protocols {ospf {area 0.0.0.0 {interface so-0/0/0.0 {node-link-protection;}}}}
Freenode
IRC Freenode is something really useful. It's amazing that people still prefer to use a real-time chat services rather than forums and mailing lists.
10/16/2012
JunOS Conditional routing
It's really lovely how straight-forward the JunOS conditional routing is. There is a quick example how to configure it. In the example we are monitoring the IS-IS route 172.27.255.2/32 and if it's in the routing table we will generate 172.27.0.0/16 route. The important bit here is the generate route and the policy which is in the end of the 'generate route' statement.
[edit logical-systems r1 routing-options]
root@m# show
generate {
route 172.27.0.0/16 policy isis-present;
root@m# show
generate {
route 172.27.0.0/16 policy isis-present;
}
policy-statement isis-present {
term 1 {
from {
protocol isis;
level 1;
route-filter 172.27.255.2/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
policy-statement isis-present {
term 1 {
from {
protocol isis;
level 1;
route-filter 172.27.255.2/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
Juniper IS-IS summary
- #####################################################################################################
- ## ISIS
- #####################################################################################################
- # Be sure to set family iso on the interface to be placed into ISIS
- set interfaces <interface> family iso
- # By default Junos places interfaces as L1/L2
- # Default route leaking:
- L1 to L2 - all internal routes
- L2 to L1 - 0/0 route
- # L1/L2 will send the attached-bit down to L1 and it will act as a NSSA-like area. When the L1 interface
- # receives the attached-bit it will inject a 0/0 route into the RIB point to the L1/L2 interface.
- # To disable the attached bit use:
- set protocols isis ignore-attached-bit
- # Be careful with the "interface all" command, as it may have some unexpected consequences such as trying
- # to establish a neighbor on your fxp0 management interface. Use explicit interface names. If you must
- # use the "interface all" command, remember that if you also define another explicit interface such as
- # "interface ge-0/0/0.0 <options>" that it _doesn't_ inherit the "interface all" options.
- # ALWAYS include the interface lo0.0
- # L2 backbone must be contiguous.
- # Human-readable hostnames via TLV 137. Good to quickly verify that the router has the proper adjcancies .
- show isis hostname
- # Set LSP authentication (per area knob)
- set protocols isis level <level> authentication-type (simple|md5)
- set protocols isis level <level> authentication-key <key>
- # Set hello authentication (per interface knob)
- set protocols isis interface <interface> hello-authentication-type (simple|md5)
- set protocols isis interface <interface> hello-authentication-key <key>
- # Set lsp-interval
- set interfaces ge-0/0/0.0 lsp-interval <milliseconds>
- # L2 to L1 route summarization
- ## set aggregate route in routing-options
- set routing-options aggregate route 10/8
- ## set policy-options - what prefix to match
- set policy-options policy-statement isis-export term 1 from protocol aggregate route-filter 10/8 exact
- ## set policy-options - what level to go _to_
- set policy-options policy-statement isis-export term 1 to level 1
- ## set action
- set policy-options policy-statement isis-export term 1 then accept
- # L1 to L2 route summarization
- ## set aggregate route in routing-options
- set routing-optiong aggregate route 10/8
- ## set policy-options
- ### match exact route
- set policy-options policy-statement isis-export term 1 from protocol aggregate router-filter 10/8 exact
- ## set policy-options - what level to go _to_
- set policy-options policy-statement isis-export term 1 to level 2
- ## set action
- set policy-options policy-statement isis-export term 1 then accept
- ### suppress more specific routes (to prevent advertisements of both aggregate and more specific routes)
- set policy-options policy-statement isis-export term 2 from protocol isis
- set policy-options policy-statement isis-export term 2 from level 1
- set policy-options policy-statement isis-export term 2 to level 2
- ## set action
- set policy-options policy-statement isis-export term 2 then reject
- # Verify that a route is internal or external
- show route protocol isis <prefix> exact
- show isis database <sysid> detail
- # When using wide-metrics-only it makes the route internal. When there is a situtation where the L1 routers
- # are wide-metrics-only and are exporting external routes into the L1 area, they will appear as internal
- # routes. Also if there are any L1/L2 routers in the area that exported prefix will be automatically
- # redistributed from L1 into L2 because it's showing as an internal route. If narrow-metrics were used, the
- # L1/L2 routers would have to have an export policy to redistributed the prefix from L1 to L2.
- # Set DIS priority
- set protocols isis interface <interface> level <level> priority <level>
- ## Remember that the highest MAC address is the tie-breaker if the priorities are equal
- ## view current DIS
- show isis interface
9/30/2012
Service Provider Workbook from Inet Zero
I just purchased the new Service Provider workbook from InetZero and I hope it's worthy the price of 300GBP
Cisco - Steps to Success
Steps to Success provides engagement and deployment methodologies, best practices, and technical resources that enable you to sell, deliver, and support Cisco Advanced Technology solutions.
- Increase productivity by following methodologies and reusing content
- Reduce costs and streamline your deployment cycles
- Improve profitability by leveraging industry best practices throughout your engagements
- Develop and grow your service practices and offerings to meet your customers' needs
http://www.cisco.com/web/partners/tools/steps-to-success/index.html
8/27/2012
Buffer Requirements for High-Speed Routers
Nice article by Damon Wischik
1. Introduction
Today, the buffer size in core Internet routers is
typically chosen according to a rule of thumb which
says: provide at least one round trip time's worth of
buffering. The round trip time is often taken to be
around 250ms (it takes 134ms to send a packet half
way round the world and back, but queueing delay
may plausibly add 100ms). A 40Gb/s linecard
therefore needs 1.25GByte of memory.
Such large memories are hard to build in electronics.
(The problem is that data can arrive at line rate, so
the memory needs to be writeable at line rate. Such a
high memory bandwidth is hard to engineer—and
DRAM access speeds increases at only 7.5% a year
[6].) Such large memories are also wildly impractical
for any all-optical router that we can conceive of
today.
Recent theoretical work has challenged the rule of
thumb: it seems that a buffer of just 20 packets
should be sufficient. The modeling behind this deals
with TCP's algorithm for congestion control, with very
short-timescale traffic statistics, and with queueing
theory for Poisson traffic. (Long-range dependence
has no bearing on buffer size.) This article outlines
the theory.
Practical work has also challenged the rule of thumb.
A measurement study of a Sprint backbone router [1]
found that the queue size hardly ever exceeded 10
packets! (perhaps not surprising given that Sprint
aims to keep utilization below 20%). Preliminary
experiments on working routers [15] suggest that
buffers can be much smaller than they are now,
though the experimentation does not yet make clear
quite how much.
Small buffers have obvious practical benefits. In an
electronic router, the buffer could be on-chip, giving
much higher memory bandwidth. In an all-optical
router, 20-packet buffers might become feasible in the
coming few years.
more on the link
1. Introduction
Today, the buffer size in core Internet routers is
typically chosen according to a rule of thumb which
says: provide at least one round trip time's worth of
buffering. The round trip time is often taken to be
around 250ms (it takes 134ms to send a packet half
way round the world and back, but queueing delay
may plausibly add 100ms). A 40Gb/s linecard
therefore needs 1.25GByte of memory.
Such large memories are hard to build in electronics.
(The problem is that data can arrive at line rate, so
the memory needs to be writeable at line rate. Such a
high memory bandwidth is hard to engineer—and
DRAM access speeds increases at only 7.5% a year
[6].) Such large memories are also wildly impractical
for any all-optical router that we can conceive of
today.
Recent theoretical work has challenged the rule of
thumb: it seems that a buffer of just 20 packets
should be sufficient. The modeling behind this deals
with TCP's algorithm for congestion control, with very
short-timescale traffic statistics, and with queueing
theory for Poisson traffic. (Long-range dependence
has no bearing on buffer size.) This article outlines
the theory.
Practical work has also challenged the rule of thumb.
A measurement study of a Sprint backbone router [1]
found that the queue size hardly ever exceeded 10
packets! (perhaps not surprising given that Sprint
aims to keep utilization below 20%). Preliminary
experiments on working routers [15] suggest that
buffers can be much smaller than they are now,
though the experimentation does not yet make clear
quite how much.
Small buffers have obvious practical benefits. In an
electronic router, the buffer could be on-chip, giving
much higher memory bandwidth. In an all-optical
router, 20-packet buffers might become feasible in the
coming few years.
more on the link
7/02/2012
6/29/2012
6/28/2012
6/18/2012
Will Miss You
It's always bad when you lose someone close.
This is my grandma. She past away Today (18/06/2012). She was one of the most amazing people in my life.
6/15/2012
detailed topic list
This are just a topics I need to start building lab scenarios for. If you read this BLOG - please ignore that bit.
- Device Administration
- Class of Service
- Open Shortest Path First (OSPF)
- Intermediate System to Intermediate System (IS-IS)
- IPv6
- Border Gateway Protocol (BGP)
- Multicast in the provider core
- Multi-Protocol Label Switching (MPLS)
- Layer 3 VPNs
- Layer 2 VPNs
- Virtual Private LAN Switching (VPLS)
- Next generation multicast VPNs (NG-MVPN)
OSPF
- Describe the concepts, operation and functionality of OSPF
- Various OSPF LSA types
- Flooding of LSAs in an OSPF network
- SPF algorithm
- OSPF metrics, including external metric types
- OSPF authentication options
- OSPF area types and operations, including stub areas and NSSAs
- Summarize and restrict routes
- Purpose of virtual links
- Key differences between OSPFv2 and OSPFv3
- Demonstrate knowledge of how to configure and monitor single-area and multi-area OSPF
- Implement OSPF routing policy
IS-IS
- Describe the concepts, operation and functionality of IS-IS
- Various IS-IS link-state PDU (LSP) types
- IS-IS adjacency rules
- Interpret the LSDB
- IS-IS metrics, including wide metrics
- IS-IS authentication options
- Default operation in multi-area IS-IS
- IS-IS route summarization and route leaking methods
- Demonstrate knowledge of how to configure and monitor single-area and multi-area IS-IS
- Implement IS-IS routing policy
BGP
- Describe the concepts, operation and functionality of BGP
- BGP route selection process
- How to alter the route selection process
- Various BGP attributes and explain the operation of those attributes
- Purpose and function of BGP communities
- Utilize regular expressions for route selection
- Describe, configure and monitor BGP route damping
- Manipulate BGP attributes using routing policy
- Multiprotocol BGP
- Demonstrate knowledge of how to configure and monitor BGP
- Implement BGP routing policy
- Describe and configure BGP scaling mechanisms, including route reflection and confederations
Class of Service (CoS)
- Describe the concepts, operation and functionality of Junos CoS
- Purpose of forwarding classes
- Function and types of packet classification
- Function and types of policers
- Function and interrelationships of the components of scheduling
- Purpose of hierarchical scheduling (H-CoS), and describe the characteristics of the four levels of H-CoS (high-level only)
- Characteristics of Differentiated Services
- Common per-hop behaviors (PHBs)
- Describe the CoS fields in various packet headers
- List the CoS processing stages on devices running Junos OS
- Function of rewriting packet headers
- Demonstrate knowledge of how to configure the various CoS components, including forwarding classes, classifiers, policers, schedulers, and rewrite rules
- Describe and configure CoS-based forwarding (CBF)
- Describe how to monitor CoS using various operational commands
IP Multicast
- Describe the concepts, operation and functionality of IP multicast
- IP multicast traffic flow
- Components of IP multicast, including multicast addressing
- Function of RPF in multicast
- Demonstrate knowledge of the components and function of common multicast routing protocols
- Function of IGMP and compare the various IGMP versions
- Compare PIM dense-mode and sparse-mode
- Various rendezvous point (RP) discovery options
- Compare Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
- Requirements, benefits, and address ranges used for SSM
- Purpose and operation of MSDP within a single PIM domain and across multiple PIM domains
- Function and benefit of using Anycast RP
- Use of routing policies to control PIM and MSDP message traffic and to scope multicast groups
- Demonstrate knowledge of how to configure and monitor IGMP, PIM-DM, PIM-SM (including SSM) and MSDP
- Implement IP multicast routing policy
MPLS
- Describe the concepts, operation and functionality of MPLS
- Common MPLS terms
- How a router forwards MPLS packets
- MPLS packet flow from an ingress node to an egress node
- Examine the Label Information Base
- Functionality of the two common label distribution protocols used by the Junos OS
- LSP metrics, including interaction with IGP metrics
- Default traffic protection behavior of RSVP-signaled LSPs
- Compare primary and secondary LSPs
- Function and interrelationship of LSP priority and preemption
- Compare the operation of fast reroute, link protection and node protection
- LSP optimization options
- Routing table integration options for traffic engineering
- Use of routing policies to control path selection
- Additional MPLS features, such as automatic bandwidth, TTL handling, and MPLS pings
- Describe the concepts, operation and functionality of Constrained Shortest Path First (CSPF)
- IGP extensions needed to build and maintain a traffic engineering database (TED)
- How the CSPF algorithm selects the best path
- Purpose of administrative groups
- Demonstrate knowledge of how to configure and monitor MPLS, LDP and RSVP
- Configure a router to perform MPLS forwarding
- Configure RSVP-signaled and LDP-signaled LSPs
- Implement MPLS routing policy
- Configure traffic protection mechanisms
- Configure the components of CSPF
Layer 3 VPNs
- Describe the concepts, operation and functionality of L3 VPNs
- Roles of P, PE, and CE routers
- Format of VPN-IPv4 addresses
- Function of a route distinguisher
- Operation and flow of the control and data planes
- Various L3 VPN CoS mechanisms
- How to support communications between sites attached to a common PE router
- Benefits and requirements of using a hub-and-spoke topology
- Methods to scale L3 VPNs
- Compare L3 VPN Internet access options
- Demonstrate knowledge of how to configure, monitor and troubleshoot L3 VPNs
- Demonstrate knowledge of the operation and configuration of multicast VPNs
- Concepts, operation and functionality of next-generation MVPNs (NG-MVPN)
- Flow of control and data traffic in a NG-MVPN
- Configure and monitor NG-MVPNs
- Describe Junos support for carrier of carrier and interprovider VPN models
Layer 2 VPNs
- Describe the concepts, operation and functionality of BGP L2 VPNs
- Roles of a CE, PE, and P router in an L2 VPN
- Flow of control and data traffic for a BGP L2 VPN
- Benefits and requirements of over-provisioning
- Methods to scale BGP L2 VPNs
- Various BGP L2 VPN CoS mechanisms
- Describe the concepts, operation and functionality of LDP L2 circuits
- Flow of control and data traffic for an LDP L2 circuit
- Describe the concepts, operation and functionality of VPLS
- Purpose of the PE, CE, and P devices
- Signaling, learning and forwarding process of VPLS
- Demonstrate knowledge of how to configure, monitor and troubleshoot L2 VPNs
- Configure, monitor and troubleshoot BGP L2 VPNs
- Configure, monitor and troubleshoot LDP L2 circuits
- Configure, monitor and troubleshoot VPLS
Automation
- Demonstrate basic knowledge of using automation scripts
6/13/2012
JNxNS
The next step is to bring the virtual-routers and do something useful with these two gears.
root@m120_lab_01> show version
Hostname: m120_lab_01
Model: m120
JUNOS Base OS boot [11.4R3.7]
JUNOS Base OS Software Suite [11.4R3.7]
JUNOS Kernel Software Suite [11.4R3.7]
JUNOS Crypto Software Suite [11.4R3.7]
JUNOS Packet Forwarding Engine Support (M/T Common) [11.4R3.7]
JUNOS Packet Forwarding Engine Support (M120) [11.4R3.7]
JUNOS Online Documentation [11.4R3.7]
JUNOS Voice Services Container package [11.4R3.7]
JUNOS Border Gateway Function package [11.4R3.7]
JUNOS Services AACL Container package [11.4R3.7]
JUNOS Services LL-PDF Container package [11.4R3.7]
JUNOS Services PTSP Container package [11.4R3.7]
JUNOS Services Stateful Firewall [11.4R3.7]
JUNOS Services NAT [11.4R3.7]
JUNOS Services Application Level Gateways [11.4R3.7]
JUNOS Services Captive Portal and Content Delivery Container package [11.4R3.7]
JUNOS Services RPM [11.4R3.7]
JUNOS Services HTTP Content Management package [11.4R3.7]
JUNOS AppId Services [11.4R3.7]
JUNOS IDP Services [11.4R3.7]
JUNOS Services Crypto [11.4R3.7]
JUNOS Services SSL [11.4R3.7]
JUNOS Services IPSec [11.4R3.7]
JUNOS Runtime Software Suite [11.4R3.7]
JUNOS Routing Software Suite [11.4R3.7]
root@m120_lab_01> show interfaces terse
Interface Admin Link Proto Local Remote
pfh-0/0/0 up up
pfh-0/0/0.16383 up up inet
xe-0/0/0 up down
pfh-1/0/0 up up
pfh-1/0/0.16383 up up inet
xe-1/0/0 up up
xe-1/0/0.0 up up inet 1.1.1.1/24
multiservice
pfh-2/0/0 up up
pfh-2/0/0.16383 up up inet
gr-2/2/0 up up
ip-2/2/0 up up
lt-2/2/0 up up
mt-2/2/0 up up
pd-2/2/0 up up
pe-2/2/0 up up
vt-2/2/0 up up
pfh-3/0/0 up up
pfh-4/0/0 up up
pfh-5/0/0 up up
demux0 up up
dsc up up
em0 up up
em0.0 up up inet 10.0.0.4/8
128.0.0.1/2
128.0.0.4/2
inet6 fe80::200:ff:fe00:4/64
fec0::a:0:0:4/64
tnp 0x4
em1 up down
em1.0 up down inet 10.0.0.4/8
128.0.0.1/2
128.0.0.4/2
inet6 fe80::200:1ff:fe00:4/64
fec0::a:0:0:4/64
tnp 0x4
fxp0 up down
gre up up
ipip up up
lo0 up up
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
tap up up
root@m120_lab_01>
Subscribe to:
Posts (Atom)