We’ve been talking about Frame-Relay for a while. In previous posts we’ve seen how to deal with basic frame-relay configuration here, and how to configure some advanced features in Frame-Relay such as back-to-back frame-relay links and PPPoFR here. In this post we’ll keep diving in advanced frame-relay stuff: end-to-end keepalives and TCP&RTP header compression.
So let’s start with the end-to-end keepalive feature.
End-to-End Keepalive (EEK)
As we know, Frame Relay devices connect with each other through virctual circuits (identified by DLCIs), and information about availability or unavailability is carried through LMI with the use of status bits.
Read the rest of Frame Relay Basics III (End-to-End Keepalives and Compression) »
CCIE RS by .
In one of my previous post we spoke about the capability we had to enable a “traffic sniffer” inside our router without the need to use any other physical device on the network. The capture is done and saved inside the router. That feature was called: Embedded Packet Capture
This time I want to write a little bit about another feature for similar purpose, and that is IP Traffic Export, also in the CCIE Lab blueprint.
With “IP Traffic Export” you can “copy” the traffic that is flowing through an interface and direct it to another device in any of the segments that the router is connected. Every packet that matches the specified export “rule” is going to be sent to a configured MAC address (normally a device in promiscuous mode with a sniffer) outbound on a specific interface in the router. Keep in mind that since the traffic is going to be targeted to the MAC, it needs to be on the same layer 2 segment as the router. Also the outgoing interface can be in production (normal traffic switching), but don’t forget that if the traffic to be exported is too much it may affect the performance of the interface.
Read the rest of IP Traffic Export »
CCIE RS by .
On my first article about Cisco Performance Routing, I described how it works, things to keep in mind when deploying PFR/OER and a basic configuration with static definition of traffic classes. In this article we are going to work on Learning methods to dynamically detect and classify the traffic, the modes Cisco Performance Routing can use to measure and react if needed and lastly a feature called link-groups. I highly recommend to give a good read to my first Cisco Performance Routing article as all the foundation are in there.
Read the rest of Cisco Performance Routing – Measure and Learning methods »
CCIE RS by .
On my previous post we described the basics of Frame Relay (Frame Relay Basics). In our journay to achieve the CCIE number we need to learn how to master all the stuff related to layer 2 medias, such as Ethernet, PPP or Frame Relay. In this post we’ll try to dive a little bit deeper on the Frame Relay world.
As we know, when working with Frame Relay we find two protocols that give the same funcionalities than ARP does in Ethernet. These are LMI and Inverse-ARP (InARP). LMI is in charge of announcing all the DLCIs that are provided in a circuit by the Frame Relay service provider, while InARP is in charge of mapping IP addresses to those DLCIs.
Now, what happens if we use a back-to-back frame relay interface to connect two routers? In this case, there is no service provider using LMI to announce the DLCIs, so the interface will not come up. Let’s check it on the lab:
Read the rest of Frame Relay Basics II (back-to-back and PPPoFR) »
CCIE RS by .
INE recently published an infographic about the Cisco Career Certification. You’ll find information like, average salaries for each certification (More info for CCIE Salary here), where are the most demanding locations for CCIE’s, how much time does it take to get on average each certification, and some other information.
I found the infographic very interesting, specially for the salary side (that in real life I still don’t know anyone getting that numbers, specially for CCNA/CCNP) and jobs locations. But, I still miss some interesting information like, current amount of CCNA, CCNP and CCIE certified individuals, average amount of money expended by candidates on each certification, a graph with the CCIE density by geographic location, where are located the highest paying CCIE jobs, etc.
Anyway, is still nice to have one of this available. (full size: Click on the image and then click at the botton right corner expand icon)
Read the rest of Cisco Career Infographic »
Announcements by .
In this post we are going to check some of the basics of the CCIE Lab: the Frame-Relay world. You will find in the CCIE some Frame-Relay configuration for sure, so it worths to spend some time on it, in order to master it.
This is the lab we will follow:
Read the rest of Frame-Relay Basics »
CCIE RS by .
One useful tool I saw more than a year ago implemented by a TAC engineer and rediscovered at the CCIE INE bootcamp, is the Embedded packet capture that IOS provides. It can be very useful while studying for the CCIE.
This feature allows you to capture packets flowing through a router directly without the need to do any configuration changes on switches or doing cabling. Basically it allows you to do something similar to a `monitor session` on a switch but with the difference that the actual packets/dump in this router features are kept in memory and not sent through the wire directly to a sniffer.
The packet capture generated can be displayed on capture software as wireshark (it is on a PCAP format) for later analysis. Allowing you to sniff traffic even when the devices are not physically close to you or when working with remote racks like INE, as they are going to provide in the near future access to a virtual machine on each rack for you to work with packet captures. That way you’ll be able to send your capture to the virtual machine and open it with wireshark, everything from the confort of your home 
Read the rest of Cisco IOS Packet Capture (EPC Embedded Packet Capture) »
CCIE RS by .
INE
Translate
