Jncip-sp

In preparing for the JNCIP-SP, I decided to create a thread and post my learning experiences, as a way to keep myself motivated (lots of content I've never really dealt with, like QoS) and as a review. I'll be going through the blueprint listed here, starting with some ramblings about IS-IS later tonight.

I've found that there aren't as good a resources out there for the JNCIP-SP as there are for the JNCIS-SP, or even the JNCIE-SP, so I hope this thread can be a contribution to someone else's study.

Find more posts tagged with

Comments

tomtom1

IS-IS link-state PDU (LSP) types

IS-IS has different types of LSP in it's normal operation. The PDU types that are used are:

Link state PDU (LSP): Used to carry routing information.
Complete Sequence Number PDU: Used for link state database synchronization
Partial Sequence Number PDU: Used for link state database synchronization

Link state PDU

An LSP in IS-IS is used for the exchange of routing information. Every router (also known as IS in ISO terms) will create a LSP to provide topology information about networks that router is connected to. If the router also operates as the DIS for a given level it will also send a Pseudonode LSP, describing every router (IS) in the topology. Every LSP has a unique identifier and as such can be requested a CSNP or PSNP. This ID consists of the System ID, Pseudonode ID and the fragment and is reffered to as the LSPID.

Complete Sequence Number PDU

The Complete Sequence Number PDU (CSNP) is used for LSDB synchronization and more specifically list the LSPID's of the LSP's available in the network. When other routers receive the CSNP they compare the entries in this packet type to the LSPID's of their local link state database, they can flood LSP's or request LSP's if information is missing. On broadcast type networks, the CSNP can also function as an acknowledgement type packet for LSP's.

The DIS on a broadcast segment sends CSNP packets every 10 seconds.

Partial Sequence Number PDU

The Partial Sequence Number PDU can be used to request information about a specific LSP when based on a CSNP packet the router detects that information is missing. On point to point links, without a DIS, the PSNP can also function as an acknowledgement packet for LSP's.

tomtom1

IS-IS areas/levels and operations

IS-IS like OSPF knows the concept of area's. Unlike OSPF, IS-IS operates in levels.

Level 1, considered intra area routing.
Level 2, considered inter area routing. Compareable to the OSPF area 0 backbone.

When an interface is enabled in IS-IS, without explicitly stating levels that are disabled (either per interface or globally in the protocols isis hierarchy) both L1 and L2 are enabled on the interface, as shown by the 3 under the L heading. L3 means both L1 and L2 are enabled.

root@R1# run show isis interface em0.0 
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
em0.0                 3   0x1 PE-1.02           PE-1.02                10/10

In IS-IS, an IS-IS Hello packet (IIH) is sent for every level configured, so when L3 is in play, 2 hello packets are sent. The DIS sends hello packets every 3 seconds, and non DIS-routers send hello packets every 9 seconds.

When another router with IS-IS configured on both L1 and L2 gets these IIH's, an adjacency will form on both L1 and L2.

IS-IS levels and adjacencies.

L1 and L2 enabled on both routers in the same area ID = L1 and L2 Adjacency will form
L1 enabled on both routers in the same area ID = L1 Adjacency will form
L2 enabled on both routers in the same area ID = L2 Adjacency will form
L1 and L2 enabled on both routers in different area ID's = L2 Adjacency will form, L1 adjacency will not form
L1 enabled on both routers in different area ID's = L1 Adjacency will not form
L2 enabled on both routers in different area ID's = L2 Adjaceny will form

A level can be disabled globally or on a per interface basis:

[edit]
root@PE-1# set protocols isis level 1 disable 


[edit]
root@PE-1# set protocols isis interface em0.0 level 1 disable

Routing between levels

As mentioned before, level 2 is considered to be the backbone of the IS-IS topology. But how do Level 1 only routers reach inter area destinations? With the use of the attached bit in the LSP. Once a Level 1 router gets an LSP with the attached bit set, it creates a default route towards the closest (in terms of metric) L2 router.

A level 1 area can be compared with a totally stubby area in OSPF terms.

tomtom1

Metrics, including wide metrics

When IS-IS is configured on JunOS, a single link can have a maximum metric of 63, and a path towards a prefix can have a maximum metric of 1023. To overcome this limitation, Juniper offered the option to configure wide metrics. With wide-metrics a link can have a maximum metric of 167.77215. This addition can be configured on a per-level basis with the following command:

root@R1# set protocols isis level 1 wide-metrics-only

Metrics, like OSPF are calculated on incoming LSP's. When a link metric (default 10) is changed (again on a per level basis), this metric is added to incoming LSP's on a specific interface

root@R1# set protocols isis interface em0.0 level 1 metric 100

Authentication options

Authentication in IS-IS can be configured with simple (plain-text) or MD5 authentication. This can be done per interface, per level or on per level globally.

A few example commands for per interface, per level IIH (every 3 seconds for the DIS, or 9 seconds for non-DIS routers) :

[edit]
root@R1# set protocols isis interface em0.0 level 1 hello-authentication-key 1234 


[edit]
root@R1# set protocols isis interface em0.0 level 1 hello-authentication-type md5

A few examples from per level authentication for all packets:

root@R1# set protocols isis level 2 authentication-key 1234 


root@R1# set protocols isis level 2 authentication-type md5

With the above command the IIH, the LSP, the CSNP and the PSNP are all authenticated using MD5.

snadam

Good Luck with your studies. Will be following this one for sure!

tomtom1

IS-IS route leaking

In IS-IS, the default behaviour is to leak routing information from level 1 to level 2. Via the Attached bit, the L1 router will set the default route as we've seen, but it is also possible to leak specific routes from level 2 to level 1 routers via a specific export policy in IS-IS on the L2 router.

That would look like this (policy-statement applied as IS-IS export):

root@R1# show policy-options policy-statement IS-IS-EXPORT 
from {
    protocol isis;
    level 2;
    route-filter 1.1.1.1/32 exact;
}
to level 1;
then accept;

IS-IS like OSPF as a link state protocol has export policies applied at the global level:

root@R1# show protocols isis export 
export IS-IS-EXPORT;

wizkid01

Also following this thread.

Hoping to take this exam myself in the not so distant future.

tomtom1

The last part of the IS-IS topic is the route summarization feature in IS-IS. Guess what? There is none. To apply route summarization in IS-IS, create a 'normal' aggregate route which can then be redistributed into IS-IS using the export feature.

set routing-options aggregate route 172.16.0.0/12

set policy-options policy-statement IS-IS-EXPORT term summarize from protocol aggregate
set policy-options policy-statement IS-IS-EXPORT term summarize from route-filter 172.16.0.0/12 exact
set policy-options policy-statement IS-IS-EXPORT term summarize then accept

set protocols isis export IS-IS-EXPORT

OSPF up next..

tomtom1

OSPF LSA

Ah, OSPF Link State Advertisements, contained within Link State Updates (LSU)'s, the core foundation of the OSPF Link State Database (abbreviated LSDB). These LSA with each their own flooding scope and function within the OSPF protocol describe the OSPF topology to routers in an area. One LSDB per area. Since OSPF is a link state routing protocol, the contents of the LSDB need to be identical for every router in the same area.

The well known OSPF LSA types:

Type 1 - Router LSA
The LSA type 1 has an area flooding scope and is originated by every OSPF router in the area. It describes the links that that router has with the metric attached to them.

Type 2 - Network LSA
On multi access segments (for example Ethernet) a DR / BDR election occurs. The LSA type 2 also has an area flooding scope and is originated by the DR to identify itself as the DR for a particular segment.

Type 3 - Summary LSA
The LSA type 3 is originated by an area border router (ABR) to describe inter area networks. The ABR takes the information learned via the type 1 LSA and summarizes this information in the type 3 LSA.

Type 4 - ASBR Summary
To be able to route to external networks via the LSA type 5 (external) the LSA type 4 is originated via the ABR and it describes the path to the ASBR.

Type 5 - External LSA
Information about networks that are externally injected (exported into the OSPF protocol) into the OSPF domain are propagated by the LSA type 5 which is originated by the ASBR. There are 2 types of External LSA, type 1 and type 2. Type 2 is the default and does not calculate the internal cost to the ASBR and only calculates using the seed metric.

Type 7 - NSSA LSA
Seen only in OSPF NSSA (Not So Stubby Areas), a special type of stub area where redistribution is allowed. Converted back to a LSA type 5 by the ABR with the highest router ID to allow for flooding the LSA to the backbone.

Type 10 - Opaque LSA
Used for the OSPF TED (Traffic Engineering Database), used for RSVP traffic engineering in MPLS LSP signaling.

OSPF uses the metric received in the LSA and increments the metric to an interface to come up with the total cost from that routers perspective. Every LSA has a maximum lifetime of 3600 seconds as described by the OSPF RFC. That means that once a LSA reaches this timer, it needs to be aged out and removed from the link state database. To ensure information accuracy in the OSPF LSDB, the LSA refresh timer in JunOS is set to 50 minutes. Every 50 minutes, that specific LSA is re-flooded.

The show ospf database command can be used to view LSA's currently in the database.

root@R1> show ospf database 


    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *2.2.2.2          2.2.2.2          0x8000019f  1498  0x22 0xb202  36

Here we see a router with the router ID of 2.2.2.2 originated a router LSA into area 0. If we use the extensive knob, we can look even further into this LSA.

root@R1> show ospf database extensive 


    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *2.2.2.2          2.2.2.2          0x8000019f  1723  0x22 0xb202  36
  bits 0x0, link count 1
  id 192.168.1.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 100
  Gen timer 00:21:16
  Aging timer 00:31:16
  Installed 00:28:43 ago, expires in 00:31:17, sent 1w0d 00:05:58 ago
  Last changed 6d 11:07:18 ago, Change count: 8, Ours

From this LSA, we can conclude that this router has a network attached to it, more specifically 192.168.1.0/24 which has a metric of 100 from the sending's router perspective. We'll be continuing with a review of the OSPF area types, and how that might impact area design from a scalability perspective and their impact on LSA type flooding.

tomtom1

OSPF area types and operations

OSPF provides for an excellent scaling mechanism through the use of area's. An area is basically a group of routers that share the same link state database. To go even further with this scaling, different types of areas have been defined, to allow for the blocking of specific LSA's into the area, to reduce load on the routers, who need to run the SPF algorithm against the contents of the LSDB.

The OSPF area types and the LSA types they block:

Backbone area
OSPF area 0 - The backbone of the OSPF domain. LSA type 7 is not seen here

Normal area
OSPF area - A 'normal' area, for example area 1. LSA type 7 is not seen here

Stubby area
OSPF area where LSA type 4 and 5 are blocked, and a default route can be originated in the area to reach inter area destinations.

Totally stubby area
OSPF area where LSA type 3, 4 and 5 are blocked, and a default route can be originated in the area to reach inter area destinations.

Not-so-stubby area
A special kind of OSPF area, where LSA type 4 and 5 are blocked, but in the area an ASBR is present, which can redistribute routes into the NSSA area. The LSA type 7 that the ASBR originates is converted back to an LSA type 5 to allow flooding the LSA back to the backbone area.

Totally NSSA area
An OSPF area with the same characteristics as the NSSA, but LSA type 3 is also blocked here.

When OSPF was originally implemented, there was much difference in control plane capacity between different routers. To lessen the burden on those weaker routers, area's could be implemented as part of the design, to suppress specific LSA types and rely on a default route out of the area, via the ABR.

JunOS implementation

JunOS allows for the implementation of the area types as we discussed above. Some commands to configure, and verify:

Stub area

root@R1# set protocols ospf area 1 stub

Totally stub area

root@R1# set protocols ospf area 1 stub no-summaries

Not so stubby area

root@R1# set protocols ospf area 1 nssa

Totally Not so stubby area

root@R1# set protocols ospf area 1 nssa no-summaries

Remember that OSPF area type is a flag that is carried in the OSPF hello messages, and needs to be agreed upon by neighbors. If this doesn't match, no adjacency will form.

Verification

root@R2> show ospf interface ge-1/1/8.500 extensive    
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-1/1/8.500        BDR     0.0.0.1         1.1.1.1         2.2.2.2            1
  Type: LAN, Address: 172.31.255.2, Mask: 255.255.255.252, MTU: 8978, Cost: 1
  DR addr: 172.31.255.1, BDR addr: 172.31.255.2, Priority: 128
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, [U][B]Stub[/B][/U]
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Cost: 1

root@R2> show ospf overview | find Area 
  Area: 0.0.0.1
[U][B]    Stub type: Stub[/B][/U]
    Authentication Type: None
    Area border routers: 1, AS boundary routers: 0
    Neighbors
      Up (in full state): 1
  Topology: default (ID 0)
    Prefix export count: 0
    Full SPF runs: 5
    SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
    Backup SPF: Not Needed

Lab time

Consider the following scenario. R1 has a loopback in area 0, and has an adjacency over area 1 - a totally stubby area. Since the totally stubby area blocks inter area LSA's (type 3,4,5), how can we provide reachability from R2 to the loopback of R1? By originating a default route from the ABR connected to area 0 and area 1, R1.

To configure R1 to originate a default route, configure a default metric:

[edit]
root@R1# set protocols ospf area 1 stub default-metric 10

The default-metric refers to the metric in the summary LSA advertised by R1. When R2 receives this LSA, it will add the link cost from the link over which the LSA came in to the metric and it will have the total metric from the perspective of R2.

root@R2> show route 0.0.0.0/0 exact           


inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


0.0.0.0/0          *[OSPF/10] 00:02:03, metric 11
                    > to 172.31.255.1 via ge-1/1/8.500

root@R2> show ospf database netsummary area 1 


    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary  0.0.0.0          1.1.1.1          0x80000001   165  0x20 0xed43  28

root@R2> ping 1.1.1.1 source 172.31.255.2 
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=0.840 ms

lab.png

tomtom1

OSPF Neighbor establishment
Thought it would be nice to talk a little bit about OSPF neighbor establishment too. In order for an OSPF adjacency to establish, there needs to be an agreement on different factors. These are:

OSPF area ID
Network / subnet range
Area type (stub, totally stub, etc)
Hello / dead timers
Authentication
MTU*

All this information is carried in every OSPF hello message, as one can see with a wireshark capture.The E bit - No external routing capability denotes a stub area. Do note that an adjacency can be formed between a totally stub and a stub neighbor, since the E bit is set for both the stub and the totally stub area.

Neighbor establishment proces

When both neighbors establish bidirectional communication through the use of hello packets, they start the database exchange process. In this process, a master and a slave are elected. The router with the highest RID, in the drawing above R2, is elected master and can send DBD and set sequence numbers. The slave in the exchange process is only allowed to acknowledge DBD packets by sending another DBD packet with the same sequence number, that functions as an acknowledgement.

The OSPF DB Description packet can be compared with the IS IS CSNP, it contains a list of the LSA's currently in the LSDB. When the database exchange process is complete, both routers in the LSDB have a complete overview of the LSA's. If a router concludes a specific LSA is missing, it can send a LSR (Link State Request) to request a full LSA.

Database Description & MTU

When there is an MTU mismatch between the neighbouring routers, the adjacency will form up to the Exchange / ExStart state. Especially when working with 2 vendors, one might see this, since MTU implementation is still not considered consistent.

root@R2> show ospf neighbor
    Address          Interface              State     ID               Pri  Dead
172.31.255.1     ge-1/1/8.500           ExStart   1.1.1.1          128    36

Screen Shot 2015-03-29 at 11.16.50.jpg

Screen Shot 2015-03-29 at 11.02.34.jpg

ospf-adjacency.png

tomtom1

OSPF DR / BDR operation

In order to minimize the effects of LSA flooding on multi-access segments, the concept of a DR / BDR was elected. On a segment with multiple OSPF enabled routers, every router will only achieve a full neighbor relationship with the DR and the BDR and thus are allowed to exchange LSU's. The other routers will have an adjacency in the 2way state.

root@SRX> show ospf neighbor     
Address          Interface              State     ID               Pri  Dead
192.168.1.223    ge-0/0/0.0             2Way      192.168.1.223      1    31
192.168.1.248    ge-0/0/0.0             Full      10.255.0.254     128    33
192.168.1.246    ge-0/0/0.0             Full      2.2.2.2          128    39

When a topology change in the OSPF network occurs on a DRother (router that is neither the DR, nor the BDR), this router will send a LSU to the 224.0.0.6 address (al DR routers) where the DR and the BDR will update this entry in their link state database. After updating their database, they will send a LSU to 224.0.0.5 (all OSPF routers) to inform other routers about the topology change. This also functions as an acknowledgement for the LSU sent by the router that detected the topology change in the first place.

DR election

The router with the highest priority (default 128 in JunOS) will win the DR election and act as DR for the segment, orginating a type 2 LSA to identify itself as the DR and every neighbor relationship. If there is a tie in the router priority, the OSPF router ID acts as a tiebreaker where the highest ID wins.

Rules for Router ID selection:

Can be statically set via set routing-options router-id
Lowest IP address assigned to a loopback interface
If no loopback address is present; Lowest IP address assigned to a physical interface

OSPF network types

Think about this.. What if, you have a point to point connection between 2 router, for example on your WAN interface. Wouldn't make sense to do a DR / BDR election on that segment would it? To speed up convergence on those networks, since a DR / BDR election isn't necessary you can use the p2p network type.

[edit]
root@SRX-Lab# set protocols ospf area 0 interface ge-0/0/0.0 interface-type p2p

tomtom1

OSPF and metrics

Ah, cost, the metric of an OSPF implementation that provides a number detailing the preference of a specific path to reach a given destination. Once an LSA with a given cost comes in, the cost mentioned in the LSA is then added to the cost of the link on which the LSA came in. That means cost is significant on received LSA's.

As we can see in the image above, R1 and R2 have an adjacency over area 0. R2 is advertising the 192.168.1.0/24 network in it's type 1 LSA with a metric of 100. R1 receives this route, and based on the interface it came in on (ge-0/0/0), with the associated cost (1) saves this LSA, runs the SPF algorithm and decides the shortest path to reach 192.168.1.0/24 is via R2 with a total metric (from the perspective of R1) of 101.

Reference bandwidth

OSPF by default assigns any link faster than 100 megabit the default cost of 1.

root@SRX> show ospf interface detail | match Cost    
  Type: LAN, Address: 192.168.1.253, Mask: 255.255.255.0, MTU: 8986, Cost: 1

With that default cost, OSPF cannot differentiate between gigabit (ge) and 10 gigabit (xe) interfaces which might lead to suboptimal routing. To change the default vantage point of OSPF from 100 megabit to something more 2015, like 10 gigabit, use the reference-bandwidth onder the protocols ospf hierarchy:

root@SRX# set protocols ospf reference-bandwidth 10g

After applying 10 gigabit reference bandwidth, you can immediately see that the link cost has changed:

root@SRX# run show ospf interface detail | match Cost 
  Type: LAN, Address: 192.168.1.253, Mask: 255.255.255.0, MTU: 8986, Cost: 10

Setting cost manually

Let's say you don't want a specific router to become a transit router in your network. You can raise the cost manually, so that when this router re-advertises LSA's, the cost is high enough to become a less preferred path. This can be done on a per interface basis:

[edit]
root@SRX# set protocols ospf area 0 interface ge-0/0/0 metric 200

OSPF (like IS-IS) also has the concept of an overload knob. When activating OSPF overload, it will start to advertise LSA's with a metric of 65535 to ensure no router transits via this router. Might come in handy when performing maintenance that could impact the OSPF or IS-IS topology. You can enable overload until you manually disable it again, or with a specific timer.

root@SRX-Lab# set protocols ospf overload

External OSPF metrics

Let's say you have this topology. R3 is redistributing (exporting) routes into OSPF. When redistributing into OSPF, we have 2 types of routes.

External type 1 routes, who consider the metric to reach the ASBR in the path cost (ASBR metric + external metric).
External type 2 routes, who only consider the metric for reaching the external routes

External type 2 is the default, but this can be changed in the export policy applied to OSPF.

Consider the following export policy applied to R3:

root@R3# show policy-options policy-statement OSPF-EXPORT | display set 
set policy-options policy-statement OSPF-EXPORT from route-filter 172.16.1.255/32 exact
set policy-options policy-statement OSPF-EXPORT then metric 20
set policy-options policy-statement OSPF-EXPORT then accept

When looking on R1 to see the route for 172.16.1.255/32:

root@R1> show route 172.16.1.255/32 exact 


172.16.1.255/32    *[OSPF/150] 00:01:26, [B][U]metric 20,[/U][/B] tag 0
                    > to 172.31.255.1 via ge-1/1/8.500

Looking in the OSPF LSDB, we can see that this external LSA is an LSA type 2 with a seed-metric of 20:


root@R1> show ospf database external extensive | match Type 
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
  [U][B]  Type: 2[/B][/U], Metric: 20, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

Only the metric of 20 which we applied during the export is visible in the route. Let's now change the route type from the external type 2 default to external type 1.

root@R3# set policy-options policy-statement OSPF-EXPORT then external type 1

And revisit R1 to see the updated cost:

root@R1> show route 172.16.1.255/32 exact 


172.16.1.255/32    *[OSPF/150] 00:00:41, [U][B]metric 220[/B][/U], tag 0
                    > to 172.31.255.1 via ge-1/1/8.500

root@R1> show ospf database external extensive | match Type 
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
    [U][B]Type: 1[/B][/U], Metric: 20, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

Now the OSPF metric applies to both external and internal cost.

The exception to every rule

There is however an exception to every rule. There are a few scenario's in which OSPF does not even look at metric but just follows it's own rules.

Consider a scenario like this:

Clearly (when looking at metrics) the path over R3 from the perspective of R2 is the better path to reach the loopback on R3, but this is in direct conflict with OSPF's rules.

Intra area routes to the same destination are preferred over interarea routes
External type 1 routes to the same destination are preferred over External type 2 routes

When looking at the routing table on R2 for the loopback, the route follows the above rules and goes over R1 to reach R3, even if that is considered (from a metric standpoint) a worse route.

root@R2> show route 172.16.1.255   


inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


172.16.1.255/32    *[OSPF/10] 00:00:05, metric 200
                    > to 172.31.255.1 via ge-1/1/8.500


root@R2> traceroute 172.16.1.255 
traceroute to 172.16.1.255 (172.16.1.255), 30 hops max, 40 byte packets
 1  172.31.255.1 (172.31.255.1)  0.593 ms  0.514 ms  0.602 ms
 2  172.16.1.255 (172.16.1.255)  0.684 ms  0.637 ms  0.676 ms

intra vs inter.jpg

tomtom1

OSPF route summarization and route restriction

OSPF summarization can only be done on points where topology information enters the network because all routers need to have the same LSDB in order for OSPF to function properly. With such constraints, the only places summarization can be performed is the ABR and the ASBR.

Summarization or restriction of routes is always performed in the area that contains the routes to be summarized or restricted.

In this example, R3 originates some type 1 LSA's for connected subnets on it's interface, which are:

172.16.0.0/24
172.16.1.0/24
172.16.2.0/24
172.16.3.0/24

It would seem a bit wasteful to let R2 create 4 seperate summary LSA's for every network. If we could summarize this prefix, it would make both our LSDB and routing table more concise without losing connectivity to those networks.

Configure on R2:

root@R2# set protocols ospf area 1 area-range 172.16.0.0/22

When checking the LSDB in area 0 (ouput omitted) a summary LSA for the summarized prefix can be observed:

root@R2> show ospf database area 0 
    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Summary *172.16.0.0       2.2.2.2          0x80000002    12  0x22 0xc0b8  28

The routing table on R1 also reflects this summarized route:

root@R1> show route 172.16.0.0/22 exact 

172.16.0.0/22      *[OSPF/10] 00:18:37, metric 2
                    > to 172.31.255.2 via ge-1/1/9.500

img.jpg

tomtom1

Extending area 0... OSPF virtual links

Because OSPF is more of a distance vector than link state protocol in summarizing information between area's, as a main loop prevention mechanism, everything has to cross area 0 and every area has to be directly connected to area 0. But what if the topology you're facing does not have direct connections to area 0.

In such a case, virtual links can be used. Virtual links can be used to extend area 0 over what is known as a transit area. The transit area is a normal, non stub area over which the virtual link is created. A virtual link is created under the protocols ospf area 0 virtual-link hierarchy and consists of 2 main ingredients.

Transit area: The area over which the virtual link is created
Neighbor-id: The RID of the remote router on which the other end of the virtual link terminates.

Example configuration:

root@R1# set protocols ospf area 0 virtual-link transit-area 1 neighbor-id 2.2.2.2

When the configuration on both ends is provisioned, a new OSPF point to point interface is provisioned in area 0.

root@R2> show ospf interface 
Interface           State   Area            DR ID           BDR ID          Nbrs
vl-3.3.3.3          PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            1

tomtom1

Back into this again, after doing the VCP6 beta, I plan to do the JNCIP-SP within 3 months. It's a pretty high mountain to climb from where I'm currently at, but we'll see if it can be done.

snadam

Glad to see you're back at it!

tomtom1

Did a larger lab on IS-IS, OSPF and route redistribution between the two, complimenting it with IS-IS route leaking, OSPF metric tweaking and authentication to get myself back into the game. With that being said and done, it's time to move into the BGP piece.

Border Gateway Protocol (BGP)

The JNCIP-SP and service provider networks in general rely heavily on BGP with customers, peers and transits to announce their IP space to the rest of the world. As such, BGP is an important part of daily operations. Because support for multiple address families exist, BGP can also be used as a control plane protocol for MPLS applications, also found in SP networks. BGP is the routing protocol that allows the greatest level of granular control on both inbound and outbound routing with the use of BGP attributes.

BGP is an exterior gateway protocol (EGP) that works with the concept of autonomous systems, basically routers under the same administrative domain. By establishing a statefull connection with another peer across TCP port 179, routing information can be established.

BGP route selection

To allow granular control on routing, the route selection process is a bit more complex then we're used with IGP protocols. If BGP receives the same prefix information from multiple sources, the route selection process works like this:

1) Check if the next hop of the route can be resolved.
2) Prefer the path with the highest local preference
3) Prefer the shortest AS-Path
4) Prefer the lowest origin code (I > E > ?)
5) Prefer the lowest MED (Multi Exit Descriminator)
6) Prefer eBGP routing information over iBGP
7) Prefer the lowest internal metric to the BGP next-hop

Prefer the oldest path to prevent route flapping
9) Prefer the lowest router ID
10) Prefer the route from the peer with the lowest IP address

We will dive into this later.

Next hop resolution

In order for BGP to even consider a route for forwarding traffic, the next-hop of that route needs to resolvable. Meaning, the router needs to have a route to the BGP next hop. Between eBGP neighbors, the next-hop is updated. On iBGP neighbor relations, this is not the case.

Consider the following scenario. eBGP is setup between R1 and R2, and iBGP is in place between R2 and R3.

If R1 originates a prefix, and advertises this via BGP to R2, the next-hop of that route is set to the interface IP address of the point-to-point subnet of R1 as we can see here.

tom@MX80:R2> show route 1.1.1.1/32 exact detail    


inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
        State: <FlashAll>
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 1315
                Address: 0x27d45b4
                Next-hop reference count: 2
                Source: 172.31.255.1
[B]                Next hop: 172.31.255.1 via ge-1/1/8.500, selected[/B]
                Session Id: 0x200102
                State: <Active Ext>
                Peer AS: 65535
                Age: 58 
                Validation State: unverified 
                Task: BGP_65535_64512.172.31.255.1+179
                Announcement bits (1): 3-KRT 
                AS path: 65535 I
                Accepted
                Localpref: 100
                Router ID: 1.1.1.1

The next-hop is visible here and the route is inserted into the routing and the forwarding table. However, the route is not visible on R3:

tom@MX80:R3> show route 1.1.1.1/32 exact detail    



inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1 hidden)

But wait, what is that hidden route there?

tom@MX80:R3> show route 1.1.1.1/32 exact detail    



inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1 hidden)
1.1.1.1/32 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Next hop type: Unusable
                Address: 0x24e9bf4
                Next-hop reference count: 1
                State: <Hidden Int Ext>
                Peer AS: 64512
                Age: 1:59 
                Validation State: unverified 
                Task: BGP_64512_64512.172.31.255.5+179
                AS path: 65535 I
                Accepted
                Localpref: 100
                Router ID: 2.2.2.2
                Indirect next hops: 1
                        Protocol next hop: 172.31.255.1
                        Indirect next hop: 0 - INH Session ID: 0x0

It's our route.. but why is it hidden? Check the next-hop type, it's unuseable because the protocol next-hop is not updated on iBGP sessions. We can solve this by adding either a route to the 172.31.255.0/30 network, or placing what is known as a next-hop-self policy on R2, in which it updates the next-hop to itself before advertising the route towards R3.

This is done by applying a BGP export policy on R2

tom@MX80:R2# set policy-options policy-statement BGP-NEXT-HOP-SELF then next-hop self                   


[edit]
tom@MX80:R2# set protocols bgp group iBGP export BGP-NEXT-HOP-SELF

Validate with:

tom@MX80:R2> show route advertising-protocol bgp 172.31.255.6 


inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.1.1.1/32              Self                         100        65535 I



tom@MX80:R3> show route 1.1.1.1/32 detail                        


inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x27946e4
                Next-hop reference count: 3
                Source: 172.31.255.5
                Next hop type: Router, Next hop index: 1310
                Next hop: 172.31.255.5 via ge-1/1/9.501, selected
                Session Id: 0x300101
                Protocol next hop: 172.31.255.5
                Indirect next hop: 2918000 1048574 INH Session ID: 0x300103
                State: <Active Int Ext>
                Peer AS: 64512
                Age: 1:38       Metric2: 0 
                Validation State: unverified 
                Task: BGP_64512_64512.172.31.255.5+179
                Announcement bits (2): 2-KRT 6-Resolve tree 4 
                AS path: 65535 I
                Accepted
                Localpref: 100
                Router ID: 2.2.2.2

iBGP.png

tomtom1

BGP Communities

One of the elements that make BGP as flexible as it is, is the use of communities. Compare communities with tags, that can be used between BGP speakers to mark certain prefixes with either a custom or a well known community.

The well known communities are:

no-export
Routes marked with this community value must not be exported to other AS'es.

no-advertise
Routes marked with this community value must not be advertised.

no-export-subconfed
Routes marked with this community value must not be exported to other AS'es, even other AS'es in the same subconfederation.

Keep in mind that communities do not have an effect on the local router. So, if you export a route into BGP with a specific community set (no-advertise for example), the route will be advertised to that routers neighbors, but will not be advertised from that point on.

Example of marking the route 1.1.1.1/32 with the no-advertise community:

root@R1# set policy-options community no-advertise members no-advertise 
root@R1# set policy-options policy-statement EXPORT-LOOPBACK from route-filter 1.1.1.1/32 exact 
root@R1# set policy-options policy-statement EXPORT-LOOPBACK then community add no-advertise       
root@R1# set policy-options policy-statement EXPORT-LOOPBACK then accept                        
root@R1# set protocols bgp export EXPORT-LOOPBACK

Note that even though no-advertise is a well known community, in JunOS we first need to define the community with the member no-advertise.

Verification on R1:

tom@R1> show route advertising-protocol bgp 172.31.255.2 extensive 


inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
* 1.1.1.1/32 (1 entry, 1 announced)
 BGP group eBGP type External
     Nexthop: Self
     AS path: [65535] I
     Communities: no-advertise

Verification on R2:

tom@R2> show route 1.1.1.1/32 exact detail | match Communities 
                Communities: no-advertise

So, as I said before, communities have no effect on local routers, that is why R2 still receives this route. However, if we check what R2 is advertising in it's session with R3, the loopback of R1 is not advertised due to the BGP community no-advertise.


tom@R2> show route advertising-protocol bgp 172.31.255.6 


tom@R2>

Besides the well known communities, one could also chose to implement own communties to implement, for example, selective blackholing. That would mean your customer exports a route with a predefined community to you as a service provider, and you place an import policy matching such routes.

A piece of the configuration, R1 is presumed to be the CE, R2 the PE:

tom@R1# set policy-options community BLACKHOLE members 65535:10                                    
tom@R1# set policy-options policy-statement BLACKHOLE-ROUTES from route-filter 1.1.1.1/32 exact    
tom@R1# set policy-options policy-statement BLACKHOLE-ROUTES then community BLACKHOLE add          
tom@R1# set policy-options policy-statement BLACKHOLE-ROUTES then accept

tom@R1> show route advertising-protocol bgp 172.31.255.2 extensive    


inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
* 1.1.1.1/32 (1 entry, 1 announced)
 BGP group eBGP type External
     Nexthop: Self
     AS path: [65535] I
[B]     Communities: 65535:10[/B]

On R2, the PE, a BGP import policy is created setting the next-hop of a blackhole route to discard. That way, the destination can be filtered upstream (from the customer perspective) on the provider routers and not on the customer end.

tom@R2# set policy-options community BLACKHOLE members 65535:10                   
tom@R2# set policy-options policy-statement BLACKHOLE from community BLACKHOLE    
tom@R2# set policy-options policy-statement BLACKHOLE then accept                 
tom@R2# set policy-options policy-statement BLACKHOLE then next-hop discard

tom@R2> show route 1.1.1.1/32 


inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both


1.1.1.1/32         *[BGP/170] 00:03:41, localpref 100, from 172.31.255.1
                      AS path: 65535 I, validation-state: unverified
                      Discard

tomtom1

BGP Multipath

Consider the scenario above. Both customer routers R2 and R3 are advertising the same prefix (172.16.0.0/24) towards the PE R1. If we take a look at the routing table on R1, we see it is receiving both the routes, but only one route is selected as active:

tom@R1> show route 172.16.0.0/24 extensive 
inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
172.16.0.0/24 (2 entries, 1 announced)
TSI:KRT in-kernel 172.16.0.0/24 -> {172.31.255.2}        
*BGP    
Preference: 170/-101                
Next hop type: Router, Next hop index: 1320                
Address: 0x26fc4d0                
Next-hop reference count: 2                
Source: 172.31.255.2                
Next hop: 172.31.255.2 via ge-1/1/9.500, selected                
Session Id: 0x280001                
State:                 
Peer AS: 65535                
Age: 2:04                 
Validation State: unverified                 
Task: BGP_65535_9150.172.31.255.2+59365                
Announcement bits (1): 1-KRT                 
AS path: 65535 I                Accepted                
Localpref: 100                
Router ID: 2.2.2.2         
BGP    Preference: 170/-101                
Next hop type: Router                
Address: 0x26fc6e4                
Next-hop reference count: 1                
Source: 172.31.255.18                
Next hop: 172.31.255.18 via ge-1/1/9.600, selected                
Session Id: 0x0                
State:                 
Inactive reason: Not Best in its group - Active preferred                
Peer AS: 65535                
Age: 12                 
Validation State: unverified                 
Task: BGP_65535_9150.172.31.255.18+59418                
AS path: 65535 I                Accepted                
Localpref: 100                
Router ID: 3.3.3.3

What if we wanted to use both paths toward the 172.16.0.0/24 prefix and load share our traffic between them. Luckily, BGP has a feature called multipath. When multipath is activated, if both paths have the same IGP cost to the next-hop (step 7), multipathing is enabled, effectively allowing BGP to load share between these prefixes.

tom@R1# set protocols bgp group multipath multipath

If we've configured it like stated above, we also need to edit the forwarding table to allow per-packet (actually per-flow) loadbalancing. This is done by adding an export policy under the routing-options forwarding-table stanza.

tom@R1# set policy-options policy-statement PPLB from route-filter 172.16.0.0/24 exact
tom@R1# set policy-options policy-statement PPLB then load-balance per-packet             
tom@R1# set routing-options forwarding-table export PPLB

After we've configured this, both routes are placed in the forwarding table:

172.16.0.0/24      user     0                    ulst 1048574     
172.31.255.2       ucst  1320      3 ge-1/1/9.500   
172.31.255.18      ucst  1349     4 ge-1/1/9.600

bgp-multipath.jpg

tomtom1

Multihop BGP

By default, the TTL of an iBGP packet is 64, and the TTL of an eBGP packet is 1. When using iBGP it is pretty common to peer using loopback IP addresses to ensure a single link failure in the internal network cannot disturb the BGP session. This is done by configuring the local-address under the [protocols bgp] stanza.

If you need to peer with (for example) an IP transit provider but their BGP router is not at the edge of the network, it can be necessary to configure eBGP multihop. The configuration itself is rather simple and can be configured under:

[protocols bgp]
[protocols bgp group xxx]
[protocols bgp group xxx neighbor y.y.y.y]

tom@R2# set protocols bgp group test multihop

An optional argument to the multihop command is ttl, in which you can manually specify the TTL for the eBGP packets ranging from 1 to 255. If you do not specify the ttl option, the default TTL of 64 is chosen.

You can verify this by checking the show bgp neighbor command:

tom@R2> show bgp neighbor 172.31.255.1 | match Options 
  Options: <Multihop Preference PeerAS LocalAS Refresh>

tomtom1

Started a lab on CoS today from the basics, have got 0 experience with that so I'm taking my time there. Did some practice things yesterday and ran into IS-IS hello padding (full MTU link packets before the adjacency goes up to ensure no errors during synchronization) and some RR / Confederations.. Will summarize later.

tomtom1

CUSTOMJunOS CoS implementation

CoS is the process or prioritising packets over each other. Looking at this from a high level perspective, JunOS does this in the following manner:

1) Classification refers to the recognition of certain traffic types / streams, either on a BA (i.e. DSCP, EXP bits) or MF (source / destination IP address, protocol, port numbers).

2) Policing refers to the hard rate limiting of traffic types

3) Queuing is the process of buffering packets when a shaper reaches a maximum transmit rate

4) Scheduling means mapping packet to egress queues

5) Rewriting means taking CoS information from either a BA or MF classifier and taking that information and changing the CoS bits (DSCP, MPLS exp) in the protocol header.

Traffic classification
A firewall filter in JunOS can be used to recognize certain traffic based on header information and then assigning that traffic to a specific forwarding class and / or assigning a loss priority. This is considered a multi-field classifier, and is configured like this:

tom@PE-2# show firewall family inet filter multified-classifier 
term icmp-nc {
    from {
        protocol icmp;
    }
    then {
        loss-priority low;
        forwarding-class nc;
    }
}
term accept-rest {
    then accept;
}

That filter is then applied to an interface:

tom@PE-2# show interfaces ge-1/1/8.502 
vlan-id 502;
family inet {
    filter {
        input multified-classifier;
    }
    address 172.31.255.10/30;
}
family iso;
family mpls;

Forwarding classes

In JunOS a forwarding class is related to a traffic queue. There can be a one to one relation between a queue and a forwarding class, but there can also be a one to many relation between a forwarding class and a queue.

There are 4 default forwarding classes which you can use, but you can also create custom forwarding classes:


tom@MX80> show class-of-service forwarding-class 
Forwarding class                       ID      Queue  Restricted queue  Fabric priority  Policing priority   SPU priority
  best-effort                           0       0          0             low                normal            low    
  expedited-forwarding                  1       1          1             low                normal            low    
  assured-forwarding                    2       2          2             low                normal            low    
  network-control                       3       3          3             low                normal            low

To create a custom forwarding class:

tom@MX80# set class-of-service forwarding-classes queue 1 CUSTOM-QUEUE-1

In this example, we map the forwarding class CUSTOM-QUEUE-1 to the system queue 1.