VPN notes -sham links and domain id for ospf

Sham links
---------------

Configuring OSPF Sham Links for Layer 3 VPNs

When you configure OSPF between the PE and CE routers of a Layer 3 VPN, you can also configure OSPF sham links to compensate for issues related to OSPF intra-area links.

The following sections describe OSPF sham links and how to configure them:

• OSPF Sham Links Overview
• Configuring OSPF Sham Links
• OSPF Sham Links Example

OSPF Sham Links Overview

Figure 19 provides an illustration of when you might configure an OSPF sham link. Router CE1 and Router CE2 are located in the same OSPF area. These CE routers are linked together by a Layer 3 VPN over Router PE1 and Router PE2. In addition, Router CE1 and Router CE2 are connected by an intra-area link used as a backup.

OSPF treats the link through the Layer 3 VPN as an interarea link. By default, OSPF prefers intra-area links to interarea links, so OSPF selects the backup intra-area link as the active path. This is not acceptable in configurations where the intra-area link is not the expected primary path for traffic between the CE routers.

An OSPF sham link is also an intra-area link, except that it is configured between the PE routers as shown in Figure 19. You can configure the metric for the sham link to ensure that the path over the Layer 3 VPN is preferred to a backup path over an intra-area link connecting the CE routers.

Figure 19: OSPF Sham Link

You should configure an OSPF sham link under the following circumstances:

• Two CE routers are linked together by a Layer 3 VPN.
• These CE routers are in the same OSPF area.
• An intra-area link is configured between the two CE routers.

If there is no intra-area link between the CE routers, you do not need to configure an OSPF sham link.

For more information on OSPF sham links, see the Internet draft draft-ietf-l3vpn-ospf-2547-01.txt, OSPF as the PE/CE Protocol in BGP/MPLS VPNs.

Configuring OSPF Sham Links

The sham link is an unnumbered point-to-point intra-area link and is advertised by means of a type 1 link-state advertisement (LSA). Sham links are valid only for routing instances and OSPF version 2.

Each sham link is identified by a combination of the local and remote sham link end-point address and the OSPF area to which it belongs. Sham links must be configured manually. You configure the sham link between two PE routers, both of which are within the same VRF routing instance.

You need to specify the address for the local end point of the sham link. This address is used as the source for the sham link packets and is also used by the remote PE router as the sham link remote end-point.

The OSPF sham link’s local address must be specified with a loopback address for the local VPN. The route to this address must be propagated by BGP. Specify the address for the local end point using the local option of the sham-link statement:

sham-link {

local address;

}

You can include the sham-link statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols ospf]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

The OSPF sham link’s remote address must be specified with a loopback address for the remote VPN. The route to this address must be propagated by BGP. To specify the address for the remote end point, include the sham-link-remote statement:

sham-link-remote address <metric number>;

You can include the sham-link-remote statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols ospf area area-id]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id]

Optionally, you can include the metric option to set a metric value for the remote end point. The metric value specifies the cost of using the link. Routes with lower total path metrics are preferred over those with higher path metrics.

You can configure a value from 1 through 65,535. The default value is 1.

OSPF Sham Links Example

This example shows how to enable OSPF sham links on a PE router.

The following is the loopback interface configuration on the PE router. The address configured is for the local end point of the OSPF sham link:

[edit]

interfaces {

lo0 {

unit 1 {

family inet {

address 10.1.1.1/32;

}

}

}

}

The following is the routing instance configuration on the PE router, including the configuration for the OSPF sham link. The sham-link local statement is configured with the address for the local loopback interface:

[edit]

routing-instances {

example-sham-links {

instance-type vrf;

interface e1-1/0/2.0;

interface lo0.1;

route-distinguisher 3:4;

vrf-import vpn-red-import;

vrf-export vpn-red-export;

protocols {

ospf {

sham-link local 1-.1.1.1;

area 0.0.0.0 {

sham-link-remote 10.2.2.2 metric 1;

interface e1-1/0/2.0 metric 1;

}

}

}

}

}

 

 

 

 

 

OSPF domain-id

-------------

 

For most OSPF configurations involving Layer 3 VPNs, you do not need to configure an OSPF domain ID. However, for a Layer 3 VPN connecting multiple OSPF domains, configuring OSPF domain IDs can help you control LSA translation (for Type 3 and Type 5 LSAs) between the OSPF domains and back-door paths. Each VPN routing and forwarding (VRF) table in a PE router associated with an OSPF instance is configured with the same OSPF domain ID. The default OSPF domain ID is the null value 0.0.0.0. As shown in Table 4, a route with a null domain ID is handled differently from a route without any domain ID at all.

Table 4: How a PE Router Redistributes and Advertises Routes

Route Received	Domain ID of the Route Received	Domain ID on the Receiving Router	Route Redistributed and Advertised As
Type 3 route	A.B.C.D	A.B.C.D	Type 3 LSA
Type 3 route	A.B.C.D	E.F.G.H	Type 5 LSA
Type 3 route	0.0.0.0	0.0.0.0	Type 3 LSA
Type 3 route	Null	0.0.0.0	Type 3 LSA
Type 3 route	Null	Null	Type 3 LSA
Type 3 route	0.0.0.0	Null	Type 3 LSA
Type 3 route	A.B.C.D	Null	Type 5 LSA
Type 3 route	Null	A.B.C.D	Type 5 LSA
Type 5 route	Not applicable	Not applicable	Type 5 LSA

You can configure an OSPF domain ID for both version 2 and version 3 of OSPF. The only difference in the configuration is that you include statements at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level for OSPF version 2 and at the [edit routing-instances routing-instance-name protocols ospf3] hierarchy level for OSPF version 3. The configuration descriptions that follow present the OSPF version 2 statement only. However, the substatements are also valid for OSPF version 3.

To configure an OSPF domain ID, include the domain-id statement:

domain-id domain-Id;

You can include this statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols ospf]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

You can set a VPN tag for the OSPF external routes generated by the PE router to prevent looping. By default, this tag is automatically calculated and needs no configuration. However, you can configure the domain VPN tag for Type 5 LSAs explicitly by including the domain-vpn-tag number statement:

domain-vpn-tag number;

 

MPLS notes

Common label distribution methods

Downstream on demand - MPLS device do not signal a FEC to label binding unless it is requested by an upstream device

Downstream unsolicited - MPLS device will signal FEC to label bindings without waiting for a request from upstream

Liberal label retention mode - maintains the binding between a label and a FEC which are received from LSRs which are not its next hop for that FEC eg:- LDP

Conservative label retention mode - discards such bindings

Ordered control - LSR will not signal FEC to label binding to its peer unless it is the egress of the LSP or until it has received a label from the peer

Independent control - LSR will signal FEC to label bindings independent of the other routers

• Downstream on demand, ordered control with RSVP-TE


• Downstream unsolicited, independent control or ordered control with LDP(ordered control is default)

BGP accepts only downstream unsolicited, ordered control.

How does a router distinguish between a normal IP packet and an MPLS packet?
By using the ethertype/length field of the ethernet header.(13 and 14 octects after preamble) A value of 0x0800 indicates IP packet whereas 0x8847 indicated MPLS unicast packet.

My first touch- Optical Networking

Introduction
Optical networking is some flashing light moving back and forth across a glass rod. This flashing light carries the information traveling between networking components, such as optical switches and routers.

Optical networking is enabled because of two improvements in the field of shining a flashlight in one end of a glass rod:
-> The glass used in fiber optics is specially designed so that it is low in impurities. Further, within the fiber itself, the light can bounce around and propagate to the far end.
-> Very powerful lights called lasers are capable of traveling much farther than regular light.

Optical networking, offers enhancements over conventional networking because it provides three important network performance improvements: speed, capacity, and distance.

How Optical Networking Works
The transmission of light in optical fiber is most commonly explained using the principle of total internal reflection (TIR). This means that 100 percent of light that strikes a surface is reflected. For means of comparison, a mirror reflects about 90 percent of the light that strikes it, so you can see that TIR is a high standard to meet.

When light is emitted be it from a powerful laser or from candlelight, the radiated light can bounce, assuming it strikes the right material. Light can be manipulated in two basically different ways:
-> Reflection means that the light bounces back.
-> Refraction means that the light’s angle is altered as it passes through a different medium (like a glass of water, a prism, or a fiber). The angle is determined by the angle of incidence. The angle of incidence is the angle at which light strikes the interface between an optically denser material and an optically thinner one.

For TIR to occur, the following conditions must be present:
-> Beams of light must pass from a dense material to a less dense material.
-> The incident angle must be less than the critical angle. The critical angle is the angle of incidence at which light stops being refracted and is insteadtotally reflected.

The core and cladding are constructed out of optically denser and optically thinner types of highly pure silica glass. These components are mixed with components called dopants (like erbium), which adjusts their refractive indices. The difference between the refractive indices of the two different kinds of glass causes most of the emitted light to bounce off the cladding and stay within the core, traveling to the endpoint. The critical angle requirement is met by controlling the angle at which light is beamedinto the core.

Optical Fibers
For optical networking to happen, it must use a fantastically pure kind of glass. In this case, silica glass is the blend of choice. Even though it is exceptionally pure, there is still a little loss of light as the light travels through. The loss, however, is much less pronounced than with ordinary glass.

Once you have a core of pure silica, an extra layer of glass (called cladding) is wrapped around the core. The cladding has a lower refractive index than the core. The difference in refractive indices guides the light into the core and prevents the light from escaping through the sides of the fiber.

An optical signal can generate many different light waves, which can travel through the fiber simultaneously. This is the method used in multimode fibers (which provides a medium over which a number of concurrent transmissions can be sent). Unfortunately, this can also cause problems as the waves arrive at the end of the fiber and are out of sync. Most optical networks use single-mode fiber, which has a rather small fiber core (about 9 micrometers—a micrometer is a millionth of a meter), thus ensuring that only a single light wave traverses the fiber, alleviating receiving problems

Fiber optic cables contain extremely thin strands (10 micrometers across) of silica glass, which are then encased in a thicker, denser layer of silica glass (about 125 micrometers across). Once a protective wrap is applied, the fiber optic cable is a quarter of a millimeter in diameter. The glass used within the fiber is highly pure, thus ensuring that the photons keep moving. Also, these strands of glass can be hundreds or thousands of miles long.

Design
Optical fiber is composed of three parts:
-> The core, which carries the light
-> Cladding, which traps the light in the core, causing total internal reflection
-> The Buffer, which is the insulating wrap protecting the fiber


1. First, the light source (in this case a laser) converts the network’s electrical signal into pulses of light.
2. The light is injected into the core of the fiber.
3. The photons bounce off of the border between the core and the cladding. Because the core and the cladding have different refractive indices, the photons are bounced back into the core.
4. The photons continue through the length of the fiber.
5. Ultimately, they exit the fiber and are converted back into electrical signals by the light detector.
6. Because the fiber doesn’t exist in a harm-free environment, the core and cladding are encased in a protective wrap called the buffer. The buffer makes the fiber more durable and easy to handle.


Types of Fiber
Fiber comes in two basic types, single-mode and multimode.
-> Single-mode fiber has a core size of only about six times the wavelength of the fiber. In turn, this causes all the light to travel across a single path (in optical networking parlance, a path is referred to a mode). Single-mode fiber is useful because modal dispersion disappears and the bandwidth of the fiber is at least 100 times greater than graded index fiber.
-> Multimode fiber allows light to travel across several different paths through the core of the fiber, which enter and leave the fiber at various angles

Multimode fiber can further be broken down into two different types of fiber.They differ based on the index.
-> Step index fiber has a core made from a single type of glass. Light within the fiber travels in straight lines and reflects off the cladding. Step index fiber has a numerical aperture that is determined by the differences in the indices of refraction of the core and cladding. Because each mode of light travels a different path, a pulse of light is dispersed while traveling through the fiber, thereby restricting the bandwidth of step index fiber.
-> Graded index fiber has a core that is composed of many different layers of glass. The layers differ because of their densities, thereby transmitting light along a parabolic path. In glass with a lower index of refraction, light travels faster as it approaches the outside of the core. Conversely, light traveling closest to the core will travel at the slowest pace. Since the fiber contains these different layers of glass, the bandwidth capacity of the fiber is 100 times greater than for step index fiber.

Size Matters
Fiber can also be categorized by its size. The most popular fiber in multimode today is 62.5/125.

The first multimode fiber in wide use was 50/125. Telephone companies needing more bandwidth for long-distance uses were the first to adopt this type of fiber. Because it has a small core and a low numeric aperture, it was difficult to connect to LED sources. Because of this difficulty, a move was made to 100/140 fiber. It worked well, but because the core was so large, it was expensive to manufacture. Further, it had a unique cladding that required connector manufacturers to develop connectors specifically for it. The next popular size of fiber was 85/125. It provided connectivity to LED sources but used the same connectors as other fibers. Finally, 62.5/125 became the de facto standard for when IBM turned to 62.5/125 for its fiber optic hardware. When this occurred, other types of fiber have dropped away, leaving 62.5/125 as the industry standard.

My FAQs 3 - BGP

port ?
TCP 179

Goals of bgp?
->First, it needed to support the meshlike connectivity of ISP networks.
->It also required extensive policy controls to enforce the administrative policies of each ISP.
->It needed the ability to reliably transmit routing information between BGPpeers.
->Finally, the protocol required the ability to scale route advertisements beyond a few thousand routes

Loop prevention?
Provides loop prevention through an attribute called the AS Path, which is a collection of AS numbers through which a particular route has passed. The use of this attribute also leads to a common description of BGP as a path-vector protocol. In a BGP network, each router knows the networks a route has traversed (the path) and the direction to send a packet for the route (the vector).

EBGP?
When two BGP routers are in different AS networks, the session between them is considered an external BGP (EBGP) connection. By default, an EBGP connection is formed between directly connected peers. This requirement is enforced by setting the time-to-live (TTL) of the IP packet to 1, thereby not permitting an intermediate router to forward the BGP packet. Once the EBGP session is established, the two peers can begin to exchange routing knowledge with each other. All active BGP routes learned from other EBGP sessions are advertised. In addition, all active BGP routes learned from internal BGP peers are advertised.

IBGP?
The connection of two BGP routers within the same AS is called an internal BGP(IBGP) connection. Unlike the EBGP variety, there is no requirement forphysical connectivity between IBGP peers. The TTL of the BGP packets is set to64 to allow for connectivity across an AS. Once the IBGP session is established, routes are exchanged between the peers. By default, only active BGP routes learned from EBGP peers are advertised across an IBGP session.

BGP FSM?
Idle Idle is the initial neighbor state, in which it rejects all incoming session requests. After the BGP process starts, a TCP session is initiated to the remote peer. The local router transitions to the Connect state and begins to listen for a connection initiated by the remote router.
Connect In the Connect state, the local router is waiting for the TCP session to be completed. If it is successful, the local router sends an Open message to the peer and transitions to the OpenSent state. Should the TCP connection attempt fail, the local router resets the ConnectRetry timer and transitions to the Active state. If the ConnectRetry timer reaches 0 while the local router is in the Connect state, the timer is reset and another connection attempt is made. The local router remains in the Connect state.
Active In the Active state, the local router is trying to initiate a TCP session with its peer. If the session establishes successfully, an Open message is sent and the local router transitions to the OpenSent state. If the TCP session fails to establish, the local router initiates another session, sets the ConnectRetry timer to 0, and transitions back to the Connect state. Attempts by the remote router to connect from an unexpected IP address for the session causes the local router to refuse the connection. The local router remains in the Active state and resets the ConnectRetry timer.
OpenSent The OpenSent state is reached upon a successful TCP establishment. The local router sends a BGP Open message and waits for an Open message from the remote peer.
When a valid Open message is received, the local router begins to send Keepalive messages to the remote router. The BGP peers negotiate the session parameters and the local router transitions to the OpenConfirm state. Should a TCP disconnect be received while in this state, the local router terminates the BGP session, resets the ConnectRetry timer, and transitions back to the Active state.
OpenConfirm When the local router receives a valid Open message from the remote peer, the OpenConfirm state is reached. The local router sends Keepalive messages to the peer and waits for a Keepalive message in return.
Established The Established state is achieved when a Keepalive message is received while in the OpenConfirm state. This is the final state of a peer relationship and designates a fully operational connection.
Two BGP peers can exchange routing information only when the Established state is reached. All other BGP peering states designate a nonfunctional session

Message types?
The Open Message The Open message is the first packet BGP sends to a peer after the TCP connection has been established. It allows the two peers to negotiate the parameters of the peer session. These parameters include the BGP version, the hold time for the session, authentication data, refresh capabilities, and support for multiple Network Layer Reachability Information (NLRI).
The Update Message Routing information is sent and withdrawn in BGP using the Update message. If needed, each message contains information previously advertised by the local router that is no longer valid. The same message may also contain new information advertised to the remote peer. Each Update contains a single set of BGP attributes and all routes using those attributes. This format reduces the total number of packets routers send between BGP peers when exchanging routing knowledge.
The Notification Message When a BGP peer detects an error within the session, it sends a Notification message to the remote router and immediately closes both the BGP and TCP sessions.
The Keepalive Message A BGP Keepalive message contains only the 19-octet message header and no other data. These messages are exchanged at one-third the negotiated hold-time value for the session, if necessary. The advertisement of an Update message within the keepalive period resets the timer to 0. In short, a Keepalive is sent only in the absence of other messages for a particular session. Should the local router not receive a Keepalive or Update message within the hold-time period, a Notification message of Hold Time Expired is generated and the session is torn down.

Routing Information bases?
Each BGP router establishes memory locations in which to store routing knowledge. These are collectively known as a Routing Information Base (RIB). A BGP peer maintains three categories of RIBs: the Adjacency-RIB-In, the Local-RIB, and the Adjacency-RIB-Out.
Adjacency-RIB-In An Adjacency-RIB-In table is created on the local router for each established BGP peer. All routes received from the peer are placed in the appropriate memory table
Local-RIB The best path to each destination is stored in the Local-RIB table. These are the routes that thelocal router uses to forward user data traffic
Adjacency-RIB-Out Each established BGP peer also creates its own Adjacency-RIB-Out table for outbound route advertisements. Only routes currently located in the Local-RIB are eligible to be placed in this outbound database. In other words, a BGP router advertises only routes that it is currently using to forward data traffic.

Route selection process?
1. The Next Hop attribute value for each route must be reachable in the local routing table; otherwise, the local router discards the route.
2. The router selects the route with the highest Local Preference attribute value.
3. The router selects the route with the shortest AS Path length.
4. The router selects the route with the smallest Origin attribute value.
5. The router selects the route with the smallest Multiple Exit Discriminator attribute value. This step is executed, by default, only for routes from the same neighboring AS.
6. The router selects routes learned from an EBGP peer over routes learned from an IBGP peer. If the remaining routes are all EBGP-learned routes, the router skips to step 9.
7. The router selects the route with the smallest IGP metric to the advertised BGP Next Hop.
8. If Route Reflection is used for IBGP peering, the router selects the route with the shortest Cluster-List length.
9. The router selects the route from the peer with the smallest numerical Router ID.
10. The router selects the route from the peer with the smallest numerical Peer Address.

BGP attributes?
Optional Bit (Bit 0) An attribute is either well known (a value of 0) or optional (a value of 1).
Transitive Bit (Bit 1) Optional attributes can be either nontransitive (a value of 0) or transitive (a value of 1). Well-known attributes are always transitive.
Partial Bit (Bit 2) Only optional transitive attributes use this bit. A 0 means each BGP router along the path recognized this attribute. A 1 means that at least one BGP router along the path did not recognize the attribute

Next Hop Next Hop, attribute type code 3, is a well-known mandatory attribute
Local Preference Local Preference, attribute type code 5, is a well-known discretionary attribute.
AS Path AS Path, attribute type code 2, is a well-known mandatory attribute.Origin Origin, attribute type code 1, is a well-known mandatory attribute.
Multiple Exit Discriminator Multiple Exit Discriminator (MED), attribute type code 4, is an optional nontransitive attribute.
Community Community, attribute type code 8, is an optional transitive attribute. It is used to administrativelygroup routes for a common policy action.

My FAQs 2 - OSPF

runs over?
Directly over IP

packet types?
Hello
Database description
Link state request
Link state update
Link state ack

hello?
for discovery of OSPF neighbors. Addressed to multicast 224.0.0.5 for broadcast and point-to-point interfaces. Hello on other interfaces is unicast. Default hello interval - 10 sec

DD?
The DD packet, type code 2, summarizes the local database by sending LSA headers to the remote router. The remote router analyzes these headers to determine whether it lacks any information within its own copy of the link-state database.

virtual links?
Virtual links are used for:

Linking an area that does not have a direct connection to the backbone.

Linking the backbone in case of a partitioned backbone.

Area without direct connection to the backbone
The backbone always need to be the center of all other areas, in some rare case where it is impossible to have an area physically connected to the backbone, a virtual link is used. This virtual link will provide that area a logical path to the backbone area. This virtual link is established between two ABRs that are on one common area, with one of the ABRs connected to the backbone area.

Partitioned Backbone
OSPF allows for linking a partitioned backbone using a virtual link. The virtual link should be configured between two separate ABRs that touch the backbone are from each side and having a common area in between.

LSA types?
1 Router LSA
2 Network LSA
3 Network summary LSA
4 ASBR summary LSA
5 AS external LSA
6 Group membership LSA
7 NSSA external LSA

OSPF neighbors stuck in ex-start state?
1. MTU mismatch b/w neighbors
2. Can't pass large packets in L2

Adjacency states?

Down Down is the starting state for all OSPF routers. A start event, such as configuring the protocol, transitions the router to the Init state. The local router may list a neighbor in this state when no hello packets have been received within the specified router dead interval for that interface.

Init The Init state is reached when an OSPF router receives a hello packet but the local router ID is not listed in the received Neighbor field. This means that bidirectional communication has not been established between the peers.

Attempt The Attempt state is valid only for Non-Broadcast Multi-Access (NBMA) networks. It means that a hello packet has not been received from the neighbor and the local router is going to send a Unicast hello packet to that neighbor within the specified hello interval period.

2-Way The 2-Way state indicates that the local router has received a hello packet with its own router ID in the Neighbor field. Thus, bidirectional communication has been established and the peers are now OSPF neighbors. On Point-to-Point and Point-to-Multipoint interfaces, the state will be changed to Full. On Broadcast interfaces, only the DR/BDR will advance to Full state with their neighbors, all the remaining neighbors will remain in the 2-Way state.

ExStart In the ExStart state, the local router and its neighbor establish which router is in charge of the database synchronization process. The higher router ID of the two neighbors controls which router becomes the master.

Exchange In the Exchange state, the local router and its neighbor exchange DD packets that describe their local databases.

Loading Should the local router require complete LSA information from its neighbor, it transitions to the Loading state and begins to send link-state request packets.

Full The Full state represents a fully functional OSPF adjacency, with the local router having received a complete link-state database from its peer. Both neighboring routers in this state add the adjacency to their local database and advertise the relationship in a link-state update packet.

Router LSA?
For advertising the networks connected to the local router. This includes all links connected to the router, the metrics of those interfaces, and the OSPF capabilities of the router. It has area scope.

Need for DR and BDR?
Broadcast segments in a network, such as an Ethernet link, pose a special problem to link-state protocols and their peer-to-peer nature. Multiple routers on the same physical segment share the resources of that link and produce a lot of redundant information
The ramifications of this process are twofold. First, each router reports the same set of information, the Ethernet link, to the rest of the OSPF network. Second, and perhaps more damaging, every router floods LSAs to each of its adjacent neighbors using the 224.0.0.5 multicast address.

DR?
Each broadcast segment in an OSPF network elects a designated router to act as the main point of contact for the network segment. Each router on the link must become adjacent with the DR, which handles all LSAs for the network. Each router sends the DR information using a new multicast destination address of 224.0.0.6, AllDRRouters. The designated router generates a network LSA, type code 2, to represent the broadcast segment to the rest of the network.

DR election?
Based on priority and router id. Router with the highest priority (value 0 -ineligible for election) becomes DR. If there is a tie, higher router id is selected. The wait time for electing the first designated router on the segment arises from an OSPF timer called the WaitTimer. This is to guarantee exchange of hellos b/w ospf routers

When a higher priority router comes to a network, it will not immediately become the DR/BDR. It has to wait till the next electioni to become BDR first.

Backbone area?
Area 0.0.0.0 connects all areas and redistributes all non-backbone routing info b/w the areas. All other areas must be connected to the backbone area.

OSPF router types?
Internal router A router that maintains all operational interfaces within a single area is known as an internal router. An internal router may belong to any OSPF area.
Backbone router A router that has at least one interface in area 0 is known as a backbone router.
Area border router The area border router (ABR) connects one or more OSPF areas to the backbone. This means that at least one interface is within area 0 while another interface is in another area. The ABR plays a very important role in an OSPF network.
Autonomous System boundary router An Autonomous System boundary router (ASBR)
injects external routing knowledge into an OSPF network.

N/w summary LSA?
Routing knowledge crosses an area boundary in an OSPF network by using a network summary LSA, type code 3. By default, each Type 3 LSA matches a single router LSA or network LSA on a one-for-one basis. The network summary LSA also has an area-flooding scope.


AS external LSA?
Both the router and network summary LSAs are effective at propagating internal OSPF routing knowledge throughout the network. They are not capable, however, of carrying external routing information. The AS external LSA, type code 5, was defined for this explicit purpose. External routes in an OSPF network can come in multiple forms like redistribute static routes, or from a network(internal or external) that is not currently running OSPF.

ASBR summary LSA?
While the Type 5 LSA provides the network information necessary to reach the external networks, the OSPF routers may not automatically begin using that data. The address of the ASBR must be known in the link-state database via a router LSA. For each ASBR reachable by a router LSA, the ABR creates an ASBR summary LSA, type code 4, and injects in into the appropriate area. This LSA provides reachability information to the ASBR itself. ASBR summary LSA has area scope and is generated by an ABR.

Stub areas?
An OSPF stub area provides for a smaller link-state database by restricting the presence of AS external LSAs within the area. Since a single Type 5 LSA is generated for each external route, the potential number of LSAs in an OSPF network can be quite sizeable. ( disadvantage of forwarding potentially unroutable
packets)

The responsibility for enforcing an OSPF stub area rests with the ABR. Under normal circumstances, the ABR re-floods the Type 5 LSAs into the area. When configured as a stub area, however, the ABR simply does not flood the AS external LSAs into the area. To provide the required IP reachability, the ABR should instead generate a summary LSA for the default route and inject that into the stub area

Totally stubby area?
An expansion of the concept of a stubby area. The ABR in a totally stubby area stops creating and flooding Type 3 LSAs for the backbone and for area 22 routes. The default Type 3 LSA is generated to provide reachability to all routes outside area 10. The basic operation of the stub area did not change in this situation. Types 4 and 5 LSAs are still not present in the area 10 routers.

Not so stubby area?
Suppose that your OSPF network requires connectivity to a partner that is using RIP within its network. The routers in this area have been suffering from database issues that caused the area to become stub. This exact set of circumstances led to the development of the not-so-stubby area (NSSA).

A not-so-stubby area is an OSPF stub area that allows some external routes to be present in the database. This is accomplished with a new NSSA external LSA, type code 7. The Type 7 LSA carries external routing information from the ASBR within the NSSA. It has an area flooding scope, so only routers in the NSSA receive the Type 7 LSA. The external routing information within the LSA is converted by the ABR into an AS external LSA at the area boundary. The ABR floods the Type 5 LSA into the OSPF domain, and no other routers in the network are aware of the NSSA configuration.

My FAQs 1 - TCP/IP, RIP

How are the protocols classified?

Protocols are classified into two based on whether they use hop count as the metric or not. Distance vector protocols like RIP use Bellman Ford algorithm. Link state protocols like OSPF uses complete knowledge of the network to detemine the path to destination.

Another classification is based on whether they are running in the same AS or different AS. Protocols like OSPF,RIP which run within the same AS are called Interior Gateway Protocol(IGP) and others are Exterior Gateway Protocol(EGP)

What is Jumbo packet?
Packets whose size exceeds the MTU of the medium. Such packets are fragemented if the Don't Fragment bit in IP header is not set and discarded otherwise

What is ARP?

ARP is used for obtaining the hardware address for the given IP address. ARP requests are sent as broadcast to ff:ff:ff:ff:ff:ff:ff and ARP replies are sent as unicast.

Different types of ARP?

RARP- Reverse Address Resolution - used by diskless machines to obtain their own IP for the MAC address given
GARP- Gratuitous ARP - both request and reply - Source and destination IP set to the address of the machine issuing the request. Destination MAC is broadcast. Usually no reply obtained.
-> Used to detect IP conflicts
->Used to update other machines' arp table
->Every time an interface goes up, the driver for that interface sends out a gratuitous arp to preload the arp tables of other machines.
Proxy arp - Router will respond with its own MAC on the behalf of the host to which the arp request is sent. Usually occur when two hosts are connected over a router.

Collision domain and broadcast domain?
Collision domain- Network segment where packets can collide while sent over that shared medium
Broadcast domain - Logical division of network where all nodes can reach each other though an L2 broadcast

CSMA/CD?
When two hosts would send at the same time, though, a collision would occur. When the signals would collide, both would be rendered unusable. A standard had to be created that would have the hosts follow rules relating to when they could send data and when they could not. This standard is Carrier Sense Multiple Access with Collision Detection, referred to as CSMA/CD.

If two of the three computers on this segment send data at the same time, a collision occurs.

To avoid this, CSMA/CD forces computers to “listen” to the Ethernet before sending in order to make sure that no other host on the wire is sending. When the Ethernet segment is not busy, the device that wants to send data can do so. The sender will then continue to listen, to make sure that sending the data didn’t cause a collision.

If a collision is heard, both of the senders will send a jam signal over the Ethernet. This jam signal indicates to all other devices on the Ethernet segment that there has been a collision, and they should not send data onto the wire. (A second indication of a collision is the noise created by the collision itself.)

After sending the jam signal, each of the senders will wait a random amount of time before beginning the entire process over. The random time helps to ensure that the two devices don't transmit simultaneously again.

Packet firewall filter and proxy based firewall filter?

Packet firewall filter- L3 firewall filter
Proxy based firewall filter - application layer filter

RIP - Routing Information Protocol

Protocol & port?
UDP port 520

Infinity metric/count to infinity ?

To prevent routing loops, the RIP protocol depends on a function known as “counting to infinity.” A maximum metric (the infinity metric) is defined within the protocol, and all routes with a larger metric are deemed unusable. For RIP, the maximum hop count is defined as 15. If a router receives a RIP update with a metric value over 15 (that is, 16 or greater) after it is incremented, the router must throw the update away and the destination is considered unreachable.

Messages?

Request and response
The purpose of a Request message is to ask for all or some part of the local router’s current routing table Request message has a single entry in it with a metric of 16 and an address family identifier field that contains all zeros. This message translates into “Send me your entire routing table.” A Request message may contain one or more specific route entries. In this case, the local router consults its routing table for each of the destinations listed

A RIP router receives Response messages for one of three different reasons:
>In response to a Request message generated by the local router
>A regular (unsolicited) Response message sent by a neighbor
>A triggered update Response message sent by a neighbor


Split horizon?
When the Update timer expires and a Response message is generated, split horizon prevents the local router from including any routes learned from a neighbor on the interface from which the message is being sent out.

SH with Poisoned Reverse?
Instead of never advertising a route back to the neighbor it was learned from, the router advertises it with an infinity metric.


Timers?
RIP uses a number of timers in its operation, among them the Update timer, the Hold-Down timer, the Timeout timer, and the Garbage Collection timer. A RIP router uses an Update timer to advertise its complete routing table (less split horizon) to all its neighbors. The JUNOS software uses 30 seconds as the default Update timer.

Hold down timer prevents the propagation of bad routing information throughout the network. The Hold-Down timer is used when an update is received by the local router that contains a route from a peer with a higher metric (other than infinity) than the one in the current routing table.

The Timeout timer is used to ensure that the copy of the route is valid and usable. When the route is first installed in the table, this timer is initialized to 120 seconds, its maximum value. The timer value is updated when a Response message from a neighbor is processed and the route is maintained in the table. In this case, the timer is reset to 120.

The Garbage Collection timer runs to a maximum non-configurable value of 180 seconds, at which time the route will be removed from the routing table.

Limitations ?

Scalability
RIP does not scale well for large networking environments. One issue is the maximum hop count used (discussed next). Another issue is the use of the 255.255.255.255 broadcast address for Response message updates in RIP version 1. On broadcast networks, this is quite disruptive to other IP (non-RIP) hosts.
Small hop count limit
Sixteen hops is the defined infinity metric that denotes an unreachable or unusable subnet. This value limits the size or “diameter” of the networks that can be built using RIP.
Slow convergence
Although triggered updates can help advertise new information into RIP, the timers can have the opposite effect. When a route needs to be removed from the protocol, the timer values for the Hold-Down, Timeout, and Garbage Collection timers can mean that a topology change at one end of the network may not be known at the other end of the network for several minutes.
Suboptimal routing
Since RIP routers utilize only the hop count as the metric, some suboptimal routing may occur. This occurs because hop count does not allow for dissimilar bandwidths, fewer delays, or less congestion on other alternate paths to a destination. When these alternate paths are available, RIP will always pick the one with the smallest hop count regardless of the interface speeds of the other path.
Nonhierarchical design
As the size of the RIP routing domain grows larger and approaches the maximum diameter of 15 routers, there is no mechanism to divide the domain into smaller, more manageable subdomains

RIPv2 over v1?

VLSM support By default, all RIPv2 Response updates include the subnet mask. This allows v2 routers to support variable-length subnet mask (VLSM) routing and provides for a classless network routing environment.

Multicast announcements RIPv2 sends all Request and Response messages to a multicast address (224.0.0.9) instead of the 255.255.255.255 broadcast address. This provides for better scalability since only RIP-speaking routers (or hosts) need to process the packets.

Authentication RIPv2 supports authentication by means of a password. This allows a RIP router to accept Response messages only from a “trusted” source. Although RFC 2453 specifies the use of a plain-text password only, the JUNOS software also supports the use of MD5 hashes, as defined in RFC 2082.

Route tag RIPv2 supports a 16-bit field called a route tag. This field was originally included to indicate whether the route was derived internally or externally to the RIP network. This field can also be used for other purposes, including administrative routing policy control.

Next hop address RIPv2 allows the sending router to advertise the immediate next hop address for a route entry. Similar to an ICMP redirect message, this field is helpful in a broadcast environment to avoid an extra forwarding hop when the advertising RIP router is not the immediate next hop for the route.


Configurations?

user@Cabernet# show
rip {
group neighbor-routers {
neighbor fe-0/0/0.0;
neighbor fe-0/0/1.0;
}
}

user@Cabernet> show rip neighbor
Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
fe-0/0/0.0 Up 172.16.1.2 224.0.0.9 mcast both 1
fe-0/0/1.0 Up 172.16.2.1 224.0.0.9 mcast both 1

user@Riesling> show route protocol rip
inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.2.0/24 *[RIP/100] 00:07:25, metric 2
> to 172.16.1.2 via fe-0/0/0.0
192.168.8.1/32 *[RIP/100] 00:07:25, metric 2
> to 172.16.1.2 via fe-0/0/0.0

BFD Notes

Bidirectional forwarding detection


Introduction:-

Bfd is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols.

An increasingly important feature of networking equipment is the rapid detection of communication failures between adjacent systems, in order to more quickly establish alternative paths.

The time to detect failures (“detection times”) available in the existing protocols is no better than a second, which is far too long for some applications and represents a great deal of lost data at gigabit rates. Furthermore, routing protocol Hellos are of no help when those routing protocols are not in use, and the semantics of detection are subtly different--they detect a failure in the path between the two routing protocol engines.

The goal of BFD is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and to the extent possible the forwarding engines themselves.

An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods.

It is intended to be implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated. This not only binds the protocol more to the forwarding plane, but decouples the protocol from the
fate of the routing protocol engine, making it useful in concert with various "graceful restart" mechanisms for those protocols. BFD may also be implemented in the control engine, though doing so may preclude the detection of some kinds of failures.

BFD operates on top of any data protocol being forwarded between two systems. It is always run in a unicast, point-to-point mode. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. BFD may be running at multiple layers in a system.





Protocol Overview:-

BFD is a simple hello protocol that in many respects is similar to the detection components of well-known routing protocols. A pair of systems transmits BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed.

A path is only declared to be operational when two-way communication has been established between systems, though this does not preclude the use of unidirectional links.

A separate BFD session is created for each communications path and data protocol in use between two systems

Operating Modes

BFD has two operating modes which may be selected, as well as an additional function that can be used in combination with the two modes.

The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.

The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously.

An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand modes. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode.)

Pure asynchronous mode is advantageous in that it requires half as many packets to achieve a particular detection time as does the Echo function. It is also used when the Echo function cannot be supported for some reason.

The Echo function has the advantage of truly testing only the forwarding path on the remote system. This may reduce round-trip jitter and thus allow more aggressive detection times, as well as potentially detecting some classes of failure that might not otherwise be detected.

The Echo function may be enabled individually in each direction. It is enabled in a particular direction only when the system that loops the Echo packets back signals that it will allow it, and when the system that sends the Echo packets decides it wishes to.

Demand mode is useful in situations where the overhead of a periodic protocol might prove onerous, such as a system with a very large number of BFD sessions. It is also useful when the Echo function is being used symmetrically. Demand mode has the disadvantage that detection times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand mode may not be used when the path round trip time is greater than the desired detection time.


BFD Control Packet Format:-

Generic BFD Control Packet Format

BFD Control packets are sent in an encapsulation appropriate to the environment.

The BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section, if present, is dependent on the type of authentication in use.

The Mandatory Section of a BFD Control packet has the following format:

An optional Authentication Section may be present:

Version (Vers)

Denotes the version number of the protocol. Here we define protocol version 1.

Diagnostic (Diag)

A diagnostic code specifying the local system's reason for the last session state change to states Down or AdminDown.
Values are:

0 -- No Diagnostic
1 -- Control Detection Time Expired
2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset
5 -- Path Down
6 -- Concatenated Path Down
7 -- Administratively Down
8 -- Reverse Concatenated Path Down
9-31 -- Reserved for future use

This field allows remote systems to determine the reason that the previous session failed.

State (Sta)

The current BFD session state as seen by the transmitting system.
Values are:

0 -- AdminDown
1 -- Down
2 -- Init
3 -- Up


Poll (P)

If set, the transmitting system is requesting verification of connectivity, or of a parameter change, and is expecting a packet with the Final (F) bit in reply. If clear, the transmitting system is not requesting verification.

Final (F)

If set, the transmitting system is responding to a received BFD Control packet that had the Poll (P) bit set. If clear, the transmitting system is not responding to a Poll.

Control Plane Independent (C)

If set, the transmitting system's BFD implementation does not share fate with its control plane (in other words, BFD is implemented in the forwarding plane and can continue to function through disruptions in the control plane.) If clear, the transmitting system's BFD implementation shares fate with its control plane.

The use of this bit is application dependent

Authentication Present (A)

If set, the Authentication Section is present and the session is to be authenticated.

Demand (D)

If set, Demand mode is active in the transmitting system (the system wishes to operate in Demand mode, knows that the session is up in both directions, and is directing the remote system to cease the periodic transmission of BFD Control packets.) If clear, Demand mode is not active in the transmitting system.

Multipoint (M)

This bit is reserved for future point-to-multipoint extensions to BFD. It must be zero on both transmit and receipt.

Detect Mult

Detection time multiplier. The negotiated transmit interval, multiplied by this value, provides the detection time for the transmitting system in Asynchronous mode.

Length

Length of the BFD Control packet, in bytes.






My Discriminator

A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.


Your Discriminator

The discriminator received from the corresponding remote system. This field reflects back the received value of My Discriminator, or is zero if that value is unknown.

Desired Min TX Interval

This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets. The value zero is reserved.

Required Min RX Interval

This is the minimum interval, in microseconds, between received BFD Control packets that this system is capable of supporting. If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets.

Required Min Echo RX Interval

This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting. If this value is zero, the transmitting system does not support the receipt of BFD Echo packets.

Auth Type

The authentication type in use, if the Authentication Present (A) bit is set.

0 - Reserved
1 - Simple Password
2 - Keyed MD5
3 - Meticulous Keyed MD5
4 - Keyed SHA1
5 - Meticulous Keyed SHA1
6-255 - Reserved for future use


Auth Len

The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields.



Elements of Procedure:-

A system may take either an Active role or a Passive role in session initialization. A system taking the Active role MUST send BFD Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both.) The role that a system takes is specific to the application of BFD, and is outside the scope of this specification.

A session begins with the periodic, slow transmission of BFD Control packets. When bidirectional communication is achieved, the BFD session comes Up.

Once the BFD session is Up, a system can choose to start the Echo function if it desires to and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active.

If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the detection time requirements for the session.

Once the session is up, a system may signal that it has entered Demand mode, and the transmission of BFD Control packets by the remote system ceases. Other means of implying connectivity are used to keep the session alive. If either system wishes to verify bidirectional connectivity, it can initiate a short exchange of BFD Control packets to do so.

If Demand mode is not active, and no Control packets are received in the calculated detection time, the session is declared Down. This is signaled to the remote end via the State(Sta) field in outgoing packets.

If sufficient Echo packets are lost, the session is declared down in the same manner.

If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared down in the same manner.

If the session goes down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate.

Once a session has been declared down, it cannot come back up until the remote end first signals that it is down (by leaving the Up state), thus implementing a three-way handshake.

A session may be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field.


BFD State Machine:-

The BFD state machine is quite straightforward. There are three states through which a session normally proceeds, two for establishing a session (Init and Up) and one for tearing down a session (Down.) This allows a three-way handshake for both session establishment and session teardown (assuring that both systems are aware of all session state changes.) A fourth state (AdminDown) exists so that a session can be administratively put down indefinitely.

Each system communicates its session state in the State (Sta) field in the BFD Control packet, and that received state in combination with the local session state drives the state machine.

Down state means that the session is down (or has just been created.) A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down state, the session advances to Init state; if that packet signals Init state, the session advances to Up state. Semantically, Down state indicates that the forwarding path is unavailable, and that appropriate actions should be taken by the applications monitoring the state of the BFD session. A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state.) This may be done for operational or administrative reasons, among others.

Init state means that the remote system is communicating, and the local system desires to bring the session up, but the remote system does not yet realize it. A session will remain in Init state until either a BFD Control Packet is received that is signaling Init or Up state (in which case the session advances to Up state) or until the detection time expires, meaning that communication with the remote system has been lost (in which case the session advances to Down state.)

Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails, or the session is taken down administratively. If either the remote system signals Down state, or the detection time expires, the session advances to Down state.

AdminDown state means that the session is being held administratively down. This causes the remote system to enter Down state, and remain there until the local system exits AdminDown state. AdminDown state has no semantic implications for the availability of the forwarding path.

The following diagram provides an overview of the state machine. Transitions involving AdminDown state are deleted for clarity. The notation on each arc represents the state of the remote system (as received in the State field in the BFD Control packet) or indicates the expiration of the Detection Timer.