CCIE R&S Written : Layer 3 Technologies

ARP

ARP -ARPA is the encapsulation for Ethernet -SNAP is encapsulation for Token Ring and FDDI

DHCP Operations

DHCP Operations -DHCP Discovery - When a client (PC) is booted, it broadcasts a DHCP Discover message over the Ethernet network to locate all available DHCP servers on the same subnet network (by setting the destination MAC address in the Ethernet header as Broadcast MAC=FF:FF:FF:FF:FF:FF), reaching all the DHCP servers on the same subnet network. Broadcast will be at layer 2 and layer 3 e.g. ff:ff:ff:ff:ff:ff and 255.255.255.255 on UDP port 68 -DHCP Offer - When a DHCP server receives the DHCP Discover message from the client, it also broadcasts a DHCP Offer message over the Ethernet network (because the client IP address has not been allocated yet), informing the client that it is available. This message contains the network information, such as client IP address, subnet mask, default gateway IP address, DNS IP address, IP lease time and DHCP server IP address. The DHCP Offer message broadcasted is delivered to all the clients on the same subnet network, including the one that sent the DHCP Discover message. -DHCP Request - The client, having received the DHCP Offer message, recognizes there is a DHCP server available on the same subnet. Then it broadcasts a DHCP Request message to the server over the Ethernet network, requesting network configuration data including an IP address for itself. -DHCP Acknowledgement - The DHCP server which received the DHCP Request message from the client checks if the IP address shown in the DHCP Server Identifier (option 54) field matches its own. If it does, it broadcasts a DHCP Ack message ensuring the client can receive the message -IP Renewal Process - after the lease time expires, a DHCP client will request to renew the IP address for an extended period. This is accomplish with only the DHCP Request and DHCP Acknowledge messages to the servers unicast IP and MAC. When half of the lease time set through "IP address allocation/lease" procedure has passed, it unicasts a DHCP Request message to the DHCP server for renewal of its IP address. The DHCP server, upon receiving the DHCP Request message, accepts the request by responding with a unicast DHCP Ack message. -IP Release process - If the client does not need its allocated IP address any longer, it unicasts a DHCP Release message (Destination MAC=DHCP Server MAC (m2), Destination IP=DHCP Server IP (1.1.1.254)) to the DHCP server. DHCPv6 -Stateful DHCPv6 - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been standardized by the IETF through RFC3315. DHCPv6 enables DHCP servers to pass configuration parameters, such as IPv6 network addresses, to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration". Configured with "ipv6 nd managed-config-flag" and "ipv6 nd other-config-flag" set on the interface -Stateless DHCPv6 - When using stateless-DHCPv6, a device will use Stateless Address Auto-Configuration (SLAAC) to assign one or more IPv6 addresses to an interface, while it utilizes DHCPv6 to receive "additional parameters" which may not be available through SLAAC. For example, additional parameters could include information such as DNS or NTP server addresses, and are provided in a stateless manner by DHCPv6 -DHCPv6-PD - DHCPv6-PD is aimed at assigning complete subnets and other network and interface parameters from a DHCPv6-PD server to a DHCPv6-PD client. This means that instead of a single address assignment, DHCPv6-PD will assign a set of IPv6 "subnets". -DHCPv6 uses an architecture concept of "options" to carry additional parameters and information within DHCPv6 messages. These options are aligned in the TLV (Type-Length-Value) structure. - Each DHCPv6 component has a DUID (DHCPv6 Unique Identifier) which is used to identify the device when exchanging DHCPv6 messages -Each DHCPv6 client and server is identified by a DHCP unique identifier (DUID) -The device uses the MAC address from the lowest-numbered interface to form the DUID. -DHCPv6 messages are exchanged over UDP port 546 and 547. Clients listen for DHCP messages on UDP port 546 while servers and relay agents listen for DHCP messages on UDP port 547. -reserved link-local "ff02::1:2" (All DHCPv6 relay agents and servers) and site-local "ff05::1:3" (All DHCPv6 Servers) multicast addresses. -The DHCPv6 Client-Server exchange can be completed by either a 2(rapid-commit) or 4 message exchange Remove-private-as -private AS range 64512-65535 -configured on the neighbor that receives the outbound updates from the local router

EIGRP

EIGRP Over The Top (OTP) -EIGRP OTP (Over the Top) allows you to run EIGRP between routers that are not directly connected -An EIGRP targeted adjacency between CEs is created. This EIGRP neighborship is done via unicast packets -OTP uses EIGRP control packets on the control plane and LISP for the data plane to allow for EIGRP neighbor peering between neighbors that are separate over the WAN, without relying on the ISP transportation -OTP does not provide for dynamic discovery of other peers. Instead it relies on manual configuration to specify which routers peer with which routers using the "neighbor" option under EIGRP. OTP supports two modes, point-to-point for finer control, and route-refactor for greater scaling. -OTP Point-To-Point - peers directly with neighbor, use of the "neighbor" command -OTP Route Reflector - uses a route reflector to peer with multiple neighbors, use of "source" and "unicast-listen lisp-encap" command. OTP will reflect routes from neighbors without changing the next-hop address to itself and without changing the metric as well! -CEs peer with RRs, only is used and RRs reflect the routes they receive to other CEs. Each CE is configured with the RRs WAN address and each RR is configured in EIGRP promiscuous mode, i.e. to accept incoming 'connections' (similar to BGP listen feature) -RR reflects the routes untouched, i.e. without changing the metric, and keeping next-hop unchanged (no next-hop-self). -OTP does NOT use LISP control plane (map server/resolver, etc.) instead it uses EIGRP to exchange routes and provide the next-hop, which LISP encapsulation uses to reach remote prefixes. -OTP can be configured to preserve the next-hop address of the advertising site when routing information is sent to other sites using the "no next-hop-self" configuration under EIGRP -OTP could be used with DMVPN to have Hub and Spoke topology as well -Unlike regular EIGRP rules, metric is modified before being sent out to the OTP neighbor and the receiving router does NOT modify metric. This means delay needs to be modified on the egress CE LISP interface (not on ingress CE)! -On the data plane, LISP uses UDP to encapsulate data and tunnel traffic. EIGRP OTP only uses LISP for the data plane, EIGRP is used for the control plane. Wide Metric -to improve accuracy by increase metric calculation granularity -The 64-bit wide metric calculations work only in EIGRP named mode configurations. EIGRP classic mode uses 32-bit metric calculations. -only supported in EIGRP Named Mode Multicast Flow Timer, RTO, and SRTT -when a reliable multicast packet is sent and an ACK is not received, the local device will start sending reliable unicast packets out -Multicast Flow Timer—Maximum number of seconds that the router will wait for an ACK packet after sending a multicast EIGRP packet, before switching from multicast to unicast -Reliable Timeout (RTO) - Is the time for how long to wait to receive a unicast ACK before sending another unicast ACK, max 16 ACK possible, and max RTO 5000ms -Smooth Round Trip Time (SRTT) - The total time it takes for a packet to travel to a neighbor a for an ACK to be delivered back. There is a proprietary equation to determine this. -Query multicast packet is sent out an interface on a subnet, a neighbor on the subnet doesn't respond. After the Multicast Flow Timer expires, the local router will send out a unicast Query to the neighbor. Then after the RTO timer expires, another unicast Query is sent. Maxed reliable packet sent without ACK is 16. Troubleshoot EIGRP -check mismatch K values -check ACLs -ping 224.0.0.10 to check which neighbor responding -check EIGRP enabled interfaces -check Hello and Hold timers -check authentication -check CPU utilization, could cause SIA Queries to not receive replies -check layer 2 reachability -check layer 3 Ping test between neighbors -check neighbor next-hop reachability -check if subnets are matching, mismatch subnet will not work -check steps on local router and neighbor -check misconfigured Ip address -check mismatch AS numbers -check SIA Query -"show ip eigrp topology active" command will show what routes are in the Active state -the "r" on the show ip eigrp topology active means that the neighbor has not replied to the query Metric -Delay is cumulative along the path a prefix takes, i.e. delay of all interfaces are in the metric equation -Bandwidth is not cumulative, the metric is only used on the local device Variance -second non-successor route must be a feasible successor and also the metric of the feasible successor must be less than the total of the successor metric multiplied by the variance number configured -a feasible successor is if the reported distance of the non-successor route is less than current successor's metric, it can't be equal as well. Graceful Shutdown -A graceful shutdown is a router's way of telling its neighbor to end the adjacency with the router because the EIGRP routing process is disabled. The change converges more quickly than allowing each device to reach its hold interval, which is by default fifteen seconds on fast links. A graceful shutdown is a special Hello goodbye message sent out of each interface running EIGRP. The goodbye message is a form of a Hello message, but with all five K-values set to 255. -Goodbyes are transmitted by an EIGRP router to its peer whenever a neighbor adjacency fails but the interface to reach that neighbor is still up. I.e. I'm not hearing any Hellos from you, so I'll send you a Goodbye message Add-Path -The EIGRP Add Path Support is a feature that allows the hub in a DMVPN topology to advertise multiple best paths to its spoke routers. This feature is needed if you have two or more spoke routers that advertise the same subnet. The hub router will learn about the subnet from both spoke routers so it can use ECMP (Equal Cost Multipath) with both spoke routers. -by default, EIGRP advertises only one path as the best path to connected spokes. With the implementation of the Add Path Support in EIGRP feature, hubs in an EIGRP-DMVPN domain can advertise up to four additional best paths to connected spokes, thereby allowing load balancing and path redundancy. -before you configure this feature on a hub device in a Dynamic Multipoint VPN (DMVPN) domain, you must disable the next-hop-self command that is configured on the hub interface that connects to spokes in the DMVPN domain. Named Mode -One thing to be aware of in regards to the named mode is that configuration of the address-family does not enable IPv4 routing as a traditional configuration of IPv4 EIGRP. A 'no shut' is required in order to start the process: router eigrp [virtual-instance-name | asystem] [no] shutdown -only a single instance of EIGRP needs to be created. It can be used for all address family types. It also supports multiple VRFs limited only by available system resources. -There is an automatic method to convert the configuration from the traditional way to the new method. Inside the EIGRP process, the command "eigrp upgrade-cli <EIGRP Virtual-Instance Name>" needs to be entered. This automatically converts the configuration to the named mode without an impact to the established EIGRP peering LFA -EIGRP always computes prefix-based LFAs.

Fundamental Routing Concept

Fundamental Routing Concept - static route -a static route will not install if it is self recursive I.e. /30 pointing to /24 which points to an interface -The following example shows that using the dhcp keyword in a configuration of Ethernet interfaces 1 and 2 enables the interfaces to obtain the next-hop router IP addresses dynamically from a DHCP server: ip route 10.165.200.225 255.255.255.255 ethernet1 dhcp ip route 10.165.200.226 255.255.255.255 ethernet2 dhcp 20 -"permanent" keyword in static route will cause route to install regardless if next-hop interface is up or not -The following ip route vrfcommands are supported when you configure static routes in an MPLS VPN environment, and the next hop is in the global table in the MPLS cloud in the global routing table. For example, these commands are supported when the next hop is pointing to the Internet gateway. But "global" next-hop not supported for load-balancing ip route vrf vrf-name [destination-prefix mask] [next-hop-address] global Default routing -The ip default-gateway command differs from the other two commands. It should only be used when ip routing is disabled on the Cisco router. -Unlike the ip default-gateway command, you can use ip default-network when ip routing is enabled on the Cisco router. When you configure ip default-network the router considers routes to that network for installation as the gateway of last resort on the router. -The ip default-network command is classful. This means that if the router has a route to the subnet indicated by this command, it installs the route to the major net. -The ip default-network command must be issued, using the major net, in order to flag the candidate default route. -For IGRP and EIGRP to propagate the route, the network specified by the ip default-network command must be known to IGRP or EIGRP. This means the network must be an IGRP- or EIGRP-derived network in the routing table, or the static route used to generate the route to the network must be redistributed into IGRP or EIGRP, or advertised into these protocols using the network command. -The default route announced using the ip default-network command is not propagated by Open Shortest Path First (OSPF) or IS-IS Administrative Distance -when two different routing protocols are configured to have same AD, the router will internally fall back to the default administrative distances to decide which route is more preferred VRF Lite -VRF-lite does not support IGRP and ISIS. -VRF-lite interfaces must be Layer 3 interfaces. IPv4-Specific VRF-lite does not support IGRP and ISIS. IPv6-Specific VRF-aware ISISv6, RIPng, IPv6 Multicast Routing (MVRF), and PIMv6 are not supported. -VRF-lite interfaces must be Layer 3 interfaces Policy-Based Routing The "set ip default next-hop" command verifies the existence of the destination IP address (of the transit ip packet)in the routing table, and... -if the destination IP address network in the ACL in the PBR exists in the RIB, the command does not policy route the packet, but forwards the packet based on the routing table. When the destination route exists in the routing table, normal forwarding is used—do not policy route the packet. -if the destination IP address does not exist, the command policy routes the packet by sending it to the specified next hop. ! access-list 100 permit ip host 200.200.200.4 host 100.100.100.3 ! route-map blah permit 10 match ip address 100 set ip default next-hop 10.10.10.1 —-if the destination 100.100.100.3 is in rib, don't PBR. If not in rib, do PBR! The "set ip next-hop" command verifies the existence of the next hop specified, and... -if the next hop exists in the routing table, then the command policy routes the packet to the next hop. -if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet. -When the only route to the destination is the default route—there is no specific route for destination in the ACL in PBR in the routing tale—the packet is policy routed. BFD -version 0 only sends out Control Packets, version 1 sends out echo packets -timers are for echo packets -Control-plane packets are sent, but they are sent at the "slow timers" speed, specified as: bfd slow-timers <speed> -There are two modes, asynchronous and demand. Asynchronous is the "normal" BFD mode that you're used to when you think Cisco BFD: continuous, high-speed detection of neighbor failure. Asynchronous Mode depends on the sending of BFD control packets between two systems to activate and maintain BFD neighbor sessions between routers. The demand mode is different, once BFD has found a neighbor it won't continuously send control packets but only uses a polling mechanism. Demand mode is more of a steady-state operation, where it's assumed the neighbor and link are generally stable, but you'd periodically want to check to see if it's up. Cisco does not support demand mode. -both control packet (3784) and echo (3785) uses UDP -BFD usually only operates for single-hop neighbors, could be for static or dynamic routing -BFD multihop does not support echo mode. Authentication - HMAC-SHA-256 The device sending a packet calculates the hash to be sent based on the following: -Key part 1—the configured shared secret. -Key part 2—the local interface address from which the packet will be sent. -Data—the EIGRP packet to be sent (prior to the addition of the IP header). For successful authentication, all of the following must be true: -The sender and receiver must have the same shared secret. -The source address chosen by the sender must match the source address in the IP header that the receiver receives. -The EIGRP packet data that the sender transmits must match the EIGRP packet data that the receiver receives. Authentication cannot succeed if any of the following is true: -The sender does not know the shared secret expected by the receiver. -The IP source address in the IP header is modified in transit. -Any of the EIGRP packet data is modified in transit. OSPFv3 IPsec Authentication -OSPFv3 uses the IPsec secure socket API to add authentication to OSPFv3 packets. -To configure IPsec, you configure a security policy, which is a combination of the security policy index (SPI) and the key (the key is used to create and validate the hash value). IPsec for OSPFv3 can be configured on an interface or on an OSPFv3 area

IPv4 Multicast

IPv4 Multicast Boundary -interface command "ip multicast boundary..." -239.0.0.0/8 defined are for private local LAN IPv4 multicast addresses not to be leaked out to the Internet. 239.0.0.0/8 are administratively-scoped addresses. This range of addresses can then be reused in domains administered by different organizations. The addresses would be considered local, not globally unique. -use standard ACL to permit/deny multicast destination addresses i.e. deny 225.1.1.1 -use extended ACL to permit/deny multicast source and destination addresses PIMv6 -uses Anycast RP with IPv6 PIM-SM for intradomain multicast routing -An IPv6 multicast address is an IPv6 address that has a prefix of FF00::/8 -A multicast address that has the scope of a node, link, site, or organization, or a global scope has a scope parameter of 1, 2, 5, 8, or E -The anycast RP solution in IPv6 PIM allows an IPv6 network to support anycast services for the PIM-SM RP. It allows anycast RP to be used inside a domain that runs PIM only -A unicast IP address is chosen as the RP address. This address is either statically configured or distributed using a dynamic protocol to all PIM devices throughout the domain -A set of devices in the domain is chosen to act as RPs for this RP address; these devices are called the anycast RP set. Each device in the anycast RP set is configured with a loopback interface using the RP address. Each device in the anycast RP set also needs a separate physical IP address to be used for communication between the RPs. Each device in the Anycast set must contain the list of all the devices in the Anycast set. Troubleshoot PIM -"show ip mroute" -"show ip rpf..." All preceding sources of RPF data are searched for a match on the source IP address. When you use Shared Trees, the RP address is used instead of the source address. -if more than one matching route is found, the route with the lowest administrative distance is used. -If the administrative distances are equal, then this order of preference is used: Static mroutes DVMRP routes MBGP routes Unicast routes -"show ip pim interface" -"show ip pim neighbor" to check if the routers are PIM neighbors or not -Check unicast route back to multicast source IP address is acceptable for unicast RPF checks -check RP address and mcast group filtering -"show ip rpf source (source IP)" to check if the route back to the unicast source is consistent with the incominng mcast traffic. -check PIM interface and neighbor relationship -check mcast TTL thresholds -check mcast boundaries -check mcast static routes or unicast static routes -check access-list filtering -"ip pim rp-address [rp ip] [ACL to permit/deny mcast group] override" -the override on the PIM command tells the local router to use the static RP over the dynamically learned RP info from Auto-RP or BSR. By default, dynamically learned RP addresses are preferred over static RP that are configured. PIM RPF on Tunnel -on PIM Dense mode, make sure router is pointing to the correct tunnel interface towards the source for (S,G). Could be done via static or dynamic routes, but source for (S,G) group must be towards tunnel -on PIM Sparse mode, for RPF checks to pass, point towards (*,G) entry and towards RP by pointing to the tunnel interface -use commands "show ip igmp groups" on the Querier router side to check there are joined receivers for the mcast group. Check "show ip mroute (mcast group IP)" to check for source incoming and group outgoing interfaces are correct. Use "show ip mroute count" to check if there are incoming mcast packets or if there are RPF drops. PIM Dense Mode -PIM dense mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network. This push model is a method for delivering data to the receivers without the receivers requesting the data. -PIM-DM builds source-based multicast distribution trees i.e. (S,G) entries in mroute table -PIM-DM initially floods multicast traffic throughout the network. Routers that have no downstream neighbors prune back the unwanted traffic. This process repeats every 3 minutes. PIM sparse mode: this is a "pull" model where we only forward multicast traffic when requested. PIM dense mode: this is a "push" model where we flood multicast traffic everywhere and then prune it when it's not needed PIM Sparse-Dense Mode -Sparse mode and dense mode are properties of a group, as opposed to an interface. - An interface configured in sparse-dense mode is treated in either sparse mode or dense mode of operation, depending on which mode the multicast group operates. If a multicast group has a known RP, the interface is treated in sparse mode. If a group has no known RP, by default the interface is treated in dense mode and data will be flooded over this interface. -If a PIM router or multilayer switch has a source-tree state (that is, an (S, G) entry is present in the multicast routing table), it performs the RPF check against the IP address of the source of the multicast packet. -If a PIM router or multilayer switch has a shared-tree state (and no explicit source-tree state), it performs the RPF check on the RP address (which is known when members join the group). -A group specified as dense is not mapped to an RP. Instead, data packets destined for that group are forwarded by means of PIM dense-mode rules. A group specified as sparse is mapped to an RP, and data packets are forwarded by means of PIM sparse-mode rules. Bidir-RP -only the Designated Forwarder is responsible for forwarding multicast traffic towards the RP and for processing Joins and Leave messages -When a router receives a Join or Leave message, and the router is not the DF for the receiving interface, the message is ignored. -DF election is based on best unicast route selection towards the IP of the RP -only the router that is elected the DF on a network segment forwards traffic upstream towards the RP, if a non-DF router receives traffic destined to the RP it will discard the packet PIM BSR -Highest Priority elected the BSR -if priority is tied, highest IP address on interface on the router is elected BSR First Route DR -Enter these commands on the first hop router to verify IP multicast operations on the first hop router: "show ip mroute active" to display active source traffic MSDP -by default SA are not cached, but can be configured to do so. -SA needs to be cached by MSDP peer in order for local router to send the peer SA Requests -SA Request used by router when there is receiver that wants traffic from source but local router doesn't have SA cached for (S,G). But if you cache the information, you need not trigger a SA request for it. - However, you can configure the router to ignore all SA request messages from an MSDP peer. Or, you can honor only those SA request messages from a peer for groups described by a standard access list. e.g. ip msdp filter-sa-request {peer-address | peer-name} list access-list -SA messages are originated on RPs to which sources have registered. By default, any source that registers with an RP will be advertised. The "A flag" is set in the RP when a source is registered. This flag indicates that the source will be advertised in an SA unless it is filtered by command : ip msdp redistribute [list access-list] [asn as-access-list] [route-map map-name], or ip msdp sa-filter -"ip msdp redistribute [list access-list] [asn as-access-list] [route-map map-name]" filters only to domain local learned SA entries! I.e. sources from my domain that register to me, the RP! -"ip msdp sa-filter [in/out]" will filter both locally originated and learned SA from peers! -You can use TTL to control what data will be encapsulated in the first SA message for every source. For example, you could limit internal traffic to a TTL of 8. If you want other groups to go to external locations, you would need to send those packets with a TTL greater than 8. -An MSDP mesh group is a group of MSDP speakers that have fully meshed MSDP connectivity between one another. Any SA messages received from a peer in a mesh group are not forwarded to other peers in the same mesh group -By default, sources in the dense mode region are not included in MSDP. Only sources from PIM SM. To bypass configure : ip msdp border sa-address type number

IPv6 General Prefixes

IPv6 General Prefixes -The IPv6 generic prefix feature simplifies network renumbering and allows for automated prefix definition. An IPv6 generic (or general) prefix (for example, /48) holds a short prefix, based on which a number of longer, more-specific prefixes (for example, /64) can be defined. When the general prefix is changed, all of the more-specific prefixes based on it will change, too.

BGP

Neighbor States -Idle: the neighbor hasn't started an initiation yet, once the commands are in place such as the "neighbor" command, this will start the process -Connect: the neighbor is listening for TCP connection. It will not initiate the TCP connection with Open message. If the 3-way handshake is completed at this phase, then it will send an Open message and transition to OpenSent state. If not, it will go to Active state -Active: the neighbor will actively initiate a TCP connection, once completed it will send out an Open message. -OpenSent: the neighbor has received an Open message that has all the BGP parameters configured. If the parameters are accepted between local router and neighbor, then router will send out Keepalive and transition to OpenConfirm state, if parameters fail, then go back to Idle state -OpenConfirm: router in this state will wait for the Keepalive message from neighbor, if Keepalive message is received, then transition to Established state. -Established: BGP neighbors are fully established and neighbors can exchange Updates, Keepalives, and Notifications. Route Reflector -Originator ID: is the router ID of the originating router that the RR learned the route from, it is an optional non-transitive attribute. RR will not advertise a route back to the originator and it knows this by examining the originator ID field on the NLRI. Router's that see their ID in the originator ID will not install the NLRI. -Cluster ID: each cluster has a unique Cluster ID, which identifies the group itself. If there is only one RR, the cluster ID is the router ID of the RR. If there are more than one RR in the cluster, then the cluster ID must be manually define through configuration. A Cluster ID is PREPENDed to the Cluster List of an NLRI when it is advertised from a client to a non-client. If an RR receives an Update, if it see's the Cluster ID of it's own cluster (could be its router ID or manually defined) in the Cluster List field then it will ignore the update. This is to avoid potential routing loops. BGP Atomic Aggregate -signifies a loss of information in the aggregated route -when using command "aggregate-address..." without the AS-Set command, it will set the Atomic Aggregate flag, the router that receive the NLRI will know that there is a loss of information in the NLRI Aggregate, specifically means that all the attributes that make up the aggregate are not advertised along with the aggregate. -when configured aggregate with AS-Set command, the atomic aggregate flag will not show Local-AS -pretend to be a different AS when peering with an eBGP neighbor -"neighbor local-as no-prepend" when the local-as command is used, the local router will advertise outbound an NLRI with AS numbers from both it's real AS and the pretend AS. What this means is that the eBGP neighbor will see route x.x.x.x with AS numbers from both the pretend and real AS. Also, this means that any incoming routes received by the local router (that is configured with local-as) from the eBGP neighbor it will send the route with the real and pretend AS#s i.e. eBGP neighbor advertises "network x.x.x.x" to neighbor with local-as configured, neighbor with local-as configured will see route x.x.x.x with the pretend AS attached as well! The "no-prepend" config only applies to inbound updates. It makes it so that when the eBGP neighbor sends a route to the router with the "local-as no-prepend" configured, the route will not have the pretend AS attached on the NLRI. The local-as router when it receives an inbound update from the eBGP neighbor it will not see the pretend AS in the route. -"neighbor local-as no-prepend replace-as" will tell the local router to advertise to its eBGP neighbor routes but only with the the pretend AS number in the route, it won't attach the real AS with the route to the eBGP neighbor -"neighbor local-as no-prepend replace-as dual-as" means that the eBGP neighbor can peer with the local router using either the real AS or the pretend AS Route Reflector -Multiple Cluster ID (MCID) allows new features for RR clusters -it is possible to disable reflection from Intra-clients to other intra-clients. It is also possible to disable reflection to all clients, intra and inter, and only enable reflection to non-clients. However, it is not possible to only disable inter-clients and enable intra-clients -A route learned from an EBGP neighbor can be forwarded to another EBGP neighbor, a client and non-client. A route learned from a client can be forwarded to another EBGP neighbor, client and non-client. A route learned from a non-client can be forwarded to another EBGP neighbor and client, but not to a non-client. -a cluster is a group consisting of RR and client, and contains at least one RR and a client. -Before reflecting a route, route reflectors PREPEND its cluster ID to the cluster list. If the route is originated from the route reflector itself, then route reflector does not create a cluster list. -If the route is sent to eBGP peer, RR removes the cluster list information. -If the route is received from eBGP peer, RR does not create a cluster list attribute when it advertises to clients or non-clients -Cluster list is used for loop prevention by only the route reflectors. Route reflector clients do not use cluster list attribute, so they do not know to which cluster they belong. Only RRs look at the cluster-ID list to check if it sees its own router-ID in the update, and if this is the case it will discard the packet -Originator-ID; All router's that see its own Router ID in an Update message will discard the packet. -When an RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it MUST create a new one. Regular Expressions ^[0-9]+ ( [0-9]+)?$ -this expression means to match any directly connected neighbors OR optional to match directly connected neighbors plus any of their directly connected neighbors only as well -the "?" regexp means zero or one instance, in the example the ( [0-9]+)? means that you can either match any AS number or you do not have to match it i.e. it could be an AS number or it could be null -so the expression would equate to matching "100" or matching "100 200", "100 300", "100 400", etc. BGP Load Balancing -The BGP Multipath Load Sharing for Both eBGP and iBGP in an MPLS VPN feature is enabled only under the IPv4 VRF address family configuration mode. BGP Add-path (Additional Path) -BGP routers and route reflectors (RR) propagate only their best path over their sessions. The advertisement of a prefix replaces the previous announcement of that prefix (this in known as an implicit withdraw). *BGP Add-Path is only an IBGP feature, it will NOT work with eBGP! - The Additional Paths feature allows the advertisement of more paths, in addition to the bestpath, in both regular BGP router and RR, to peers -3 Steps to Take -Specify whether the device can send, receive, or send and receive additional paths. -Select a set or sets of candidate paths for advertisement by specifying selection criteria (using the bgp additional-paths select command). -Advertise for a neighbor a set or sets of additional paths from the candidate paths marked (using the neighbor advertise additional-paths command). -To send or receive additional paths, the Additional Path capability must be negotiated. If it isn't negotiated, even if the selection criteria are such that more than the bestpath is marked and the neighbor is configured to advertise the marked paths, the selections would be useless because without the capability negotiated, only the bestpath can be sent. BGP Attributes -well known mandatory - must be recognized by Bgp routers and must be sent with update message -well known discretionary - must be recognized by Bgp routers but doesn't have to be in update message -optional transitive - doesn't have to be recognized by BGP but gets passed along with update message -optional nontransitive - doesn't have to be recognized by BGP and doesn't get sent with update message -next-hop, origin, and as-path are all well-known mandatory -local pref is well known discretionary —MED is optional nontransitive -Atomic Aggregator is well known discretionary -Aggregator and Community is optional transitive -originator id and cluster list is optional nontransitive BGP Peer-Group -You can group BGP neighbors who share the same outbound policies together in what is called a BGP peer group. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration. -A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load. Peer groups have these requirements: All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members. You can customize the inbound update policy for any member of a peer group. A peer group must be either internal (with internal BGP (iBGP) members) or external (with external BGP (eBGP) members). Members of an external peer group have different autonomous system (AS) numbers. If you use peer groups for clients of a route reflector, all the clients must be fully meshed. If you use an eBGP peer group, transit cannot be provided among the peer group members. -Members also can be configured to override the options that do not affect outbound updates. Inbound policies. If there are two inbound policies one configured for a neighbor, one for peer-group and one for a specific neighbor, the specific neighbor will take over •A neighbor can belong only to one peer group. •Neighbors that belong to different address-families cannot belong to the same peer group. •Different sets of policies cannot be grouped and applied to a neighbor. BGP Template -A BGP neighbor cannot be configured to work with both peer groups and peer templates. In other words, a BGP neighbor can be configured only to belong to a peer group or to inherit policies from peer templates. -A BGP neighbor can be configured to belong only to a peer group or to inherit policies from peer templates. -A directly inherited template will overwrite any indirectly inherited statements that are duplicated in the directly inherited template. Session Template -one session per neighbor, up to seven indirect Template inheritance. The directly applied peer session template will have priority over inherited peer session template configurations. Any configuration statements that are duplicated in inherited peer session templates will be overwritten by the directly applied peer session template Policy Template -Like peer session templates, a peer policy template supports inheritance. However, there are minor differences. A directly applied peer policy template can directly or indirectly inherit configurations from up to seven peer policy template -a peer policy template will not fall through like a route-map. Every sequence is evaluated, and if a BGP policy command is reapplied with a different value, it will overwrite any previous value from a lower sequence number. -The directly applied peer policy template and the inherit statement with the highest sequence number will always have priority and be applied last. -Peer policy templates can be configured in address family and NLRI configuration modes. BGP Dynamic Update Peer-Groups -This feature does not require any configuration by the network operator. Optimal BGP update message generation occurs automatically and independently. -i.e. groups BGP Updates to multiple neighbors based on the shared outbound routing policies, and no longer relies on being in the same BGP peer-group -The introduction of the BGP Dynamic Update Peer-Groups feature separates peer-group configuration from update group generation. The BGP Dynamic Update Peer-Groups feature introduced an algorithm that dynamically calculates BGP update-group membership based on outbound routing policies. Optimal BGP update message generation occurs automatically and independently. BGP neighbor configuration is no longer restricted by outbound routing policies, and update-groups can belong to different address families. Confederation -"bgp bestpath med confed" The comparison between MEDs is made only if there are no external autonomous systems in the path (an external autonomous system is an autonomous system that is not within the confederation). If there is an external autonomous system in the path, then the external MED is passed transparently through the confederation, and the comparison is not made. -next-hop IP addresses advertised from RT1 sub-confed eBGP neighbor to RT2 sub-confed eBGP neighbor will not change when RT2 advertises update to sub-confed eBGP neighbor RT3 e.g. sub-confed eBGP peers do not alter next-hop IP Aggregatation -in order to be able to advertise the aggregated route, you must have at least one specific individual prefix in the BGP RIB table (it doesn't matter if it is in the regular RIB table) -When you issue the aggregate-address command without any arguments, there is no inheritance of the individual route attributes (such as AS_PATH or community), which causes a loss of granularity. -The "as-set" argument contains information about each individual route that the aggregate summarizes. Changes in the individual route cause an update of the aggregate. If the aggregate summarizes tens or hundreds of routes and the routes that form the aggregate have problems, there can be a constant flap. -You can configure the "attribute-map" argument in order to manipulate the community attribute of the aggregate i.e. change the attribute of the ENTIRE aggregate! meaning to match the aggregate and change ALL of it's attributes, not just specific attributes attached to individual prefixes! -If you have control over the individual prefixes that form the aggregate route, you can more easily decide which attributes the aggregate will carry based on excluding or including the individual prefixes. This means that you must have the individual prefixes in You exclude a particular prefix with the use of "advertise-map", and by excluding the specific prefix you also exclude the path attributes attached to that prefix! The aggregate inherits the attributes only out of the routes that are selected in the advertise-map, -When you use the suppress-map configuration command along with the summary-only configuration command, the summary-only configuration command does not have any effect. -When you use as-set with suppress-map, although the suppressed routes are not advertised, the aggregated route inherits the attributes of all the suppressed routes. -When you use advertise-map and attribute-map along with as-set and other configuration commands, the attribute-map overrides the attributes that are chosen in the advertise-map. -In general, when you use advertise-map, only the advertise-map influences the aggregate. In the absence of advertise-map, the aggregate inherits the attributes of the more-specific routes, both suppressed and unsuppressed. In both the cases, you can use the attribute-map configuration command to override the chosen attributes. Local-AS -With the Local AS feature, a BGP speaker can be physically in one AS and acts as such to some neighbors while it appears to be another AS to other neighbors. When sending and receiving AS_PATH to and from neighbors with Local AS configured, BGP prepends the Local AS to the real AS. For these neighbors, BGP uses the Local AS as the remote AS in the configuration. Thus, the Local AS number appears as if it were another AS inserted between the two real autonomous systems. -Local AS can be used together with peer groups, but it cannot be customized for individual peers in a peer group. Local AS cannot have the local BGP AS number or the remote peer's AS number. -The local-as command is valid only if the peer is a true eBGP peer. It does not work for two peers in different member autonomous systems in a confederation. Multipath -The BGP Multipath Load Sharing for Both eBGP and iBGP (eiBGP)in an MPLS VPN feature is enabled only under the IPv4 VRF address family configuration mode. When enabled, this feature can perform load balancing on eBGP and/or iBGP paths that are imported into the VRF. -for regular IPv4/IPv6 AFI, load balancing is only allowed for either eBGP or iBGP -for MPLS VPN IPv4/IPv6 VRF AFI, load balancing is available for iBGP, eBGP, and eiBGP BGP Synchronization Rule -The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that network until a matching network route is learned via an IGP or static route (and is in the RIB). It also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table. Soft-reconfiguration -Perform this task to configure inbound soft reconfiguration using the "bgp soft-reconfig-backup" command for BGP peers that do not support the route refresh capability. BGP peers that support the route refresh capability are unaffected by the configuration of this command. -The dynamic inbound soft reset (route refresh) and inbound soft reset using stored information functions are mutually exclusive and cannot be configured together. If the inbound soft reset using stored routing table updates is configured for a neighbor, the dynamic inbound soft update method cannot be used. -In addition to BGP RIB , BGP use adjacency RIB-IN and OUT databases. All the prefixes from the remote BGP neighbour is placed in the BGP RIB-IN database first, Then inbound filter is applied , if we want to allow them, then prefix is taken into BGP RIB database. If we enable BGP Soft Reconfiguration Inbound , we keep received prefixes in the BGP RIB-IN database, if it is not enabled we ignore them. Route Refresh -negotiated between neighbors to check if capability is supported and for what address family -route refresh capability negotiated during peer session in OPEN message -adj-rib-in => bgp rib => local-rib => adj-rib-out -routes are stored in adj-rib-in table when soft reconfigure is enabled, when needed the NLRIs are used against inbound filter before going to bgp rib. -routes are filtered outbound before going to adj-rib-out and then sent out to neighbors PIC -BGP PIC feature supports prefixes only for IPv4, IPv6, VPNv4, and VPNv6 address families. -BGP PIC feature cannot be configured with Multicast or L2VPN Virtual Routing and Forwarding (VRF) address families. -The BGP PIC feature does not work with the BGP Best External feature. If you try to configure the BGP PIC feature after configuring the BGP Best External feature, you receive an error. -BGP Fast Reroute (FRR) provides a best path and a backup/alternate path in BGP, RIB, and Cisco Express Forwarding. BGP FRR provides a very fast reroute mechanism into the RIB and Cisco Express Forwarding on the backup BGP next hop to reach a destination when the current best path is not available. Therefore, BGP FRR sets up the best path and backup/alternate path. The BGP PIC feature provides the ability for Cisco Express Forwarding to quickly switch the traffic to the other egress ports if the current next hop or the link to this next hop goes down. -The BGP PIC feature works at the Cisco Express Forwarding level, and Cisco Express Forwarding can be processed in both hardware line cards and in the software. -Because many service provider networks contain many VRFs, the BGP PIC feature allows you to configure the BGP PIC feature for all VRFs at once. Depending on where u enable the PIC feature I.e.VPNv4 or VRF VPNv4 address family configuration mode protects all the VRFs. VRF-IPv4 address family configuration mode protects only IPv4 VRFs. Router configuration mode protects prefixes in the global routing table. -When the BGP PIC feature is enabled, Cisco Express Forwarding recursion is disabled. Cisco Express Forwarding Recursion, Cisco Express Forwarding finds the next path to reach the prefix by recursing through the FIB to find the next longest matching path to the prefix. This is useful if the next hop is multiple hops away and there is more than one way of reaching the next hop. -Notice that in oder to use the PIC functionality, BGP multi-path should be turned off - otherwise, equal-cost paths will be used for load-sharing, not for primary/backup behavior. Add Path -The BGP Additional Paths feature is a BGP extension that allows the advertisement of multiple paths for the same prefix without the new paths implicitly replacing any previous paths. This behavior promotes path diversity and reduces MED oscillations. -The BGP Additional Paths feature is implemented by adding a path identifier to each path in the NLRI. The path identifier (ID) can be considered as something similar to a route distinguisher (RD) in VPNs, except that a path ID can apply to any address family. -Additional Paths feature allows the advertisement of more paths, in addition to the bestpath. The Additional Paths feature allows the advertisement of multiple paths for the same prefix, without the new paths implicitly replacing any previous paths. -Specify whether the device can send, receive, or send and receive additional paths. This is done at the address family level or the neighbor level, and is controlled by either the bgp additional-paths {send [receive] | receive} command or the neighbor additional-paths {send [receive] | receive} command, respectively. During session establishment, two BGP neighbors negotiate the Additional Path capabilities (whether they can send and/or receive) between them. -There are three path selection (path marking) policies, and they are not mutually exclusive. They are specified per address family, using the bgp additional-paths select command. They are: best 2 or best 3 (best 2 means the bestpath and 2nd best path; the 2nd best path is the one computed by eliminating best-path from the best-computation algorithm. Similarly, best 3 means the bestpath, 2nd best path, and 3rd best path; the 3rd best path is the one computed by eliminating bestpath and 2nd best path from the best-computation algorithm.) group-best (calculates the group-best for prefixes during bestpath calculation; described further below) all (all paths with unique next hops are eligible for selection) -The group-best is the set of paths that are the best paths from the paths of the same AS. For example, suppose there are three autonomous systems: AS 100, 200, and 300. Paths p101, p102, and p103 are from AS 100; p201, p202, and p203 are from AS200; and p301, p302, and p303 are from AS300. If we run the BGP bestpath algorithm on the paths from each AS, the algorithm will select one bestpath from each set of paths from that AS. Assuming p101 is the best from AS100, p201 is the best from AS200, and p301 is the best from AS300, then the group-best is the set of p101, p201, and p301. -caveat! Must select and advertise same set of paths or will get error message -best path can be configured globally, per AF, or per neighbor -You can optionally use a route map to filter the paths to be advertised by matching on the tags of additional paths that are candidates to be advertised. (These tags are the advertise-sets that are configured with the bgp additional-paths select command.) After creating the route map, you would reference the route map in the neighbor route-map out command. Thus, the route map is applied to paths being advertised (outgoing) to neighbors. Then you would use the neighbor advertise additional-paths command to advertise the additional paths

OSPF

OSPF Packet Types -Router LSAs (Type 1)--Describes the link state and costs of a router's links to the area. These LSAs are flooded within an area only. The LSA indicates if the router is an Area Border Router (ABR) or Autonomous System Boundary Router (ASBR), and if it is one end of a virtual link. Type 1 LSAs are also used to advertise stub networks. In OSPFv3, these LSAs have no address information and are network-protocol-independent. In OSPFv3, router interface information may be spread across multiple router LSAs. Receivers must concatenate all router LSAs originated by a given router when running the SPF calculation. Prefix information is not included in the Router LSA as it is in its OSPFv2 counterpart. -Network LSAs (Type 2)--Describes the link-state and cost information for all routers attached to the multi-access network. This LSA is an aggregation of all the link-state and cost information in the multi-access network. Only a designated router tracks this information and can generate a Network LSA. In OSPFv3, network LSAs have no address information and are network-protocol-independent. -Interarea-prefix LSAs for ABRs (Type 3)--Advertises internal networks to routers in other areas (interarea routes) i.e. advertises network from Area X into Area Y. Type 3 LSAs may represent a single network or a set of networks summarized into one advertisement. Only ABRs generate summary LSAs. In OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0. -Interarea-router LSAs for ASBRs (Type 4)--Advertises the location of an ASBR. Routers that are trying to reach an external network use these advertisements to determine the best path to the next hop. Type 4 LSAs are generated by ABRs on behalf of ASBRs. -Autonomous system external LSAs (Type 5)--Redistributes routes from another autonomous system, usually from a different routing protocol into OSPFv3. In OSPFv3, addresses for these LSAs are expressed as prefix, prefix length instead of address, mask. The default route is expressed as a prefix with length 0. -Link LSAs (Type 8)--Have local-link flooding scope and are never flooded beyond the link with which they are associated. Link LSAs provide the link-local address(es) of the local router to all other routers attached to the link, inform other routers attached to the link of a list of prefixes to associate with the link, and allow the router to assert a collection of Options bits to associate with the network LSA that will be originated for the link. -Intra-Area-Prefix LSAs (Type 9)--A router can originate multiple intra-area-prefix LSAs for each router or transit network, each with a unique link-state ID. The link-state ID for each intra-area-prefix LSA describes its association to either the router LSA or the network LSA and contains prefixes for stub and transit networks. Only the DR advertises Type 9 LSAs in Broadcast networks. Carries prefix information that Router and Network LSAs use to carry like they did in OSPFv2 Type 1 LSA Example -"transit" i.e. network type broadcast or NBMA -"point-to-point" i.e. network type point-to-point or point-to-multipoint -"stub" i.e. i.e. this link is an OSPF enabled link, but it doesn't have another neighbor attached on the other link! Also, if there is a type 1 LSA that is point-to-point, automatically it will be accompanied with a stub network link as well OSPFv3 -In IPv6, you can configure many address prefixes on an interface. In OSPFv3, all address prefixes on an interface are included by default. You cannot select some address prefixes to be imported into OSPFv3; either all address prefixes on an interface are imported, or no address prefixes on an interface are imported. -Unlike OSPF version 2, multiple instances of OSPFv3 can be run on a link. However, it is one instance per address-family -On NBMA networks, the designated router (DR) or backup DR (BDR) performs the LSA flooding, the DR floods out OSPFv2 Network LSAs and OSPFv3 Intra Prefix LSAs. On point-to-point networks, flooding simply goes out an interface directly to a neighbor. When using NBMA in OSPFv3, you cannot automatically detect neighbors. On an NBMA interface, you must configure your neighbors manually using interface configuration mode. -The OSPFv3 address families feature enables both IPv4 and IPv6 unicast traffic to be supported. With this feature, you may have two device processes per interface, but only one process per AF. If the IPv4 AF is used, an IPv4 address must first be configured on the interface, but IPv6 must be enabled on the interface. A single IPv4 or IPv6 OSPFv3 process running multiple instances for one AF on the same interface is not supported. I.e. can't have "ospfv3 1 ipv4 area 1 instance 2" and "ospfv3 1 ipv4 area 1 instance 1" on same interface (the latest configuration replaces the previous one), but can have both ipv4 and IPv6 instance on same interface running. -IMPORTANT! can only have one OSPF process and instance per Address family (ipv4/ipv6) and only one address family can be configured per instance, that's why IPv6 has instance number from 0-31 and for IPv4 its 64-95 -an OSPF instance is the OSPF collection of database, interfaces, etc. for an IPv4 or IPv6 -OSPFv3 instance ID number on interfaces must match between neighbors in order to form neighbor adjacency (when interfaces first come up) OSPF Network Types -P2MP Non-Broadcast - OSPF point-to-multipoint non-broadcast was designed to allow for the assignment of the cost on a per neighbor basis as opposed to using the interface's cost. Virtual-Link -The area through which you configure the virtual link, known as a transit area, must have full routing information. The transit area cannot be a stub area. -The transit area cannot be a stub area, because routers in the stub area do not have routes for external destinations. Because data is sent natively, if a packet destined for an external destination is sent into a stub area which is also a transit area, then the packet is not routed correctly. The routers in the stub area do not have routes for specific external destinations. -once the virtual link is up, no hellos are exchanged. OSPF suppresses the hellos because it considers virtual links to be demand circuits. Normally, OSPF sends hellos every 10 seconds and refreshes its LSAs every 30 minutes. However, even this amount of traffic is undesirable on demand circuits. The use of OSPF demand circuit options suppresses hello and LSA-refresh functions. As a result, any changes that you make to the OSPF authentication do not take effect until you clear the OSPF process with the clear ip ospf process command. OSPFv3 Database -differs from OSPFv2 in that a router does not have the LSAs for all other areas in which the local router does not belong i.e. "show ospfv3 database" will not show Link States that belong in an area not configured on the router! -Type 3 and Type 9 LSAs carry all prefix (subnet) information that, in OSPFv2, is included in router LSAs and network LSAs. i.e. only the Intra-Area (Type 9) and Inter-Area (Type 3) sends Prefix information OSPF Neighbor State -Attempt: only used by NBMA networks -Init: the local router has received a Hello from the neighbor. However, within that hello, the local router's ID is not in the packet. Problems in this state could be authentication issue. Also, could be ACL blocking issue. -2-way: the hellos are received from both neighbors with their router IDs attached on packet of the other neighbor. Receiving a DBD during the Init state will also transition the router to 2-way state as well. DR and BDR are elected at the end of this state. On broadcast and NBMA networks, routers will only form adjacencies with the DR and BDR, but not with the other routers on the same subnet. For the other routers, they will be considered DROther and stay in the 2-way state. Database synchronization process is only executed between two routers if one of the two routers is the DR or BDR. A router will also stay in the 2-way state when it's priority is configured as 0 "ip ospf priority 0", which will tell the OSPF interface to always remain in the DROTHER state for broadcast and NBMA, the router will not be able to become a DR or BDR. -Exstart: start exchanging link state information. Start of master and slave relationship. Master is the router with the highest IP address. In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. -Exchange: OSPF routers exchange database descriptor (DBD) packets. The routers also send link-state request packets, which request more recent link-state advertisements (LSA) from neighbors. -Loading: In this state, the actual exchange of link state information occurs. Only in this state are the actual LSAs exchanged. -Full: routers' databases are fully synchronized. Router for point-to-point, point-to-multipoint, or point-to-multipoint non-broadcast is "FULL/ - " and for broadcast and NBMA the state will either be "FULL/DR", "FULL/BDR", or "2WAY/DROTHER". -OSPF adjacencies only form over primary networks, not secondary networks. OSPF Generic TTL Security Mechanism -security setting, sends outgoing packets with TTL 255 and it discards packets that have value less than the configured threshold -benefit is to prevent Denial of Service (DoS) attacks, because when GTSM is configured correctly only packets that are one hop away will be processed by the router OSPF Link-State Advertisement (LSA) Throttling -slows down new LSA updates during times of network instability -also helps speeds up convergence by reducing default 5 second wait period to group LSAs together as much as possible and send out updates. Timer could be reduced to milliseconds. -One command controls the generation (sending) of new LSAs and another command controls the receiving interval. -The "timers throttle lsa all" command controls the generation (sending) of LSAs -The "timers lsa arrival" command controls the minimum interval for accepting the same LSA. If an instance of the same LSA arrives sooner than the interval that is set, the LSA is dropped. It is recommended that the arrival interval be less than or equal to the hold-time interval of the "timers throttle lsa all" command. Refresh Age LSA Tuning -"timers pacing lsa-group..." controls the wait timer period to group aged LSA before sending out LSA refreshes to neighbors i.e. when there is an LSA that is about to reach the 30 minute old age mark and needs to be sent out to refresh neighbors, wait for X amount of time to see if there are other LSAs that will also need to be refreshed, then send out this as a group. This command will also influence the group waiting period for checksum validations as well. -"timers pacing flood" controls the wait and group period timer on interfaces to allow for a group of LSAs that just arrived to wait and send it in after the configured time -"timers pacing retransmission" is the time configured to wait/group un-acknowledged LSAs before retransmitting the same LSA to the same neighbor Loop Free Alternative (LFA) Single Hop -having a router with an LFA allows an OSPF router to precompute an alternative path to a route destination, so when the primary path fails, a separate repair path is available to use immediately without having routers run SPF again and having to reconverge -You cannot configure a traffic engineering (TE) tunnel interface as a protected interface. You can configure a TE tunnel interface in a repair path, but OSPF will not verify the tunnel's placement; you must ensure that it is not crossing the physical interface it is intended to protect. -for Single Hop, repair path router must be within one hop reach I.e. TE interface can't be a protected path but can be a repair path -3 conditions to be repair path (LFA); 1st condition - the path from the repair path router to the destination must be less than the path from the repair path router to the source router PLUS the distance from the source router to the destination. i.e. Router A is the source, Router B is the repair path router, Router C is the destination router. In order for the link from Router A to Router B to be the repair path, the distance from Router B to Router C must be less than the distance of Router B to Router A to Router C e.g. Router B + Router C > Router B + Router A + Router C. This is to prevent a situation where the repair path router might end up using the source router as the path to the destination and thus causing a routing loop -2nd condition - the distance from the repair path router to the destination router must be less than the distance of the source router to the destination router e.g. Router B + Router C < Router A + Router C -3rd condition - the distance from the repair path router to the destination router must be less than from the repair path router to the primary next-hop router to the destination e.g. Router B + Router C < Router B + primary next-hop router + Router C -Paths are chosen based on priority, listed below. Below are the backup prefix selection criteria with their preference in decreasing order. In the event of two backup routes available for a protected primary prefix, only one would be selected based on below mentioned ordered list of attributes they carry. srlg primary-path interface-disjoint lowest-metric linecard-disjoint node-protecting broadcast-interface-disjoint -Shared risk link group (SRLG): Default LFA policy tries to avoid a path that carries same SRLG as primary path.Assume multiple routers are using the same switch, so they all be sharing the same risk . -Primary-path: This helps in eliminating candidates that are not equal cost multiple path links or ECMPs. -Interface-Disjoint: This means that repair path is over a different interface as compared to the interface used to reach destination via primary path. In case of point-to-point links, this condition is always met. -Lowest-metric: Select a backup path with minimum cost to reach destination. -Linecard-disjoint: This prefers a backup route from an interface that is on another line card. This is also a special case of SRLG however; this does not require any special configuration and is handled automatically. -Node-protecting: Repair path all together bypasses primary path next-hop router. This ensures complete traffic protection even in the event of primary next-hop router failure. The repair path must not transit the primary next-hop router to reach the destination router, uses inequality rule 2 to ensure this. This ensures that if the primary next-hop router is down, it won't bring down the primary path or the repair path -Broadcast-interface-disjoint : This attributes helps to ensure that repair path does not make use of same broadcast network used by primary path. -Load-sharing: Traffic is load shared amongst candidate back up routes when all other checks discussed above fail to provide a unique back up path. -Shared Risk Link Group (SRLG) - A shared risk link group (SRLG) is a group of next-hop interfaces of repair and protected primary paths that have a high likelihood of failing simultaneously. -VLANs on a single physical interface are an example of an SRLG. If the physical interface fails, all the VLAN interfaces will fail at the same time. Interface Disjoint Protection -Point-to-point interfaces have no alternate next hop for rerouting if the primary gateway fails. You can set the interface-disjoint attribute to prevent selection of such repair paths, thus protecting the interface. Broadcast Interface Protection -You can set the broadcast-interface-disjoint attribute to specify that the repair path never crosses the broadcast network the primary path points to; that is, it cannot use the interface and the broadcast network connected to it. Node Protection -The default repair-path attributes might not protect the router that is the next hop in a primary path. You can configure the node-protecting attribute to specify that the repair path will bypass the primary-path gateway router Downstream Path -this protects against routing loops by ensuring that the repair path router has a closer metric to the destination router than the local router does to the destination, ensuring that the situation where the repair path can use the primary path in the route to the destination doesn't occur -Similar to EIGRP Feasibility Condition. In the case of a high-level network failure or multiple simultaneous network failures, traffic sent over an alternate path might loop until OSPF recomputes the primary paths. You can configure the downstream attribute to specify that the metric of any repair path to the protected destination must be lower than that of the protecting node to the destination. This might result in lost traffic but it prevents looping. Line-Card Disjoint Interfaces -Line-card interfaces are similar to SRLGs because all interfaces on the same line card will fail at the same time if there is a problem with the line card, for example, line card online insertion and removal (OIR). You can configure the linecard-disjoint attribute to specify that LFA repair paths use different interfaces than those on the primary-path line card. Metric -An LFA repair path need not be the most efficient of the candidates. A high-cost repair path might be considered more attractive if it provides protection against higher-level network failures. You can configure the metric attribute to specify a repair-path policy that has the lowest metric. Equal-Cost Multipath Primary Paths -determine whether or not a repair path should be a path in the ECMP set or not -Equal-cost multipath paths (ECMPs) found during the primary shortest path first (SPF) repair, might not be desirable in network designs where traffic is known to exceed the capacity of any single link. You can configure the primary-path attribute to specify an LFA repair path from the ECMP set, or the secondary-path attribute to specify an LFA repair path that is not from the ECMP set. Candidate Repair-Path Lists -When OSPF computes a repair path, it keeps in the local RIB only the best from among all the candidate paths, in order to conserve memory. You can use the fast-reroute keep-all-paths command to create a list of all the candidate repair paths that were considered. This information can be useful for troubleshooting but it can greatly increase memory consumption so it should be reserved for testing and debugging. Troubleshoot OSPF Neighbor Adjacency -No State Revealed If the show ip ospf neighbor command reveals nothing at all - or reveals nothing about the particular neighbor you are analyzing - then this router has not seen any "valid" OSPF HELLOs from that neighbor -Neighbor in down State Usually, neighbors that are seen in the down state were manually configured with the neighbor command. Manually configured neighbors are always present in the OSPF neighbor table. If OSPF has never received HELLO packets from the manually configured neighbor, or if no HELLO packets were heard from the neighbor during the previous Dead timer interval, then the manually configured neighbor will be listed as down. "Neighbor" command can only be configured on NBMA or P2MP NBMA -Stuck in INIT: The init state indicates that a router sees HELLO packets from the neighbor, but two-way communication has not been established, also means router is not receiving a Hello from neighbor with it's own router-ID attached, check if neighbor is reachable and check ACLs. In other words, a router with a neighbor in the init state has received hello packets from the neighbor but has not seen its own Router ID in the neighbor's hellos -Stuck in 2-way: on broadcast and NBMA links, routers will only establish adjacency with DR and BDR, it will only stay at 2-way state with other routers and be in DROther -Stuck in Exstart/Exchange: there is a mismatch MTU on the interface with the neighbor -Neighbor in loading State In the loading state, routers send link-state request packets. Neighbors that do not transition beyond this state are most likely exchanging corrupted LSAs. -can be neighbors if... OSPF is configured on the secondary network of the neighbor, but not on the primary network. This is an illegal configuration which prevents OSPF from being enabled on the interface. OSPF Remote LFA -two paths: protect and repair -Remote LFA provides a mechanism where if direct (single hop) loop free alternate path is not available, traffic could be tunneled with MPLS to a remote node that could still deliver traffic to end destination within 50 millisecond turnaround time. -All prefixes are first checked against direct loop free alternate path availability for protection. This means that Direct LFA must be configured as well as Remote LFA for Remote LFA to work! Prefixes that do not have a direct LFA protection would not be considered for remote LFA protection. Targeted LDP neighbor sessions are built between the source node and the remote LFA repair path node -the remote node that the source uses as the repair path is called the PQ node or release node -Devices that can be selected as tunnel termination points must have a /32 address advertised in the area in which remote LFA is enabled. This address will be used as a tunnel termination IP. If the device does not advertise a /32 address, it may not be used for remote LFA tunnel termination. -All devices in the network that can be selected as tunnel termination points must be configured to accept targeted LDP sessions using the "mpls ldp discovery targeted-hello" accept command. -routers with protected paths must be configured with "fast-reroute per-prefix remote-lfa tunnel mpls-ldp" to enable remote LFA, termination router with repair path must be configured with "mpls ldp discovery targeted-hello" accept to accept targeted LDP sessions.

IPv6 Multicast Address Ranges

IPv6 Multicast Addresses -FF01::/8 defines node-local scope -FF02::/8 defines link-local scope -FF05::/8 defines site-local scope -FF08::/8 defines Organization-local scope -FF0E::/8 defines global scope -FF02:0:0:0:0:1:FFXX:XXXX/108 + last 24 bits of IPv6 address, defines the solicited-node multicast address. The solicited-node multicast address is a multicast group that corresponds to an IPv6 unicast or anycast address on the last 24 bit. IPv6 nodes must join the associated solicited-node multicast group for every unicast and anycast address to which it is assigned. -FC00::/7 defines Unique Local Addresses (ULA) which are similar to IPv4 RFC1918 in that the addresses are meant to be within a local network and not transit out to the global network IPv6 Regular Addresses -FEC:: means the address belongs to a site local address -::1 is the local router's loopback address, similar to IPv4 127.0.0.1 this address is used by the router to speak to itself -:: means that there is no IPv6 address available. The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must never be assigned to any node. It indicates the absence of an address. One example of its use is in the Source Address field of any IPv6 packets sent by an initializing host before it has learned its own address. The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing headers. RFC4291

IPv6 Neighbor Discovery

IPv6 Neighbor Discovery -The IPv6 neighbor discovery process uses ICMPv6 messages and solicited-node multicast addresses to determine the link-layer address of a neighbor on the same network (local link), verify the reachability of a neighbor, and track neighboring devices. NS -Neighbor solicitation messages are sent on the local link when a node wants to determine the link-layer address of another node on the same local link -When a node wants to determine the link-layer address of another node, the source address in a neighbor solicitation message is the IPv6 address of the node sending the neighbor solicitation message. The destination address in the neighbor solicitation message is the solicited-node multicast address that corresponds to the IPv6 address of the destination node. The neighbor solicitation message also includes the link-layer address of the source node. NA -After receiving the neighbor solicitation message, the destination node replies by sending a neighbor advertisement message, which has a value of 136 in the Type field of the ICMP packet header, on the local link. The source address in the neighbor advertisement message is the IPv6 address of the node (more specifically, the IPv6 address of the node interface) sending the neighbor advertisement message. The destination address in the neighbor advertisement message is the IPv6 address of the node that sent the neighbor solicitation message. The data portion of the neighbor advertisement message includes the link-layer address of the node sending the neighbor advertisement message. DAD - Duplicate address detection is performed first on a new, link-local IPv6 address before the address is assigned to an interface (the new address remains in a tentative state while duplicate address detection is performed). Specifically, a node sends a neighbor solicitation message with an unspecified source address and a tentative link-local address in the body of the message. If another node is already using that address, the node returns a neighbor advertisement message that contains the tentative link-local address. If another node is simultaneously verifying the uniqueness of the same address, that node also returns a neighbor solicitation message. If no neighbor advertisement messages are received in response to the neighbor solicitation message and no neighbor solicitation messages are received from other nodes that are attempting to verify the same tentative address, the node that sent the original neighbor solicitation message considers the tentative link-local address to be unique and assigns the address to the interface. RA -For stateless autoconfiguration to work properly, the advertised prefix length in RA (Router Advertisement) messages must always be 64 bits.

IS-IS

Integrated IS-IS -originally ISIS is for Connetionless Network Services (CLNS) -IP implementations is Integrated ISIS -supports both IPv4 and IPv6 -IS-IS Single Topology: create one SPF for domain but apply to both IPv4 and IPv6 at the same time i.e. run SPF for both IPv4 and IPv6 instances at same time -IS-IS is not an IP Protocol, IP is an extension of IS-IS IS-IS NET Addressing -Network Entity Title (NET), essentially CLNS Router-ID -The NET is the address of a Network Service Access Point (NSAP), which identifies an instance of the IS-IS routing protocol running on an IS. -Uses ISO NSAP Address Format; Maximum 20 bytes, Minimum 8 bytes, but must be even number of bytes -An IS-IS instance may be assigned multiple area addresses -NET Format -AA.AAAA.AAAA.AAAA.AAAA.AAAA.AAAA.SSSS.SSSS.SSSS.NN -Area - not link-state area like OSPF (A) -System-ID - Router-ID inside the area (6 byte) (S), When the IS operates at Level 1, the system ID must be unique among all the Level-1 devices in the same area. When the IS operates at Level 2, the system ID must be unique among all devices in the domain. -N-Selector - always zero (N), Its function is similar to the port number in other protocol suites. -ISIS is it's own routing protocol, it doesn't rely on IP like OSPF, EIGRP, etc. IIHs -Intermediate System-to-Intermediate System Hello PDUs (IIHs) are exchanged between IS neighbors on circuits on which the IS-IS protocol is enabled. IIHs include the system ID of the sender, the assigned area address(es), and the identity of neighbors on that circuit that are known to the sending IS. Additional optional information may also be included. There are three types of IIHs: Point-to-Point IIHs—These are sent on point-to-point circuits. Level-1 LAN IIHs—These are sent on multiaccess circuits when the sending IS operates as a Level-1 device on that circuit. Level-2 LAN IIHs—These are sent on multiaccess circuits when the sending IS operates as a Level-2 device on that circuit. LSPs -An IS generates Link-State PDUs (LSPs) to advertise its neighbors and the destination that are directly connected to the IS. An LSP is uniquely identified by the following: System ID of the IS that generated the LSP Pseudonode ID—This value is always 0 except when the LSP is a pseudonode LSP (see "Operation of IS-IS on Multiaccess Circuits" section. LSP number (0 to 255) 32-bit sequence number -Whenever a new version of an LSP is generated, the sequence number is incremented. -Level-1 LSPs are generated by ISs that support Level 1. The Level-1 LSPs are flooded throughout the Level-1 area. The set of Level-1 LSPs generated by all Level-1 ISs in an area is the Level-1 LSP Database (LSPDB). All Level-1 ISs in an area will have an identical Level-1 LSPDB and will therefore have an identical network connectivity map for the area. -Level-2 LSPs are generated by ISs that support Level 2. Level-2 LSPs are flooded throughout the Level-2 subdomain. The set of Level-2 LSPs generated by all Level-2 ISs in the domain is the Level-2 LSP Database (LSPDB). All Level-2 ISs will have an identical Level-2 LSPDB and will therefore have an identical connectivity map for the Level-2 subdomain. SNPs -Sequence Number PDUs (SNPs) contain a summary description of one or more LSPs. There are two types of SNPs for both Level 1 and Level 2: Complete Sequence Number PDUs (CSNPs) are used to send a summary of the LSPDB that an IS has for a given level. Partial Sequence Number PDUs (PSNPs) are used to send a summary of a subset of the LSPs for a given level that an IS either has in its database or needs to obtain. -An IS can generate up to 256 LSPs at each level. The LSPs are identified by the numbers 0 through 255. LSP 0 has special properties, including the significance of the setting of the ATT bit to indicate attachment to other areas. When LSPs that are numbered 1 through 255 have the ATT bit set, it is not significant. -Independent SPFs are performed for each level supported by the IS. In cases in which the same destination is reachable by both Level-1 and Level-2 paths, the Level-1 path is preferred. Neighbor Relationship on P2P Circuits -Level 1 Adjacency Requirements - must match MTU on both sides of link, must have same area ID in NSAP address, must have matching interface, network types must match, authentication (don't need area or domain authentication to match to have adj because those only authenticate the LSPs), and each neighbor must have unique system ID in NSAP -Level 2 Adjacency - neighbors must have unique system ID in the NSAP, authentication of Hellos at the interface level must match, network types must match -When an adjacency is first established, each IS sends a set of CSNPs for each level that is supported on the circuit. A CSNP set describes the current contents of the LSPDB at that level. By comparing the contents of the set of received CSNPs with the contents of the local LSPDB, each IS can determine where the databases differ and initiate procedures to exchange the necessary LSPs so that the databases are efficiently and reliably synchronized. - PSNPs are sent to acknowledge the receipt of an updated LSP. -the Circuit ID on a P2P link can be of two values for each side of the link, "00" and "01" depending on what side is established first -for multi-access networks. the Circuit ID will have the system ID of the DIS concatenated with a non-zero second octet value i.e. "R5-01" or "R5-02" -There are only two network types in IS-IS. Broadcast and Point-to-Point. Broadcast is default network type. If one end is configured with "isis network point-to-point" and other end is default network type. The hellos will be discarded and adjacency will not come up. Hence network type must match on both the ends. -Hello timers need not match for the adjacency to come up. -IS-IS Adjacency States There are only three adjacency states in IS-IS. Down: This is the initial state. Its means that no hellos have been received from the neighbor. Initializing: This state means that the local router has successfully received hellos from the neighboring router, however it's not sure that the neighboring router has also successfully received local router's hellos. Up: Now it's confirmed that neighboring router is receiving local router's hellos. IS-IS Election of the Designated Intermediate System -If each IS advertised all of its adjacencies on a multiaccess circuit in its LSPs, the total number of advertisements required would be N 2—where N is the number of ISs that operate at a given level on the circuit. To address this scalability issue, IS-IS defines a pseudonode to represent the multiaccess circuit. All ISs that operate on the circuit at a given level elect one of the ISs to act as the Designated Intermediate System (DIS) on that circuit. A DIS is elected for each level that is active on the circuit. -The DIS is responsible for issuing pseudonode LSPs. The pseudonode LSPs include neighbor advertisements for all of the ISs that operate on that circuit. All ISs that operate on the circuit (including the DIS) provide a neighbor advertisement to the pseudonode in their non-pseudonode LSPs and do not advertise any of their neighbors on the multiaccess circuit. In this way the total number of advertisements required varies as a function of N—the number of ISs that operate on the circuit. -Flooding over the LAN means that the DIS sends periodic complete sequence number protocol data units (CSNPs) (default setting of 10 seconds) -On broadcast multi-access networks, a single router is elected as the DIS. There is no backup DIS elected. The DIS is the router that creates the pseudonode and acts on behalf of the pseudonode. Two major tasks are performed by the DIS: Creating and updating pseudonode LSP for reporting links to all systems on the broadcast subnetwork. See the Pseudenode LSP section for more information. Flooding LSPs over the LAN. -The circuit ID on a multi-access link is a one-octet number that the router uses to uniquely identify the IS-IS interface. If the interface is attached to a multiaccess network, the circuit ID is concatenated with the system ID of the DIS. This is known as the pseudonode ID. i.e. Circuit ID "R6-01" on a multi-access link contains the hostname of the DIS "R6" concatenated with "-01" which identifies the numerical value assigned per circuit i.e. for R6, the if it has another circuit where it is also the DIS, the circuit ID will be "R6-02" -The DIS is also responsible for sending periodic CSNPs on the circuit. This provides a complete summary description of the current contents of the LSPDB on the DIS. Other ISs on the circuit can then perform the following activities: -Flood LSPs that they have that are absent from or are newer than those that are described in the CSNPs sent by the DIS. -Request an LSP by sending a PSNP for LSPs that are described in the CSNPs sent by the DIS that are absent from the local database or older than what is described in the CSNP set. -Padding -Regarding the padding, IOS implements a mechanism to detect the MTU on interface before adjacency is established. So that after the adjacency is established packet drops should not occur due the MTU issues and hence preventing the database from corruption. Padding a IS-IS hello increases its size till the MTU of the interface and it is observed whether the other end is able to accept hello packet with this MTU. If on the other end lower MTU exits then that end will drop the hellos and hence adjacency will not come up (for Level 1) Hello Timers -default timer on interface is 10 seconds -a value three times the hello interval seconds is advertised as the hold time in the hello packets sent. e.g. Default Hold Timer is 30 seconds - The hello interval multiplied by the hello multiplier equals the hold time. If the minimal keyword is specified, the hold time is 1 second and the system computes the hello interval based on the hello multiplier. -On point-to-point links, there is ONLY ONE hello for both Level 1 and Level 2 -By default, IS-IS uses a 10-second hello interval and 30-second dead interval, with the exception of a broadcast segment's designated router (DIS), which sends hellos at one-third the normal interval (every 3.3 seconds). There might be confusion regarding the hold timers. In IS-IS the DR in the broadcast LAN segment always sends the hellos one-third of the normal hello time i.e. 10 seconds. So from the perspective of DR the hello time is 3.33 secs and hold time is 10 secs. In the above capture R2 is the DR. -Hello timers do not have to match to form adjacency -The hello interval can be configured independently for Level 1 and Level 2 for multi-access, except on serial point-to-point interfaces. Levels -equivalent of OSPF areas -Level 2 is equivalent to OSPF backbone area -in the Level 2, every router must have unique System-ID (SSSS.SSSS.SSSS) -49 for AA is like IPv4 private address -level 2 must be contiguous i.e. must be connected -area does not mean flooding domain, the flooding domain is the Level -Level 1 is for intra area adjacency only -Level 2 is for intra or inter area adjency -Level 1 Area behaves pretty much as OSPF totally stubby area Level 1 -Intra area adjacency only -Like a Totally NSSA in OSPF -intra area routes only -default route outbound to Level 2 -redistribution allowed Level 1 / Level 2 Routing -like an ABR in OSPF -used as exit point from L1 to L2 -convert Level 1 LSP into Level 2 LSP -not converting Level 2 into Level 1 -Injects default route into Level 1 -this means that Level 1 routers will not learn of any Level 2 routes. It also means that only Level 2 and Level1/2 routers will know of both Level 1 routes and Level 2 routes by default IS-IS Level Manipulation -Process and Interfaces default to Level-1-2 -forms both L1 and L2 -separate LSP database -double the overhead -Level can be defined... -global under the process, which affects all interfaces -under the interface, affects only that interface Area -depending on area, it will tell the router base on what type of level adjacency can be formed -if my NET address has a different area id configured than on the neighbor, it means that I will not be able to form Level 1 adjacency -this means that for Level 2, the adjacency between routers can form regardless of different area configured on both neighbors -but for Level 1 adjacency to form, both neighbors MUST configure the same area to be adjacent! Default Interface and Metric -for Cisco, on ISIS the default cost of an interface is 10 -maximum default metric for an interface is 63 -maximum default metric for any route to a destination is 1023 -can change with wide metric, 32 bit address max is 16777... -To do MPLS traffic engineering, new-style TLVs that have wider metric fields must be generated Wide metrics are used in: MPLS-TE prefix tags multi-topology need for metric > 63 -Wide Metric - The Extended IS-Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks and Hosts. Network Types and DIS Election -Only two network types -Broadcast; default on multipoint interfaces, uses DIS instead of DR/BDR -Point-to-Point; default on point-to-point interfaces e.g. P2P, GRE, etc. DIS Election -Designated Intermediate System -Like OSPF DR/BDR, but with no backup DIS -Election is dynamic, preemption can occur -separate election for L1 and L2 -Elected based on configured Highest priority (default 64) and then Highest SNPA (MAC) address as the tie-breaker on interface. If the SNPA is a DLCI and is the same at both sides of a link, the router with the higher system ID becomes the DIS. SNPA stands for Subnetwork Point of Attachment. It identifies a point at which a device connects to a network. It is roughly equivalent to a Layer 2 address in the non-CLNS world. The SNPA for a local-area network (LAN) connection is the MAC address of the interface. -separate election per area and per link -"show isis neighbor" it is identified as the Circuit ID -depending on the configured Area number, the Pseudonode DIS will be represented by the name of the router (R3) and combined with the configured area ID (0001), then the Pseudonode will have the ID R3.01-00 (anything non-zero) Forming Adjacency -Ensure transport first -CLNS resolution on multipoint NBMA -IP in IP tunnels -ISIS not supported in IPv6 in IPv4 encapsulation, P2MP tunnels, DMVPN -Level of adjacency must match -area must match if L1 adjacency -network type - broadcast, and point-to-point, network types MUST match to form adjacency! IS-IS Path Selection -All links default to cost of 10 -can be manually defined -Neighbors must agree on Metric Style; narrow - default, wide - needed for MPLS TE and IPv6, transition Multi Topology IS-IS -IS-IS Supports for both IPv4 and IPv6 -IPv6 routing can be either single topology or multi topology -Single Topology ; shares path calculation with IPv4, requires 1:1 correlation of IPv4 and IPv6 interfaces. This means that if you change the ISIS metric, it changes it for both IPv4 and IPv6 metric at the same time. It also means that every link must be configured for both IPv4 and IPv6 to have parity. -Multi Topology - independent path calculation from IPv4, IPv4 and IPv6 configuration completely independent Sequence Number PDU -SNPs have functions similar to OSPF Database Description, LSA Request, and LSA Acknowledge -on a point-to-point link, PSNP is used to acknowledge receiving LSPs from P2P neighbor -on a broadcast link, PSNP is used to specifically request for missing LSPs from DR. On Point-to-Point link, a router will send out the CSNP to neighbor if there are missing LSPs -on Broadcast, only the DR sends out CSNP in multicast, which describes either the entire Level 1 or Level 2 LSPDB. When a neighbor is missing an LSP in the CSNP, then it will send to the DR an PSNP to request for the missing LSP Attached Bit and Overload Bit -Attached bit - when active "1" in the LSP that is sent, the receiving neighbor will know that the sender is a router that has connections to other area, specifically a different area Level 2 i.e. the sender is an Inter-area router. This also is used by default to advertise a default route by the L1/L2 router to the L1 only routers, but this will only be the case when the L1/L2 router has a Level 2 neighbor AND has a different Area configured then the L1/L2 router. L1/L2 IS-IS Routers will advertise a default route to an adjacent L1 router with the Attached Bit set. The L1 will know that this default route came from a L1/L2 router. The L1/L2 router needs an inter-area L2 adjacency (L1/L2 <=> L2, ADJ) in order to set the attached bit automatically. You can however just manually set the attached bit if you want. -the OL bit is use to set on LSP when sending router has high memory problems, therefore any other routers will only send traffic that is destined to the connected interfaces of the sending router but to avoid using that router as a transit path to other destinations. When used with BGP, the bit is used to indicate that BGP hasn't converged yet, so do not send traffic to the router because BGP can blackhole traffic when it hasn't converged but IGP already has. The OL bit can be set automatically or manually. Authentication -Like RIPv2 and OSPF, ISIS supports clear text and HMAC-MD5 -must define key chain first -can authenticate at interface/neighbor level or at area or domain wide. Area wide means only within Level 1 routers. Domain wide means within L2 and L1/L2 routers. -L1 and L2 authentication can be configured separately and can be different key strings -authenticating at the interfacelevel means that the authentication is sent with the Hello packets, this means that when configuring authentication on the interface levels, in order for the neighbors to be adjacent, they must authenticate -authentication at the area or domain wide routers will authenticate within the LSP, CSNP, and PSNP packets. No authentication during the Hello packet exchange. This means that the area or domain wide routers can become adjacent but will not exchange LSPs successfully if authentication is configured wrong. -what this also means is that for L1/L2 and L2 routers, authentication could be configured on the interface for neighbor Adjacency Authentication while configuring at the area or domain wide authentication for the LSP could be configured on the router config mode Single Topology -aka Integrated ISIS to run SPF for both IPv4 and IPv6 instances i.e. default metric of 10 can be used for both SPF calculation for IPv4 and IPv6 -a single topology for IPv4 and IPv6 ISIS routing -on single topology mode, if both IPv4 and IPv6 are configured on the router, then every link that has an IPv4 address must have an IPv6 address, and every interface with an IPv6 address must have an IPv4 address configured Multi Topology -separate instances for IPv4 and IPv6 topologies -by default, all routers operate at Single Topology, to change this go to IPv6 AFI config mode and use command "multi-topology" to enable. A router examines an IS-IS packet and examines the TLV to know if the neighbor that sent the packet has Single or Multi Topology enabled -a router examines the TLV packets to determine if it is Single or Multi Topology -if a router cannot or doesn't need to use IPv6 but other routers use IPv4/IPv6 and Multi topology, the Multi topology routers configure "multi-topology transition" under the IPv6 AFI, this allows the routers to operate at the Multi Topology mode BUT can send and forward both Single Topology and Multi Topology TLV packets, allow the routers to forward both Single and Multi Topology TLVs so the lone Single Topology router will still be able to form Adjacency with the other routers. Because Adjacency cannot be formed between routers that run only Single topology with routers that run Multi Topology -e.g. if within a domain all routers are configured for IPv6 and IPv4 routing and configured for Multi Topology but there are some routers that do not have IPv6 enabled or doesn't support it, then ISIS can be configured on those routers to only forward both Single and Multi Topology packets via IPv6 AFI command "multi-topology transition". -when you configure "multi-topology transition" under IPv6 AFI it means the router can send both Single and Multi Topology TLV packets, means that it will form adjacency with routers that can only operate at Single Topology, because by default neighbors that run Multi Topology will not be adjacent with Single Topology neighbors Route Leaking -when a Level 2 network route is sent to a Level 1 router -by default can't route leak into Level 1, might cause loop -Leaking can be enabled via redistirbuting Level 2 into Level 1 with either route-map or distribute-list to filter only selected routes -L1/L2 can route leak by turning the Up/Down bit (1) on the LSP Updates to prevent loop. When an L1/L2 route learns of an LSP from a Level 1 router and the LSP has the Up/Down Bit enabled, it will not allow it to enter the Level 2 database, because it knows that the LSP originated from another L1/L2 router ISIS Terms LSP - Link State PDU, this is similar to the LSA in OSPF. It advertises connected and route destinations to neighbors. CSNP - Complete Sequence Number PDU, Sent on the Broadcast Network with neighbors to advertise a description of the entire Level (1 or 2) LSP database. Sent by the DIS. If the other neighbor is missing a LSP, then the neighbor can send an PSNP to request for the missing LSP in broadcast networks. DIS - Designated Intermediate System, on the Broadcast Network, a DIS is elected based on the highest priority configured (127, default 64). Election can be preempted i.e. if one IS is already the DIS but another comes into the broadcast segment with a higher priority, the new IS will take over as DIS (unlike OSPF). The tie-breaker is the highest SNPA (MAC Address) of the candidates. There is not Backup DIS (Unlike OSPF). PSNP - Partial Sequence Number PDU, can be used to be similar to OSPF LSA Request or can be used as an LSP Acknowledgement. Depending on the link, on P2P it is used as an ACK packet in response to received LSP from neighbor. In Broadcast Networks, it is used as a form of LSA Request similar to OSPF, in that if a neighbor received an CSNP and determines that it is missing some LSPs in the list, it will send the PSNP to request for the missing LSP. NET - Network Entity Title, used as the address that defines and is required for router ISIS to start the process. Range from 8 bytes to 20 bytes, total of address must be even numbered. xx.xxxx....yyyy.yyyy.yyyy.zz where x defins the Area ID and y defines the system ID (like router-id) and z is the N-Selector (Must always be 00 for ISIS). Broadcast Network - DIS is elected on this network. CSNPs are sent on this network as well. Point-To-Point Network - one neighbor on each side of the link Authentication - ISIS supports both clear text and HMAC-MD5 in the form of key chains. There are interface and area or domain wide authentication methods. Interface authentication is configured at the interface level and authenticates the neighbor adjacency, this means that the neighbors will not be adjacency if the passwords are configured incorrectly. In area wide authentication, it is configured under the area command in router configuration. Area wide authentication refers to Level 1 authentication and only authentications of the L1 LSP, CSNP, and PSNP. Domain wide authentication refers to Level 2 authentication. Domain authentication differs in that it authenticates the L2 LSP, CSNP, and PSNP. Both Area and Domain wide authenticates the LSPs and not the neighbor Hello packets, this means the neighbors can be adjacent but will not exchange LSPs. L1 and L2 can both have separate authentication configuration. Area - not similar to OSPF areas in terms of flooding scope. Area must be configured the same between Level 1 only routers, but for Level 2 the area doesn't need to match and still be adjacent. Level 1 - similar to Totally NSSA in that by default there are no inter-area routes advertised into Level 1. Also, the L1/L2 routers will advertise only a default route into the L1 routers if the L1/L2 has connections to other L2 areas. Level 2 - similar to OSPF backbone area, in that there must only be one Level 2 Domain and all other Level 1 areas must connect. L2 routes by default do not get advertised into L1 areas. Level 1/2 - by default Cisco routers are in the L1/2. The router will have a separate LSPDB for both Level 1 and Level 2 routers. Separate adjacencies are formed between a neighbor for L1/L2. Metric - considered "narrow", default metric of 10 for Cisco router interfaces. The max is 63 for default metric. The max is 1023 for total destination routes. Default metric is 6 bit. Metric can be converted to extended or wide metric, which is 32 bit long. Wide metric also allows for IP Reachability TLV that allows for MPLS TE to be possible. Configured as "metric-style wide". Could also configure metric to support both default and wide "metric-style wide transition" Single Topology - running both IPv4 and IPv6 SPF as one instance. No need for separate SPF calculations, this also means that if you change the metric on one interface, it will be the change of metric on both the IPv4 and IPv6 metrics. Multi Topology - segregates the IPv4 and IPv6 SPF instances. Configured under the IPv6 AFI "multi-topology" Attached Bit - advertised by the L1/L2 routers into the L1 routers to let the L1 routers know that the L1/L2 router has a connection to another area. Usually advertised with the default route. If there is more than one default route LSP with the attached bit set, the L1 router will choose the LSP that is metrically closer. Internal/External - Internal routes are usually considered L1 routers. External are usually for L2 and L1/L2 routers. Overload Bit - attached on the LSP to let other routers know that the local router is experience high memory, CPU, or system errors. Also, can be used to indicate that the local router has BGP but it hasn't converged yet. When OL bit is set, the other routers know now not to use the advertising router as a transit destination to other routes (that are not directly connected). Up/Down Bit - used for route leaking from L1/L2 routers into an Level 1 area to let L1/L2 routers know that a route originated from another L1/L2. Route Leaking - process of redistributing Level 2 routes into Level 1 routers, configured by selecting the filtered routes via route-maps or distribute-list. When an L1/L2 leaks into the L1 routers, it will set the Up/Down bit on the LSPs and send it to the L1 routers. This is to prevent situations that can cause routing loops i.e. L1/L2 routes entering into L1 routers and someone another L1 router picks it up and advertises it back to another L1/L2 router, the other L1/L2 router will see the Up/Down Bit set and will know that the route came from another L1/L2 and therefore will not allow the LSP to enter the L2 domain. Neighbor Adjacency - formed via 3-way handshake similar to OSPF. When a neighbor sends a Hello and also receives a Hello from its neighbor. In the neighbor's Hello message, the local router will see it's own System ID. This indicates 3-way communication and establishes adjacency.

Autoconfig/SLAAC, temporary addresses

Temporary Addresses -random generated IPv6 addresses used by clients (e.g. Windows PC) to temporarily assign itself an IPv6 address to use. Can be combine with the IPv6 prefix it receives from the RA. -IPv6 SLAAC could be used by two methods; combining FFFE with the MAC of the interface, or use the Private addresses that are randomly generated by the client.