Thursday 23 January 2014

‘OSPF Neighbor Adjacency States’

How is OSPF?
OSPF is a fairly complex protocol made up of several protocol handshakes, database advertisements, and packet types.
Link-State Routing Protocols
  • They respond quickly to network changes.
  • They send triggered updates when a network change occurs.
  • They send periodic updates, known as link-state refresh, at long time intervals, such as every 30 minutes.
  • Uses cost as metric.
  • Protocol identifier of 89 in the IP header indicates an OSPF packet
  • Each interface participating in OSPF uses the IP multicast address 224.0.0.5 to periodically send hello packets
Link-state routing protocols generate routing updates only when a change occurs in the network topology.
  1. When a link changes state, the device that detected the change creates a link-state advertisement (LSA) concerning that link.
  2. The LSA propagates to all neighboring devices using a special multicast address.
  3. Each routing device stores the LSA, forwards the LSA to all neighboring devices (in same area).
  4. This flooding of the LSA ensures that all routing devices can update their databases and then update their routing tables to reflect the new topology.
  5. The LSDB is used to calculate the best paths through the network.
  6. Link-state routers find the best paths to a destination by applying Dijkstra’s algorithm, also known as SPF, against the LSDB to build the SPF tree.
  7. Each router selects the best paths from their SPF tree and places them in their routing table.
For all the routers in the network to make consistent routing decisions, each link-state router must keep a record of the following information:
  • Its immediate neighbor routers.
  • All the other routers in the network, or in its area of the network, and their attached networks.
  • The best paths to each destination.
OSPF neighbor table = adjacency database
OSPF topology table = OSPF topology database = LSDB
Routing table = forwarding database
OSPF Area Structure
If an area becomes too big, the following issues need to be addressed:
  • Frequent SPF algorithm calculations.
  • Large routing table— OSPF does not perform route summarization by default.
  • Large LSDB
Solutions:
  • Link-state routing protocols usually reduce the size of the Dijkstra calculations by partitioning the network into areas.
Advantages of OSPF areas
  • Reduced frequency of SPF calculations.
  • Smaller routing tables
  • Reduced LSU overhead
OSPF uses a two-layer area hierarchy:
  • Backbone area
  • Regular (nonbackbone) area – subtypes standard area, stub area, totally stubby area, not-so-stubby area (NSSA), and totally stubby NSSA
• An area should have no more than 50 routers.
• A router should not be in more than three areas.
Area Terminology
  • Internal router
  • Backbone router
  • Area Border Router (ABR)
  • Autonomous System Boundary Router (ASBR)
OSPF Adjacencies
  1. The router sends and receives hello packets to and from its neighboring routers. The destination address is typically a multicast address.
  2. The routers exchange hello packets subject to protocol-specific parameters, such as checkingwhether the neighbor is in the same area, using the same hello interval, and so on. Routers declare the neighbor up when the exchange is complete.
  3.  After two routers establish neighbor adjacency using hello packets, they synchronize their LSDBs by exchanging LSAs and confirming the receipt of LSAs from the adjacent router. The two neighbor routers now recognize that they have synchronized their LSDBs with each other. For OSPF, this means that the routers are now in full adjacency state with each other.
  4.  If necessary, the routers forward any new LSAs to other neighboring routers, ensuring complete synchronization of link-state information inside the area.
Notes: OSPF routers on broadcast networks, such as LAN links, elect one router as the designated router (DR) and another as the backup designated router (BDR). All other routers on the LAN form full adjacencies with these two routers and pass LSAs only to them. The DR forwards updates received from one neighbor on the LAN to all other neighbors on that same LAN. One of the main functions of a DR is to ensure that all the routers on the same LAN have an identical LSDB. Thus, on broadcast networks, an LSDB is synchronized between a DROTHER (a router that is not a DR or a BDR) and its DR and BDR.
The DR passes its LSDB to any new routers that join that LAN. Having all the routers on that LAN pass the same information to the new router is inefficient, so the one DR router represents the other routers to a new router on the LAN or to other routers in the area. Routers on the LAN also maintain a partial-neighbor relationship, called a two-way adjacency state, with the other routers on the LAN that are not the DR or BDR, the DROTHERs.
LSAs have the following characteristics:
  • LSAs are reliable. There is a method for acknowledging their delivery.
  • LSAs are flooded throughout the area (or throughout the domain if there is only one area).
  • LSAs have a sequence number and a set lifetime, so each router recognizes that it has the most current version of the LSA.
  • LSAs are periodically refreshed to confirm topology information before they age out of the LSDB.
OSPF Metric Calculation
For OSPF, the default behavior on Cisco routers is that the interface cost is calculated based on its configured bandwidth. The higher the bandwidth, the lower the cost. The default OSPF cost on Cisco routers is calculated using the formula (100) / (bandwidth in megabits per second [Mbps]).
So, a DS-3 interface, with a configured bandwidth of 45000 kbps, has a cost of:
100,000,000 / 45,000 = 2222

• 56-kbps serial link—Default cost is 1785.
• 64-kbps serial link—Default cost is 1562.
• T1 (1.544-Mbps serial link)—Default cost is 64.
• E1 (2.048-Mbps serial link)—Default cost is 48.
• Ethernet—Default cost is 10.
• Fast Ethernet—Default cost is 1.
• FDDI—Default cost is 1.
• ATM—Default cost is 1.
Link-State Data Structures
  • Each LSA entry has its own aging timer
  • After a default of 30 minutes the router that originated the entry resends the LSA, with a higher sequence number, in a link-state update (LSU), to verify that the link is still active.
  • If the LSA were to reach its maximum age (max age) of 60 minutes, it would be discarded.
Benefit: This LSA validation method saves on bandwidth compared to distance vector routers, which send their entire routing table at short, periodic intervals.
OSPF Packets
  • Neighbor discovery, to form adjacencies
  • Flooding link-state information, to facilitate LSDBs being built in each router
  • Running SPF to calculate the shortest path to all known destinations
  • Populating the routing table with the best routes to all known destinations
 Data— Contains different information, depending on the OSPF packet type:
  • For the hello packet—Contains a list of known neighbors.
  • For the DBD packet—Contains a summary of the LSDB, which includes all known router IDs and their last sequence number, among several other fields.
  • For the LSR packet—Contains the type of LSU needed and the router ID of the router tha thas the needed LSU.
  • For the LSU packet—Contains the full LSA entries. Multiple LSA entries can fit in one OSPFupdate packet.
  • For the LSAck packet—This data field is empty.
Establishing OSPF Neighbor Adjacencies: Hello
The Hello protocol establishes and maintains neighbor relationships by ensuring bidirectional (two-way) communication between neighbors and the package contain:
  • Router ID
  • Hello and dead intervals (must match between neighbors)
  • Area ID (must match between neighbors)
  • Router priority
  • DR and BDR IP addresses
  • Authentication password (if enabled)
  • Stub area flag (must match between neighbors)
Note
For routers to establish an adjacency on an interface, the primary IP addresses on the routers’ interfaces  must also be on the same subnet with the same mask, and the interface maximum transmission unit (MTU) must match.
Exchange Process and OSPF Neighbor Adjacency States
  1. Down: It begins by sending a hello packet through each of its interfaces participating in OSPF, even though it does not know the identity of the DR or of any other routers. The hello packet is sent out using the multicast address 224.0.0.5.
  2. Init: All directly connected routers running OSPF receive the hello packet from Router  and add Router to their list of neighbors.
  3. All routers that received the hello packet send a unicast reply packet to Router with their corresponding information. The Neighbor field in the hello packet includes all other neighboring routers, including Router .
  4. Two-way: When Router receives these hello packets, it adds all the routers that have its router ID in their hello packets to its own neighbor relationship database.
If a router joins a broadcast network in which there is already a DR and BDR, it will get to the neighbor two-way state with all routers, including the DR and BDR, and those that are DROTHER (not DR or BDR). The joining router will continue to form full bidirectional adjacencies only with the DR and BDR.
OSPF Neighbor StatesThe following is a brief summary of the states OSPF may pass through before becoming adjacent to (neighbors with) another router:
• Down: No active neighbor detected.
• Init: Hello packet received.
• Two-way: Router sees its own router ID in a received hello packet.
• ExStart: Master/slave roles determined.
• Exchange: DBDs (summary of LSDB) sent.
• Loading: Exchange of LSRs and LSUs, to populate LSDBs.
• Full: Neighbors fully adjacent.
Network instability SPF calculation
The timers throttle spf router configuration command, introduced in Cisco IOS Software Release 12.2(14)S, enables the OSPF throttling feature so that the SPF calculations can be potentially delayed during network instability.
LSA Sequence number:
show ip ospf database
debug ip ospf packet
Configuring and Verifying Basic OSPF Routing
Considerations for OSPF include the following:
• IP addressing plan— The IP addressing plan governs how OSPF can be deployed and how well the OSPF deployment will scale. A detailed hierarchical IP subnet and addressing plan must be produced, to enable OSPF summarization, allow the network to scale more easily, and to optimize OSPF behavior.
• Network topology— The topology consists of the devices (routers, switches, and so on) and the links connecting them. A detailed network topology should be created to assess OSPF scalability requirements and to determine which OSPF features might be required (for example, multiple areas, OSPF summarization, stub areas, and redistribution). The topology should include backup links where necessary.
• OSPF areas— Dividing an OSPF network into areas decreases the LSDB size and limits the propagation of link-state updates when the topology changes. The routers that are to be ABRs and ASBRs must be identified, as are those that are to perform any summarization or redistribution.
After the requirements have been assessed, the implementation plan can be created. The implementation plan should include the following steps:
• Define the network requirements
• Gather the required parameters
• Define the OSPF routing parameters
• Configure OSPF
• Verify the OSPF configuration
Basic configuration:
router process-id
network ip-address wildcard-mask area area-id  example network 10.0.0.0 0.255.255.255 area 0 or
ip ospf process-id area area-id  interface configuration command
OSPF Router ID
An OSPF router ID uniquely identifies each OSPF router in the network. The OSPF routing process chooses a router ID for itself when it starts up. The router ID is a unique number in IP address format that can be assigned in the following ways:
  1. By default, the highest IP address of any active physical interface when OSPF starts is chosen as the router ID. The interface does not have to be part of the OSPF process, but it has to be up. There must be at least one “up” IP interface on the router for OSPF to use as the router ID. If no up interface with an IP address is available when the OSPF process starts, the following error message occurs:R1(config)#router ospf 12w1d: %OSPF-4-NORTRID: OSPF process 1 cannot start.
  2. Alternatively, if a loopback interface exists, its IP address will always be preferred as the router ID instead of the IP address of a physical interface, because a loopback interface never goes down. If there is more than one loopback interface, the highest IP address on any active loopback interface becomes the router ID.
  3. Alternatively, if the router-id ip-address OSPF router configuration command is used, it will override the use of the address of a physical or loopback interface as the router ID. Using the router-id command is the preferred procedure for setting the router ID.
The OSPF database uses the router ID to uniquely describe each router in the network.
Configuration
Router(config)#router ospf  1
Router(config-router)#router-id  172.16.1.1
Router#clear ip ospf process
Verifying
show ip ospf
Loopback interfaces
first define a loopback interface with the interface loopback number global configuration command, and then configure an IP address on the loopback interface.
To verify that OSPF has been properly configured, use the following show commands:
  •  show ip ospf
  •  show ip ospf interface [type number] [brief]
  • show ip ospf neighbor [type number] [neighbor-id] [detail]
  •  show ip route ospf
  • show ip protocols
  • debug ip ospf events
  • debug ip ospf adj
  • debug ip ospf packet
Types of OSPF Networks
• Point-to-point— A network that joins a single pair of routers.
• Broadcast— A multiaccess broadcast network, such as Ethernet.
• Nonbroadcast multiaccess (NBMA)— A network that interconnects more than two routers but that has no broadcast capability.
Electing a DR and BDR and Setting Priority
To elect a DR and BDR, the routers view the OSPF priority value of the other routers during the hello packet exchange process and then use the following conditions to determine which router to select:
  • The router with the highest priority value is the DR
  • The router with the second-highest priority value is the BDR.
  • The default for the interface OSPF priority is 1. In case of a tie, the router ID is used.
  • A router with a priority of 0 cannot become the DR or BDR. A router that is not the DR or BDR is a DROTHER.
  • If a router with a higher priority value gets added to the network, it does not preempt the DR and BDR. The only time a DR or BDR changes is if one of them goes out of service. If the DR is out of service, the BDR becomes the DR, and a new BDR is selected. If the BDR is out of service, a new BDR is elected.
Configuring
Use the ip ospf priority number interface configuration command
Adjacency Behavior for a Point-to-Point Link
The default OSPF hello and dead intervals on point-to-point links are 10 seconds and 40 seconds, respectively. (The hello and dead timers can be changed with the ip ospf hello-interval seconds and ip ospf dead-interval seconds interface configuration commands.)
OSPF Nonbroadcast Mode Configuration
After you enable the OSPF process for specific interfaces, you configure nonbroadcast mode by
• Manually configuring OSPF neighbors
• Defining the OSPF network type as nonbroadcast (unless it is the default)
Use the neighbor ip-address [priority number] [poll-interval number] [cost number] [database-filter all] router configuration command to statically define adjacent relationships in NBMA networks using the nonbroadcast mode.
Configuring hub:
router ospf 10
network 192.186.1.0 0.0.0.255 area 0
neighbor 192.168.1.2 priority 0
neighbor 192.168.1.3 priority 0
interface s1/0
ip address 192.168.1.2 255.255.255.252
ip ospf priority 0
Verify neighborship status:
show ip ospf neighbor
Point-to-multipoint mode has the following properties:
  • Does not require a full-mesh network.
  • Does not require a static neighbor configuration
  • Duplicates LSA packets
Config:
RouterA(config)#interface Serial0/0/0
RouterA(config-if)#ip address 192.168.1.1 255.255.255.0
RouterA(config-if)#encapsulation frame-relay
RouterA(config-if)#ip ospf network point-to-multipoint
RouterA(config)#router ospf 100
RouterA(config-router)#log-adjacency-changes
RouterA(config-router)#network 172.16.0.0 0.0.255.255 area 0
RouterA(config-router)#network 192.168.1.0 0.0.0.255 area 0
RouterC(config)#interface Serial0/0/0
RouterC(config-if)#ip address 192.168.1.3 255.255.255.0
RouterC(config-if)#encapsulation frame-relay
RouterC(config-if)#ip ospf network point-to-multipoint
RouterC(config)#router ospf 100
RouterC(config-router)#log-adjacency-changes
RouterC(config-router)#network 192.168.1.0 0.0.0.255 area 0
OSPF Configuration in Cisco Point-to-Multipoint Nonbroadcast Mode
  • Cisco extension
  • Statically define neighbors
  • Cost of the link to the neighboring router to reflect the different bandwidths of each link
  • DRs and BDRs are not elected.
Using Subinterfaces in OSPF over Frame Relay Configuration
  • A physical interface can be split into multiple logical interfaces called subinterfaces.
  • Subinterfaces were originally created to better handle issues caused by split horizon over NBMA for distance vector-based routing protocols.
  • Each subinterface requires an IP subnet
  • interface serial number.subinterface-number {multipoint | point-to-point}global configuration command.
RouterA#
interface Serial0/0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0/0.1 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 121
interface Serial0/0/0.2 point-to-point
ip address 192.168.2.1 255.255.255.0
frame-relay interface-dlci 132
RouterB#
interface Serial0/0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0/0.1 point-to-point
ip address 192.168.1.2 255.255.255.0
frame-relay interface-dlci 122
Multipoint
interface Serial0/0/0.2 multipoint
ip address 192.168.2.1 255.255.255.0
<output omitted>
router ospf 100
network 192.168.0.0 0.0.255.255 area 0
neighbor 192.168.2.2 priority 0
neighbor 192.168.2.3 priority 0
RouterB#
interface Serial0/0/0
ip address 192.168.1.2 255.255.255.0
<output omitted>
RouterC#
interface Serial0/0/0
ip address 192.168.2.2 255.255.255.0
ip ospf priority 3
Note
Recall that, by default, OSPF advertises loopback interface addresses as /32 host routes. If the ip ospf network point-to-point command is configured on a loopback interface, OSPF advertises the actual loopback subnet mask, instead of a /32 host route.
Displaying OSPF Adjacency Activity
Use the debug ip ospf adj command to track OSPF adjacencies as they go up or down
Understanding OSPF LSAs
  • LSA Type 1 – Router – contains router links and state and is flooded into the area of origin
  • LSA Type 2 – Network – generated by DR – lists all attached routers – flooded into the area of origin.
  • LSA Type 3 – Network Summary – generated by ABR’s sent into an area to advertise prefixes to other areas – flooded throughout the Autonomous System.
  • LSA Type 4 – ASBR Summary – generated by ABR’s – advertises the ASBR – flooded throughout the Autonomous System
  • LSA Type 5 – AS External - generated by ASBR – advertises external destination – flooded throughout the Autonomous System
  • LSA Type 7 – NSSA External – generated by the ASBR in a not so stubby area – advertises external destination.
- By default, OSPF does not automatically summarize groups of contiguous subnets, or even summarize a network to its classful boundary.

Sunday 19 January 2014

CCIE PRACTICE LAB 1



SCENARIO

So you've finished CCNP by scoring 900+ on all three exams and you feel pretty confident about starting your CCIE journey. In studying for the written exam, you also like to build complex labs in your spare time. You haven't quite learned all of the CCIE technologies yet, but you've seen enough tricks from other practice labs that you decided to build your own! See if you can solve this lab in 8 hours or less while concurrently minimizing the use of "show run" and "show start".

GOAL:

  • Nothing has been preconfigured for you! You must build this lab completely from scratch, so pay close attention to the cabling instructions.
  • No static routing, policy-based routing, or default routing is allowed unless explicity stated.
  • Each router should be configured with two loopbacks. "x" is the router number. For example, R1 would have 1.1.1.1/32 and 11.11.11.11/32, R2 would have 2.2.2.2/32 and 22.22.22.22/32, etc.
    Loopback0 = x.x.x.x /32
    Loopback1 = xx.xx.xx.xx /32
  • Switch cabling:
    R1 F0/0 -> SW1 F1/1, VLAN 123
    R1 F0/1 -> SW2 F1/1, VLAN 137
    R2 F0/0 -> SW1 F1/2, VLAN 123
    R2 F0/1 -> SW2 F1/2, VLAN 246
    R3 F0/0 -> SW2 F1/3, VLAN 123
    R4 F0/0 -> SW2 F1/4, VLAN 246
    R5 F0/0 -> SW1 F1/5, VLAN 157
    R6 F0/0 -> SW1 F1/6, VLAN 256
    R7 F0/0 -> SW2 F1/7, VLAN 157
  • Frame Relay DLCI mapping
    R1:R2 :: 102:201
    R1:R7 :: 107:701
    R7:R4 :: 704:407
    R4:R6 :: 406:604
    R6:R2 :: 602:206
  • Phase 1: Basic configuration
    1. Build the topology as shown in the diagram by making physical connections.
    2. Configure all IP addresses and the FR switch as described above and shown in the diagram.
    3. Disable automatic speed and duplex negotiation on all FastEthernet interfaces. Use the fastest line speed and duplex settings you can.
    4. Disable CEF on all routers. Disable ip route-cache and ip mroute-cache on all multicast-routing interfaces. This is to overcome a multicast bug with GNS3.
  • Phase 2: Frame Relay
    1. On R1, R2, R4, and R7, configure frame relay. Use a non-proprietary encapsulation form, do not rely on IARP, and do not use the word "broadcast" anywhere in your configuration. Pay attention to the IP subnets; they will tell you whether to use P2P or MP links. Ensure you can communicate from R2 to R4. Helper commands: show frame-relaymap, show frame-relay pvc
    2. On R4 and R6, configure PPP over frame relay. Use CHAP for additional security. Helper commands: debug ppp negotiation, debug ppp authentication
    3. On R2 and R6, configure PPP over frame relay. Use PAP for additional security. Helper commands: debug ppp negotiation, debug ppp authentication
  • Phase 3: LAN Switching
    1. Add VLANs 123, 157, and 246 to the VLAN database and configure the VLAN-port mapping as described above. In GNS3, you have to do this EVERY TIME you reopen your project! Also, ensure your switches are Layer 2 only; by default in GNS3 they are multi-layer.
    2. Configure SW1 as the root bridge for VLANs 1 and 123. Configure SW2 as the root bridge for VLANs 157 and 246. Helper commands: show spanning-tree root port, show spanning-tree root cost
    3. Bundle F1/12-13 into PortChannel1 and F1/14-15 into PortChannel2 on both switches. Enable static Etherchannel. Helper commands: show etherchannel summary
    4. Configure F1/12-15 and Po1-2 as 802.1Q encapsulated trunks.
    5. To make best use of your new Etherchannels, you decide to load balance VLAN traffic across your two trunks. Po1 should carry VLANs 1 and 123 and Po2 should carry VLANs 157 and 246. If one trunk fails, the other must take over (that is, do NOT use "switchport trunk allowed vlan" command). You are only allowed to configure SW1 Po1 interface to achieve this. You can use "show" commands on SW2. Because there are only two switches, the roots will always have their ports in a forwarding state for the VLANs for which they are the root of the spanning tree; don't worry about this. Helper commands: show spanning-tree, show interfaces trunk
    6. A data collector wants to look at the traffic coming from and going to R1 and R2 on VLAN 123. Configure SPAN on SW1. The data collector will plug into F1/0 on SW1.
    7. Test connectivity between the router FastEthernet interfaces on the same segment. Helper commands: show arp (router), show mac-address-table (switch)
  • Phase 4: OSPF
    1. Configure OSPF area 0 on R3 loopback0 interface. Make sure LSAs are not sent to this loopback.
    2. Configure OSPF area 123 on R1, R2, and R3 F0/0 interfaces (corresponding to VLAN 123). Ensure R3 is the DR and R1 is the BDR on the segment. Helper commands: show ip ospf neighbor, show ip ospf interface
    3. Configure OSPF area 17 between R1 F0/1 and R7 F0/0 interfaces. To ensure R5 does not see any OSPF hello messages, send the updates as unicast packets. Ensure R7 is the DR on the segment with R1 and the BDR.
    4. Configure OSPF area 127 on R1, R7, and R2 frame-relay interfaces (whatever you called them). There should be no DR election on this network. Remember, this segment of the FR network is NBMA!
    5. Configure OSPF area 246 between R2, R4, and R6 frame-relay interfaces but NOT their FastEthernet interfaces on the LAN segment. To be clear, R2 and R6 will neighbor, and R4 and R6 will neighbor, as there is no DLCI between R2 and R4.
    6. Ensure all OSPF routers have full connectivity to the backbone area.
    7. Go back and add MD5 authentication to every OSPF link, including the secret ones I did not explicitly tell you to configure.
  • Phase 5: EIGRP
    1. Configure EIGRP AS 2467 between R4 and R7 FR interfaces (NBMA again).
    2. Configure EIGRP on R2 F0/1, R6 F0/0, and R4 F0/0 interfaces on VLAN 246. Helper commands: show ip eigrp neighbor
    3. Advertise R2, R4, R6, and R7 loopback0 interfaces into EIGRP, and make sure they do not participate in forming neighborships. Helper commands: show ip eigrp interface
    4. From R2, ensure you can ping to 7.7.7.7 from 2.2.2.2.
    5. *This is not EIGRP related, but critical for the next task* Configure NTP on R2, R4, R6, and R7. NTP updates should be sourced from loopbacks in all cases and should be authenticated with MD5. R4 is the NTP master and the other routers are simply peers. Ensure NTP is functional with an accurate clock before continuing. Helper commands: show ntp status
    6. Go back and add MD5 authentication to every EIGRP link. Use a rotating key. The first key is good from the time you started this lab until 1 hour from now. The second key is valid beginning 55 minutes from now and is good forever. This way, in one hour, you will be able to see if you configured this task properly. Helper commands: show ip eigrp interface detail, show key chain
    7. R4 and R6 are not allowed to accept updates from one another, but still want to maintain their neighborship. Therefore, you cannot use the neighbor command. Ensure R4 and R6 ignore all updates from one another, but continue to listen to R2. Ensure there is no loss of connectivity or suboptimal routing. Hint: You will have to configure all three routers.
    8. Add (4) loopbacks to R2 with IP addresses 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24, and 172.16.3.1/24. Summarize these on the F0/1 interface, but make sure the 172.16.2.0/24 is still advertised explicitly. Also, this 172.16.2.0/24 route should be set to tag 2 when it is advertised out of F0/1.
  • Phase 6: GLBP
    1. R5 is only a part-time router. Sometimes it wants to act like a host. Configure a static default route on R5 pointing to 192.168.157.254.
    2. Configure GLBP 157 on R1 F0/1 and R7 F0/0. The virtual gateway is 192.168.157.254. Ensure R5 can ping this virtual gateway. Helper commands: show arp
    3. R1 should be the AVG initially. Both routers should pay a penalty with respect to their priorities if their serial (FR) interfaces lose line protocol. For example, if R1 is AVG and it's S0/0 goes down, R7 becomes AVG. If R7 S0/0 goes down next, R1 regains AVG role. R5 should be able to reach any OSPF router at this point given that it's traffic is sourced from F0/0. Helper commands: show glbp, show track
  • Phase 7: Redistribution
    1. Configure a static route to 5.5.5.5/32 on both R1 and R7 with a next hop of R5 F0/0 interface. Selectivelyredistribute these routes at both R1 and R7 into OSPF (this means use a route-map). You are not allowed to use ACLs or prefix-lists anywhere in this solution. Ensure other OSPF routers can reach this network. Helper commands: show route-map, show ip protocols, show ip ospf database external
    2. Mutually redistribute between EIGRP 2467 and OSPF on R2, R6, R4, and R7. Ensure no loops or suboptimal routing occurs. You will need to use route-maps in some places to perform filtering. Helper commands: show ip protocols, debug ip routing, show ip route eigrp, show ip route ospf
  • Phase 8: BGP
    1. Configre BGP AS 135 between R1, R3, and R5. You can only peer R5-R1 and R5-R3 and cannot use confederations. R5 and R3 should source updates from loopback0, while R1 should source updates from F0/1. Helper commands: show ip bgp summary, show ip bgp neighbors, debug ip bgp
    3. Configure BGP Confederation-AS between R4 F0/0 (Sub-AS 4) and R6 F0/0 (Sub-AS 67). Also peer from R6 Loop0 to R7 Loop0 (also in Sub-AS67).
    3. Configure BGP AS 2 on R2. R2 F0/0 peers with R3 Loop0 and R2 F0/1 peers with R4 Loop0.
    4. Configure BGP between R5 Loop0 and R7 Loop0.
    5. Each router must bring it' Loopback 1 interface into BGP.
    6. Ensure you have full IP connectivity between Loopback1 interfaces. You will need to manipulate BGP path attributes to make this work, as it will be broken in the default configuration.
    7. R4 used to be in AS 4444 before joining the confederation. R2 still wants to peer with R4 using that AS. Without changing the actual BGP AS numbers, re-configure the R2-R4 peering so that R2 is configured with "neighbor 4.4.4.4 remote 4444".
    8. Add two new loopbacks onto R6 with IP addresses 66.66.66.1/32 and 66.66.66.2/32. The first loopback should not be allowed outside of the Sub-AS 67 (only R7 sees it), while the second should not be allowed out of the confederation AS 467 (R7 and R4 see it). Do not use the "network" command for this task, do not bring any other networks into BGP other than the two stated in this task, and make sure the origin for these routes is IGP.
    9. Go back and enable MD5 authentication between all true eBGP links (not within the confederation). iBGP links will remain unsecure.
  • Phase 9: Misc features
    1. Configure R1 so that it only accepts telnet connections from R6 Loopback1.
    2. Configure R7 so that it only accepts SSH connections from R3 Loopback1.
    3. Copy R5's running configuration into flash memory just in case.
    4. Copy R6's EIGRP topology table into flash memory too. Be sure to include nonsuccessor routes as well.
    5. On R6, print the contents of Task #4 onto the screen by reading from flash, not issuing the IOS command "show ip eigrp ..."
    6. Using IP SLA on R5, send a ping from R5 Loop1 to R3 Loop1 every 5 seconds, beginning now, running forever. The pings should be successful.
  • Phase 10: QoS
    1. R1 and R7 both agree that traffic from R5's Loopback0 is not important. Ensure it receives the lowest possible DSCP value before going out over FR. If the traffic doesn't go over FR, it can retain it's DSCP value. Additionally, ensure the FR network makes this traffic from this source more likely to be discarded if the network becomes congested.
    2. R1 and R7 also agree that traffic from R5's Loopback1 is very important, as long as it isn't ICMP. For all non-ICMP traffic, apply a high DSCP value with a medium drop probabiltiy that is not EF. For ICMP traffic, apply a low DSCP value with a high drop probability that is not zero. RTP audio treatment should get expedited service through the network, however, and should also be guaranteed 15% of the bandwidth over the frame relay network. Non-ICMP traffic should be granted 25% of what
    bandwidth remains.
    3. R1 and R7 also expect to see a lot of non-ICMP, non-RTP traffic from traffic from R5's Loopback1 interface. You fear that the queues may fill to capacity and suffer tail drop. Enable a feature to mitigate this so that after 20 packets are in the queue, 1 in every 15 packets gets dropped. After 45 packets are in the queue, all packets will be dropped. Helper commands: show ip nbar .... , show policy-map interface
  • Phase 11: Multicast
    1. Establish a GRE tunnel between R1 F0/0 and R4 F0/0 interfaces. Enable OSPF over this tunnel without making any configurations under "router ospf". Be sure to authenticate OSPF updates. Use any IP address for the tunnel interface, and any OSPF area ID.
    2. Enable PIM-SM on the tunnel. R4 Loopback0 should be the RP for group 225.3.3.3 and no other groups.
    3. R3 F0/0 wants to receive multicast on group 225.3.3.3.
    4. R6 is the source for this multicast traffic. Ensure R6 can send multicast to 225.3.3.3 successfully.
    5. For additional security, configure IPSEC over GRE on the tunnel between R1 and R4 and ensure the multicast traffic goes over this tunnel. Use AES 256 for encryption, SHA-1 for authentication, and DH Group 2. Helper commands: debug crypto ipsec, debug crypto isakmp, debug crypto engine, show crypto isakmp peer, show crypto ipsec sa

IOS:

c3725-adventerprisek9-mz.124-7.image

TOPOLOGY:

Basic GNS3 physical topology


ccie 21 nov
Basic GNS3 Topology, Logical diagram with switches removed
ccie
Frame Relay topology
ccie fr


Wednesday 8 January 2014

Cisco Router Boot Sequence:

In this article we will learn about the main components of a Cisco router and how the boot process takes place.
Types of memory
Generally Cisco routers (and switches) contain four types of memory:
Read-Only Memory (ROM): ROM stores the router’s bootstrap startup program, operating system software, and power-on diagnostic test programs (POST).
Flash Memory: Generally referred to simply as “flash”, the IOS images are held here. Flash is erasable and reprogrammable ROM. Flash memory content is retained by the router on reload.
Random-Access Memory (RAM): Stores operational information such as routing tables and the running configuration file. RAM contents are lost when the router is powered down or reloaded. By default, routers look here first for an Internetwork Operating System (IOS) file during boot.
Non-volatile RAM (NVRAM): NVRAM holds the router’s startup configuration file. NVRAM contents are not lost when the router is powered down or reloaded.
Some comparisons to help you remember easier:
+ RAM is a volatile memory so contents are lost on reload, where NVRAM and Flash contents are not.
+ NVRAM holds the startup configuration file, where RAM holds the running configuration file.
+ ROM contains a bootstrap program called ROM Monitor (or ROMmon). When a router is powered on, the bootstrap runs a hardware diagnostic called POST (Power-On Self Test).
Router boot process
The following details the router boot process:
1. The router is powered on.
2. The bootstrap program (ROMmon) in ROM runs Power-On Self Test (POST)
3. The bootstrap checks the Configuration Register value to specify where to load the IOS. By default (the default value of Configuration Register is 2102, in hexadecimal), the router first looks for “boot system” commands in startup-config file. If it finds these commands, it will run boot system commands in order they appear in startup-config to locate the IOS. If not, the IOS image is loaded from Flash . If the IOS is not found in Flash, the bootstrap can try to load the IOS from TFTP server or from ROM (mini-IOS).
4. After the IOS is found, it is loaded into RAM.
5. The IOS attempts to load the configuration file (startup-config) from NVRAM to RAM. If the startup-config is not found in NVRAM, the IOS attempts to load a configuration file from TFTP. If no TFTP server responds, the router enters Setup Mode (Initial Configuration Mode).
Cisco_Boot_Sequence.jpg
And this is the process we can see on our screen when the router is turned on:
Cisco_router_boot_process.jpg
In short, when powered on the router needs to do:
1. Run POST to check hardware
2. Search for a valid IOS (the Operating System of the router)
3. Search for a configuration file (all the configurations applied to this router)
Specify how much RAM, NVRAM and Flash of a router
Also, from the information shown above, we can learn some information about router’s model, RAM, Flash, NVRAM memories as shown below:
RAM_ROM_Flash_memory.jpg
Note: The “show version” command also gives us this information.
All the above information is straight-forwarding except the information of RAM. In some series of routers, the RAM information is displayed by 2 parameters (in this case 60416K/5120K). The first parameter indicates how much RAM is in the router while the second parameter (5120K) indicates how much DRAM is being used for Packet memory. Packet memory is used for buffering packets.
So, from the output above we can learn:
Amount of RAM: 60416 + 5120 = 65536KB / 1024 = 64MB
Amount of NVRAM: 239KB
Amount of Flash: 62720K

Monday 6 January 2014

OSPF Router Types:

There are four types of OSPF routers. Router types are determined by a router’s function and/or location 
within an OSPF area:
Internal (IR) – all (OSPF?)* interfaces must belong to the same OSPF area.
Backbone – at least one OSPF interface must belong to area 0 (backbone area)
Area Border Router (ABR) – at least one OSPF interface must belong to area 0 (backbone area) and at least 
one OSPF interface must belong to a non-backbone (area 0) area.
Autonomous System Boundry Router – an OSPF router that performs route injection (redistribution) from 
another route source (RIP, EIGRP, IS-IS, BGP, another OSPF process, etc.).
* An area is interface specific. A router that has all of its interfaces within the same area is called an internal 
router (IR) – Cisco OSPF Design Guide 
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml 

 














Verification Command:

To verify a device’s OSPF router type, use the show ip ospf command. This command will tell you if an OSPF router is an Area 
Border Router(ABR) or an Autonomous System Boundry Router(ASBR). It will not identify Internal or Backbone routers, but if 
an OSPF router is not an ABR or ASBR, then it is an Internal router. If it’s not an ABR or an ASBR and it’s in area 0, then it’s a 
Backbone router.

r2#show ip ospf

Routing Process "ospf 1" with ID 2.2.2.2
Start time: 01:16:41.316, Time elapsed: 00:08:53.116
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border router
<--- output truncated --->
r1#show ip ospf | i It is
It is an autonomous system boundary router
r2#show ip ospf | i It is
It is an area border and autonomous system boundary router

Summary:

There are four types of OSPF routers which are determined by a router’s function and/or location within an 
OSPF area:
Internal (IR) – all OSPF interfaces must belong to the same OSPF area.
Backbone – at least one OSPF interface must belong to area 0 (backbone area)
Area Border Router (ABR) – at least one OSPF interface must belong to area 0 (backbone area) and at least 
one OSPF interface must belong to a non-backbone (area 0) area.
Autonomous System Boundry Router (ASBR) – an OSPF router that performs route injection (redistribution) 
from another route source (RIP, EIGRP, IS-IS, BGP, another OSPF process, etc.). 
You can use the show ip ospf EXEC command to identify which OSPF type(s) your device is currently 
configured as.



Saturday 4 January 2014

What Makes a Router an OSPF ABR: Cisco Juniper Comparison

This blog is not directly tied to any topics related to CCIE studies, but it can be useful. It’s more of a general networking post. I had fun researching this information and decided it would be a nice thing to share with experts such as our readers.
In the Packet Pushers Podcast episode 89 (OSPF vs IS-IS Smackdown – Where You Can Watch Their Eyes Reload) published few months ago, I made few statements about border routers in both OSPF and IS-IS and their differences. This prompted some disagreement on the panel consisting of Ivan Pepelnjak of NIL, Petr Lapukhov of Microsoft, host Greg Ferro and myself. In this post, I’ll examine OSPF issues and follow-up with IS-IS in the next.
For the purpose of this testing, I will use the network of three routers connected in a “chain”. I will not change this network layout, only the configuration of the routing protocols, as required. Even though both IOS and Juniper configurations are completed in production ProctorLabs racks, I gave routers fictional names to avoid slight router numbering differences between our Cisco and Juniper racks.
OSPF on IOS
OSPF on Junos
Lab time!
One of the statements I made about OSPF was that OSPF router connected to two areas will not act as an ABR, i.e. the “B” bit in its type 1 LSA will not be set unless one of the areas is the backbone area 0.0.0.0. Petr mentioned it might be a Cisco specific behavior and given my recent Junos interest this was a perfect thing to test. The problem basically, boils down to how different vendors implement RFC3509.

OSPF Border in IOS

Here are the relevant initial configurations for our three Cisco routers. To make configurations as similar to the subswquent Juniper configurations, I will use subinterfaces in IOS. There is no other reason to do it.
R1:
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.12
 encapsulation dot1q 12
 ip address 192.168.12.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 1.1.1.1
 passive-interface Loopback0
 network 1.1.1.1 0.0.0.0 area 12
 network 192.168.12.0 0.0.0.255 area 12
!
R2:
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.12
 encapsulation dot1q 12
 ip address 192.168.12.2 255.255.255.0
 ip ospf network point-to-point
!
interface FastEthernet0/1.23
 encapsulation dot1q 23
 ip address 192.168.23.2 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 2.2.2.2
 network 192.168.12.0 0.0.0.255 area 12
 network 192.168.23.0 0.0.0.255 area 23
!
R3:
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.23
 encapsulation dot1q 23
 ip address 192.168.23.3 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 3.3.3.3
 passive-interface Loopback0
 network 3.3.3.3 0.0.0.0 area 23
 network 192.168.23.0 0.0.0.255 area 23
!
As we can see, routers R1 and R2 are neighbors in area 12, and routers R2 and R3 are neighbors in area 23. Does this make R2 and ABR? The discussion in the podcast revolved around Cisco-specific behavior in this case. Let’s check what R2 thinks about its situation.
Information whether a router is an ABR is carried in Router (Type 1) LSA as a “B” bit. If this bit is set to 1, router is an ABR. IOS will translate this bit into a helpful “Area Border Router” message. So, to get this information, I will have to check the OSPF database and read Router LSAs originated by R2. Since R2 will have both area 12 and area 23 databases even if it’s not an ABR, I will truncate the output for the sake of brevity.
R2:
R2#show ip ospf database router self-originate

            OSPF Router with ID (2.2.2.2) (Process ID 1)

  Router Link States (Area 12)

  LS age: 663
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x53CD
  Length: 48
  Number of Links: 2

[...]

  Router Link States (Area 23)

  LS age: 646
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xFF3
  Length: 48
  Number of Links: 2

[...]
In the output above, there is no trace of the “B” bit being set. As further proof of this, let’s see if the route for 192.168.23.0/24 can be seen in the routing table on R1. If R2 was an ABR, we’d see this route.
R1:
R1#show ip route 192.168.23.0
% Network not in table
This is what I expected to see. It’s clear that IOS doesn’t consider R2 to be an ABR. This is a very important concept to remember when preparing for your CCIE, as at first glance it appears that R2 is an ABR. At this moment, we don’t have reachability between networks advertised by R1 and R3. How can we repair this situation? We will need to make R2 and ABR. In Cisco IOS, ABR is the router that has interfaces in area 0.0.0.0 and one or more other areas. Remedy of the situation is therefore rather simple. We’ll advertise R2′s Loopback0 into OSPF area 0 and see if that changes anything.
R2:
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
!
R1:
R1#show ip route 192.168.23.0
Routing entry for 192.168.23.0/24
  Known via "ospf 1", distance 110, metric 2, type inter area
  Last update from 192.168.12.2 on FastEthernet0/1.12, 00:38:38 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:38:38 ago, via FastEthernet0/1.12
      Route metric is 2, traffic share count is 1

R1#show ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/3] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
O IA 192.168.23.0/24 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
We now have the OSPF routes on R1. As a final confirmation of my position, let’s take a look at R2′s OSPF database. I will truncate it again, as I’m interested only in LSA headers.
R2:
R2#show ip ospf database router self-originate

            OSPF Router with ID (2.2.2.2) (Process ID 1)

  Router Link States (Area 0)

  LS age: 377
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xA770
  Length: 36
  Area Border Router
  Number of Links: 1

[...]

  Router Link States (Area 12)

  LS age: 377
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x52CB
  Length: 48
  Area Border Router
  Number of Links: 2

[...]

  Router Link States (Area 23)

  LS age: 379
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0xEF1
  Length: 48
  Area Border Router
  Number of Links: 2

[...]
Clearly, just adding one interface into area 0 caused R2 to behave as an ABR. I wonder, how will Junos act in the same situation?

OSPF Border in Junos

Here are the relevant configurations from our Juniper routers. I have tried to replicate the configuration as much as I could. Since all logical configuration on Junos must be done on logical link units, including loopback (lo0) interface, some differences still exist. They are minor though.
R1:
interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 12 {
            vlan-id 12;
            family inet {
                address 192.168.12.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 1.1.1.1/32;
            }
        }
    }
}
routing-options {
    router-id 1.1.1.1;
}
protocols {
    ospf {
        area 0.0.0.12 {
            interface fe-0/0/1.12 {
                interface-type p2p;
            }
            interface lo0.0 {
                passive;
            }
        }
    }
}
R2:
interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 12 {
            vlan-id 12;
            family inet {
                address 192.168.12.2/24;
            }
        }
        unit 23 {
            vlan-id 23;
            family inet {
                address 192.168.23.2/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 2.2.2.2/32;
            }
        }
    }
}
routing-options {
    router-id 2.2.2.2;
}
protocols {
    ospf {
        area 0.0.0.12 {
            interface fe-0/0/1.12 {
                interface-type p2p;
            }
        }
        area 0.0.0.23 {
            interface fe-0/0/1.23 {
                interface-type p2p;
            }
        }
    }
}
R3:
interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 23 {
            vlan-id 23;
            family inet {
                address 192.168.23.3/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 3.3.3.3/32;
            }
        }
    }
}
routing-options {
    router-id 3.3.3.3;
}
protocols {
    ospf {
        area 0.0.0.23 {
            interface fe-0/0/1.23 {
                interface-type p2p;
            }
            interface lo0.0 {
                passive;
            }
        }
    }
}
Let’s start the verification by looking for OSPF routes on R1.
R1:
ipexpert@R1> show route protocol ospf

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

3.3.3.3/32         *[OSPF/10] 01:18:39, metric 2
                    > to 192.168.12.2 via fe-0/0/1.12
192.168.23.0/24    *[OSPF/10] 01:26:19, metric 2
                    > to 192.168.12.2 via fe-0/0/1.12
224.0.0.5/32       *[OSPF/10] 01:26:43, metric 1
                      MultiRecv
That came almost unexpected. All the routes are there. I can see both R3′s link to R2 and the loopback interface. I can even ping…
R1:
ipexpert@R1> ping rapid 3.3.3.3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!!!
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.509/1.999/2.544/0.349 ms
It looks like R2 is performing ABR duties even without having any interfaces in the backbone area. Let’s confirm that by looking into the OSPF database.
Unlike IOS, Junos is a little bit more cryptic about ABR status by virtue of not converting bit values into mnemonics. We’ll have to decipher VEB bit-field manually. The bit we’re after, the B-bit has bit-value of 1. Let’s take a look.
R2:
ipexpert@R2> show ospf database router advertising-router self area 12 detail

    OSPF database, Area 0.0.0.12
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *2.2.2.2          2.2.2.2          0x80000005  1145  0x22 0x50cc  48
  bits 0x1, link count 2
  id 1.1.1.1, data 192.168.12.2, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 192.168.12.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 1
  Topology default (ID 0)
    Type: PointToPoint, Node ID: 1.1.1.1
      Metric: 1, Bidirectional
Indeed, bit-field shows value 0×01, which translates into B-bit being set. R2 is an ABR! Therefore, in Junos there is no need for a router to be connected to the backbone area to perform ABR duties (generate Type 3 summary LSAs between areas).
This is still a broken configuration. It only has an appearance of being fully operational, but adding a single interface in area 0 on either R1 or R3 would render those networks unreachable beyond quasi-ABR R2. I will leave this for another time though…