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.
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.
Comments
-
tomtom1
Member Posts: 375
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
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
Member Posts: 375
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.
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
[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
Member Posts: 375
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 interfaceroot@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
Member Posts: 2,234 ■■■■□□□□□□
Good Luck with your studies. Will be following this one for sure!**** ARE FOR CHUMPS! Don't be a chump! Validate your material with certguard.com search engine
:study: Current 2015 Goals: JNCIP-SEC JNCIS-ENT CCNA-Security -
tomtom1
Member Posts: 375
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
Member Posts: 22 ■□□□□□□□□□
Also following this thread.
Hoping to take this exam myself in the not so distant future. -
tomtom1
Member Posts: 375
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
Member Posts: 375
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
Member Posts: 375
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 arearoot@R1# set protocols ospf area 1 stub
Totally stub arearoot@R1# set protocols ospf area 1 stub no-summaries
Not so stubby arearoot@R1# set protocols ospf area 1 nssa
Totally Not so stubby arearoot@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 -
tomtom1
Member Posts: 375
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 -
tomtom1
Member Posts: 375
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
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
Member Posts: 375
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
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
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 -
tomtom1
Member Posts: 375
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
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 -
tomtom1
Member Posts: 375
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.
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
Member Posts: 375
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
Member Posts: 2,234 ■■■■□□□□□□
Glad to see you're back at it!**** ARE FOR CHUMPS! Don't be a chump! Validate your material with certguard.com search engine
:study: Current 2015 Goals: JNCIP-SEC JNCIS-ENT CCNA-Security -
tomtom1
Member Posts: 375
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 R2tom@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 -
tomtom1
Member Posts: 375
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
Member Posts: 375
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.3What 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
-
tomtom1
Member Posts: 375
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
Member Posts: 375
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
Member Posts: 375
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.
