Jump to content

leerz

Members
  • Content Count

    4
  • Joined

  • Last visited

  • Days Won

    1

leerz last won the day on February 7

leerz had the most liked content!

Community Reputation

687 Excellent

About leerz

  • Rank
    Junior Member

Recent Profile Visitors

94 profile views
  1. So what Do you think is the answer? Did you try to download the dumps? Try to download it and it will answer your question.
  2. Hi all, Please try again [Hidden Content]
  3. Cisco SD-WAN Viptela - Lab Minutes (Basic Videos) This video bundle features a complete video download set for Cisco Software Defined WAN (Basic). With over 11 hours of lab video tutorial, you will be able to get up to speed and become more familiar with the technologies. Buy this video bundle and view them locally ad-free on your computer at your own pace without internet connection, and get a saving over 12%. This video bundle helps you lay a foundation to Cisco SD-WAN (Viptela) technology. The video series begins by providing you with the fundamental of Cisco SD-WAN before walking you through installations of all the key components including the controllers (vManage, vBond, vSmart) and assorted type of WAN Edge routers (ISR4K, vEdge, vEdge Cloud). You will learn how to configure devices using templates. By the end of the video series, you will have basic routing and connectivity established over your SD-WAN overlay ready to pass traffic. The next generation WAN is here so do not miss out this learning opportunity. Download [hide][Hidden Content]]
  4. Thanks..but do you have Mega? Those file size are only 60 MB each file and you can just upload it as a whole
  5. Yeah, they say that Narbik is one of a hell trainer and motivator
  6. 8.3 Implementing High Availability in Networking Bidirectional Forwarding Detection Support The detection of failures is typically accomplished via hardware detection mechanisms. However, the signals from these mechanisms are not always conveyed directly to the upper protocol layers, such as routing protocols. When the hardware mechanisms do not exist (for example, Ethernet) or when the signaling does not reach the upper protocol layers, the protocols must rely on their much slower strategies to detect failures. The detection times in existing protocols are typically equal to or greater than one second, and sometimes much longer. For some applications, this is too long to be useful. Drivers for Bidirectional Forwarding Detection: Data link layer detection can miss some types of outages Control Plane failure Control Plane failure detection is slow Order of tens of seconds Data link layer failure detection is not consistent across media types Very quick to quick for some media (SONET, Ethernet) Slow on other WAN links Provides failure detection consistency across routing protocols Built in routing failure detection mechanisms are not fast enough for SP world Packet over SONET (POS) tends to have the best failure detection time among the different media choices. It can typically detect and react to media or protocol failures in ~50 milliseconds. This has become the benchmark against which other protocols are measured. Bidirectional Forwarding Detection Bidirectional Forwarding Detection (BFD) provides low-overhead, short-duration detection of failures in the path between adjacent forwarding engines. BFD allows a single mechanism to be used for failure detection over any media and at any protocol layer, with a wide range of detection times and overhead. The fast detection of failures provides immediate reaction to failure in the event of a failed link or neighbor. A secondary benefit of BFD, in addition to fast failure detection, is that it provides network administrators with a consistent method of detecting failures. Thus, one availability methodology could be used, irrespective of the Interior Gateway Protocol (IGP) or the topology of the target network. This eases network profiling and planning, because re-convergence time should be consistent and predictable. BFD function is defined in RFC 5880. It is UDP-based and is being put into all of the hardware (e.g. Cisco CRS, Cisco Nexus 9000, and Cisco NCS 6000). It actually resides in the port ASIC. The Fundamental difference between the BFD Hellos and the Protocol Hellos (OSPF, RSVP and so on) is that BFD adjacencies do not go down on Control-Plane restarts (e.g. RSP failover) since the goal of BFD is to detect only the forwarding plane failures. BFD has two operating modes that may be selected and an extra function that can be used with the two modes. The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down. The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously. An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode). Cisco IOS XR software only supports asynchronous mode and has echo enabled by default. Asynchronous Modes Asynchronous mode without echo will engage various pieces of packet switching paths on local and remote systems. However, asynchronous mode with echo is usually known to provide slightly wider test coverage as echo packets are self-destined packets which traverse same packet switching paths as normal traffic on the remote system. Cisco IOS XR software supports the asynchronous mode of operation only (i.e. no Demand mode), with or without using echo packets (echo is enabled by default). When BFD is running asynchronously without echo packets, the following occurs: Each system periodically sends BFD control packets to one another. Packets sent by BFD router "Peer A" to BFD router "Peer B" have a source address from Peer A and a destination address for Peer B. Control packet streams are independent of each other and do not work in a request/response model. If a number of packets in a row are not received by the other system, the session is declared down. When BFD is running asynchronously with echo packets, the following occurs: BFD echo packets are looped back through th e forwarding path only of the BFD peer and are not processed by any protocol stack. So, packets sent by BFD router "Peer A" can be sent with both the source and destination address of Peer A. BFD echo packets are sent in addition to BFD control packets. Configuring BFD In IOS-XR an application must terminate the BDF session. Unlike IOS, direct peering without any application using the session is not allowed. Adding bfd fast-detect suffix to the normal static route will enable BFD feature. To fine tune BFD behavior, use minimum-interval and multiplier optional parameters inside same command. BFD on a Static Routes (simplest application): router static address-family ipv4 unicast 172.16.1.1/32 10.1.1.1 bfd fast-detect minimum-interval 5000 multiplier 3 ! interface GigabitEthernet0/0/0/0 ipv4 address 10.1.1.2 255.255.255.0 Provided examples for OSPF and IS-IS routing protocols demonstrate that same BFD commands are used for all protocols. BFD with IGP Peers (OSPF example): router ospf 1 area 0 ! interface GigabitEthernet0/2/0/1 bfd minimum-interval 100 bfd multiplier 3 bfd fast-detect ipv4 BFD with IGP Peers (ISIS example): router isis lab net 49.0111.0111.0111.0111.00 address-family ipv4 unicast redistribute connected ! interface GigabitEthernet0/2/0/1 bfd minimum-interval 500 bfd multiplier 3 bfd fast-detect ipv4 The show bfd session command allows review of configuration details and in addition provides current state for all sessions between the router and neighbors. The show bfd counters packet provides info for received and transmitted Control and Echo BFD packets (if enabled). RP/0/RSP0/CPU0:ASR9K-1# show bfd session Interface Dest Addr Local det time(int*mult) State Echo Async --------------- --------------- ---------------- ---------------- ---------- Gi0/2/0/1 10.0.9.1 1500ms(500ms*3) 6s(2s*3) UP RP/0/RSP0/CPU0:WEST-PE-ASR9K-1# show bfd counters packet GigabitEthernet0/2/0/1 Recv Xmit Recv Xmit Async: 44048 44182 Echo: 175384 175384
  7. Hi, Thank you. Tried to download it but to slow.. do you have an alternative like mega?
  8. Nice, a torrent link
  9. Planning to take the exam also.
×
×
  • Create New...