Category Archives: CCNP

Segment Routed L2VPN TE – Cisco IOS-XR

27 Jun 2018CCIE, CCNP, Cisco, IOS-XR, MPLS, Networking, RSVP, SDNAutomation, Cisco, Controller, evpn, L2VPN, MPLS, Networking, OSPF, RSVP, SDN, segment routing, SPRING, TCP/IP, Traffic-EngineeringMohit

Hi All

Let’s see Segment routing in action in this blog particularly on IOS-XR. Segment routing is quite new concept which is picking pace these days. In my earlier blog I listed the differences between Segment routing and RSVP-TE and SR can replace it and there are certain areas where it may not be able to help however L3VPN and L2VPN Traffic Engineering is surely one area where it can be used and in this blog we will use SR as TE while configuring the L2VPN.

For this we will take NCS5508 as our router platform in below topology where we will configure the L2VPN SR-TE between NCS5508-1 to NCS5508-3 via NCS5508-8.

Let’s see the SR config first.

SR beauty is that there is no special protocol needed to run it. SR Labels will be advertised in OSPF/ISIS and these protocols have been uplifted to carry them. SR Labels are carried in Type 10 Opaque area LSA as TLV.

If you are familiar with OSPF config in IOS-XR, most of the config below looks similar to you as we have just enabled OSPF under area0 and added interfaces under it.

However there are 3 configs highlighted in RED which we have enabled for Segment routing.

RP/0/RP0/CPU0:ncs5508-1#show running-config router ospf
router ospf 1
 nsr
 distribute link-state
 segment-routing mpls
 nsf ietf
 segment-routing sr-prefer
 area 0
 mpls traffic-eng
 interface Loopback0
 passive enable
 prefix-sid index 1 explicit-null
 !
 interface HundredGigE0/1/0/0
 cost 1
 network point-to-point
 !
 interface FortyGigE0/2/0/8
 cost 4
 network point-to-point
 !
 interface FortyGigE0/2/0/10
 cost 4
 network point-to-point
 !
 interface FortyGigE0/2/0/18
 cost 4
 network point-to-point
 !
 !
 mpls traffic-eng router-id Loopback0
!

segment-routing mpls , this command causes OSPF to originate RI LSA, Extended Prefix and Extended Link LSAs. It enables MPLS on all interfaces in area(s) enabled for SR and programs SR MPLS labels for forwarding.

segment-routing sr-prefer is used to set the preference of segment routing (SR) labels over label distribution protocol (LDP) labels in case both are available towards destination in your network.

prefix-sid index 1 explicit-null — A prefix SID is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels. The prefix segment steers the traffic along the shortest path to its destination. A node SID is a special type of prefix SID that identifies a specific node. It is configured under the loopback interface with the loopback address of the node as the prefix. The prefix SID is globally unique within the segment routing domain.

Let’s verify it

RP/0/RP0/CPU0:ncs5508-1#show ospf sid-database
SID Database for ospf 1 with ID 192.168.0.1

SID Prefix/Mask
-------- ------------------
1 192.168.0.1/32 (L)
2 192.168.0.2/32
3 192.168.0.3/32
4 192.168.0.4/32
5 192.168.0.5/32
6 192.168.0.6/32
7 192.168.0.7/32
8 192.168.0.8/32

In the same way we have configured the Node-SID as same index as last octet on lo0 interface.

RP/0/RP0/CPU0:ncs5508-1#show ospf database opaque-area 192.168.0.1/32
 OSPF Router with ID (192.168.0.1) (Process ID 1)
Type-10 Opaque Link Area Link States (Area 0)

LS age: 782
 Options: (No TOS-capability, DC)
 LS Type: Opaque Area Link
 Link State ID: 7.0.0.1
 Opaque Type: 7
 Opaque ID: 1
 Advertising Router: 192.168.0.1
 LS Seq Number: 800006fa
 Checksum: 0xed8b
 Length: 44
Extended Prefix TLV: Length: 20
 Route-type: 1
 AF : 0
 Flags : 0x40
 Prefix : 192.168.0.1/32
SID sub-TLV: Length: 8
 Flags : 0x50
 MTID : 0
 Algo : 0
 SID Index : 1

RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

—— ———– —————— ———— ————— ————

16002  Exp-Null-v4 SR Pfx (idx 2)     Hu0/1/0/0    50.50.50.30     0
16003  16003       SR Pfx (idx 3)     Hu0/1/0/0    50.50.50.30     0
16004  Exp-Null-v4 SR Pfx (idx 4)     Fo0/2/0/8    50.50.50.25     0
16005  16005       SR Pfx (idx 5)     Fo0/2/0/8    50.50.50.25     6421133
16006  16006       SR Pfx (idx 6)     Hu0/1/0/0    50.50.50.30     0
       16006       SR Pfx (idx 6)     Fo0/2/0/8    50.50.50.25     0
16007  16007       SR Pfx (idx 7)     Hu0/1/0/0    50.50.50.30     0
16008  Exp-Null-v4 SR Pfx (idx 8)     Fo0/2/0/18   50.50.50.38     0

Now let’s create a Segment routed TE EVPN based P2P L2 Circuit. 🙂

Ideally we know that Controller is needed to play with Segment routed labels and Controller can insert the appropriate labels required for TE however if you don’t have Controller, you can configure the path by explicitly giving the path through which traffic will be going.

So we will start with l2vpn xconnect taking edge interface on NCS5508-1 and assigning a EVPN EVI 1100 with source and target ac-id (attachment circuit id) and associate it with pw-class which we will define in next step.

RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn xconnect group evpn-vpws p2p vpws1
l2vpn
 xconnect group evpn-vpws
 p2p vpws1
 interface HundredGigE0/2/0/2.1100
 neighbor evpn evi 1100 target 11003 source 11001
 pw-class vpws1-class
 !
 !
 !
!

Pw-class is associated with sr-te policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of the shortest path calculated by the IGP

RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn pw-class vpws1-class
l2vpn
 pw-class vpws1-class
 encapsulation mpls
 preferred-path sr-te policy vpws1-policy
 !
 !
!

RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng policy vpws1-policy
segment-routing
 traffic-eng
 policy vpws1-policy
 color 10 end-point ipv4 192.168.0.3
 candidate-paths
 preference 200
 dynamic
 metric
 type te
 !
 !
 !
 preference 300
 explicit segment-list vpws1-path
 !
 !
 !
 !
 !
!

So in our policy, we have defined one preferred path which is dynamic and if that fails it should failover to explicitly configured segment list defined via path vpws1-path.

RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng segment-list vpws1-path
segment-routing
 traffic-eng
 segment-list vpws1-path
 index 10 address ipv4 50.50.50.38
 index 20 address ipv4 50.50.50.21
 !
 !
!

So if we see currently the route towards NCS5508-3, it’s going via IGP Route and not taking our defined list which is expected.

RP/0/RP0/CPU0:ncs5508-1#show route 192.168.0.3
Wed Jun 27 14:49:59.487 UTC

Routing entry for 192.168.0.3/32
 Known via "ospf 1", distance 110, metric 3, labeled SR, type intra area
 Installed Jun 27 14:47:18.930 for 00:02:40
 Routing Descriptor Blocks
 50.50.50.30, from 192.168.0.3, via HundredGigE0/1/0/0
 Route metric is 3
 No advertising protos.

So let’s see our L2VPN status.

RP/0/RP0/CPU0:ncs5508-1#show l2vpn xconnect group evpn-vpws detail

Group evpn-vpws, XC vpws1, state is up; Interworking none
 AC: HundredGigE0/2/0/2.1100, state is up
 Type VLAN; Num Ranges: 1
 Rewrite Tags: []
 VLAN ranges: [1100, 1100]
 MTU 9016; XC ID 0x1000001; interworking none
 Statistics:
 packets: received 157064234, sent 157063216
 bytes: received 234968088320, sent 234966565392
 drops: illegal VLAN 0, illegal length 0
 EVPN: neighbor 192.168.0.3, PW ID: evi 1100, ac-id 11003, state is up ( established )
 XC ID 0xc0000001
 Encapsulation MPLS
 Source address 192.168.0.1
 Encap type Ethernet, control word disabled
 Sequencing not set
 Preferred path Active : SR TE vpws1-policy, Statically configured, fallback enabled
 Tunnel : Up

 EVPN  Local Remote
 ------------ ------------------------------ -----------------------------
 Label 64007 64006
 MTU   9016  9016
 Control word disabled disabled
 AC ID 11001 11003
 EVPN type Ethernet Ethernet

So if we go n shut the primary dynamic path we can see the forwarding table moves over to our segment-list defined for label 16003 which is for NCS5508-3.

RP/0/RP0/CPU0:ncs5508-1#config t
Wed Jun 27 14:58:04.096 UTC
RP/0/RP0/CPU0:ncs5508-1(config)#int HundredGigE0/1/0/0
RP/0/RP0/CPU0:ncs5508-1(config-if)#shutdown
RP/0/RP0/CPU0:ncs5508-1(config-if)#commit

RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16002 16002 SR Pfx (idx 2) Fo0/2/0/18 50.50.50.38 0
16003 16003 SR Pfx (idx 3) Fo0/2/0/18 50.50.50.38 0

So thats all, i hope you like the blog and let me know your feedback.

Regards

Mohit

4 Byte AS Number

5 Mar 2017CCIE, CCNP, Cisco, JNCIP, JNCIS, Juniper, NetworkingAutonomous Numbers, Autonomous Systems, Cisco, Juniper, NetworkingMohit

You already know how IPv4 addresses are being depleted and how all Telecom Providers are looking at next Generation IP addressing scheme i.e. IPv6 for rescue. However there is one more resource which is depleting rapidly and that is AS Number (Autonomous System Number) or specifically 2 Byte AS Numbers.

As per official statement “An Autonomous System (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet.” i.e. each Service provider or Enterprise network will have its own AS number where it can apply its own routing-policies and connect to other AS number using BGP (eBGP).

A 16-bit number (i.e. 2 Bytes) will give 65,536 possible numbers (2^16) (AS numbers 0 – 65535). Out of these, the IANA reserves 1,026 of them: 64512 – 65534 for private, reusable ASNs (similar to private RFC1918 IPv4 addresses) and a few others such as 0, 65535 and 23456. I will come back to 23456 AS number after short while. From total of 65536 ASs, around 63000 have already been allocated, 1026 are for private use and around 1500 are remaining for Public allocation. So you can estimate yourself, how much important is this resource and something needs to be done very quickly.

Fortunately, we have new 4 Byte AS number to rescue and this is the topic of my blog.

4-byte (32bit) AS Number provides 2^32 or 4,294,967,296 autonomous system numbers ranging from 0 to 4294967295. The first thing to notice about these numbers is that they include all of the older 2-byte ASNs, 0 through 65535. That greatly helps with interoperability between autonomous systems using 2-byte ASNs and those using 4-byte ASNs.

Now main thing about 4 Byte AS number is representation. How you will represent these lengthy AS Number in meaningful way (same like for IPv6 address we have some tricks). However unlike IPv6, AS number representation is not so much complex and easy to understand.

asplain –> asplain is a simple decimal representation of the ASN, from 0 to 4294967295.
asdot –> in asdot, any ASN in the 2-byte range i.e. between 0 – 65535 is written in asplain (so 65535 is written as “65535”) however any ASN above that range is written in different format. Suppose 65536 is ASN which you know is outside the range (0 – 65535) and it will be represented as 1.0. 65537 would be 1.1, 65680 is 1.144, and so on. So if you guessed it, basically what we are doing is subtracting multiples of 65,536 from the asplain representation of the ASN, with the high-order value representing the multiples of 65536.
So 134576 can be represented as 2.3504 because 134576 = 2*65536 + 3504

HDFC Bank in India has one 4 Byte AS number allocated to it and it is:

AS131283 –> HDFC Bank

I hope you know that in BGP, AS number is used to determine the shortest path to the destination and also as a loop avoidance mechanism. So how these new AS Number notation works in environment where both types of AS number exists i.e. 2 byte and 4 byte

Ok, so let’s define the BGP implementations supporting 4-byte ASNs as BGP-New, and legacy BGP implementations that only support 2-byte ASNs as BGP-Old.

The first requirement for a BGP-New implementation is to discover whether a neighbor is BGP-New or BGP-Old. It does this by using the BGP Capability Advertisement when starting a BGP session. In addition to advertising itself as BGP-New, it includes its 4-byte ASN in the Capability advertisement.

If a neighbor responds that it also is a BGP-NEW speaker, the neighbor includes its 4-byte ASN in its own Capability advertisement. Thus two BGP-New neighbors can inform each other of their 4-byte ASNs without using the 2-byte Autonomous System field in the Open message.

If a neighbor is BGP-Old, it either responds that it does not support the 4-byte ASN capability or does not respond to the Capability advertisement at all. In this case, the BGP-New neighbor can still bring up a session with the BGP-Old neighbor, but cannot advertise its 4-byte ASN. The neighbor wouldn’t understand it. Instead, BGP-New uses a reserved 2-byte ASN which I defined earlier i.e. 23456, called AS_TRANS. Router which is configured for 4 byte number will send the BGP Open message with 23456 AS Number so that neighbor Router can understand it. Because AS_TRANS is reserved, no BGP-Old speaker can use it as its own ASN; only BGP-New speakers can use it.

Interoperable peering, then, is achieved because the BGP-New speaker “knows” its neighbor is a BGP-Old speaker and adapts to it; the BGP-Old speaker simply continues using legacy BGP rules.

Cisco has started to include this functionality from IOS-XR 3.4 and Juniper Network has included this from Junos 9.1.

There is much more to 4 byte AS but I hope you will get some idea from this blog 🙂

Regards

Mohit Mittal

NSF, GR or NSR??

3 Mar 2017CCIE, CCNP, Cisco, JNCIP, JNCIS, Juniper, NetworkingCisco, GR, GRES, Juniper, Networking, NSRMohit

There are number of terms we use in today’s High Availability Network like NSF (Non-Stop Forwarding), GR (Graceful Restart) and NSR (Non-Stop Routing). Companies these days want 99.5% availability of their networks and these High Availability features play a vital role in that. However have you ever wondered what’s the difference between all these terms??. Add to our confusion is different vendors and their usage of terms.

Let’s try to understand what’s basically these terms are and whether there is any commonality between terms used by different vendors!!!! We will compare Cisco and Juniper over here.

Modern high-performance routers physically separate the forwarding plane and the control plane and both have their own memory and processors. The control plane runs the routing protocols, and derives a forwarding table (FIB). The FIB is given to the forwarding plane, which is then responsible for actual packet forwarding through the router. The advantage of physically separating the forwarding and control planes is that in case of congestion i.e. huge traffic is flowing through the routers; forwarding plane becomes very busy however in that case it doesn’t impact the control plane’s ability to process new routing information. Similarly in case router’s routing plane/control plane becomes clogged due to route flapping or any other issues, it doesn’t impact the forwarding plane to continue forwarding packets as forwarding plane has a copy of the FIB which it previously got from Control plane. This is called Non-Stop Forwarding (NSF).

Now you must be thinking that this is not a good architecture as Router is forwarding on the path which is corrupt or not optimum at this moment or you can say that there might be good path somewhere which is not being used by Router. So why do I need NSF?

Well, you need NSF so that routers can use redundant control planes. Cisco calls their control planes as Route Processors and Juniper calls them Routing Engines. With 2 processors or routing engines, NSF switches from a primary to a backup control plane without disrupting forwarding. The FIB could still become invalid during the period between when the primary control plane goes down and the backup control plane takes over, but this is acceptable for time being 😉

So problem now is how you can make this switchover from primary to backup control plane shorter so that FIB is less prone to invalid information. Routers do this by maintaining the copy of the active configuration on backup processor/routing-engine as well. Now Cisco calls this process as Stateful Switchover (SSO) and Juniper calls it as Graceful Routing Engine Switchover (GRES). J

So what is Non-Stop Routing (NSR) then?

Ok as I stated above that Control plane has Stateful Switchover at its disposal to decrease the switchover time however problem is that once router do the switchover all the routing protocol adjacencies like OSPF, LDP, IS-IS etc. goes down. So when routing protocol goes down, neighboring routers by principle update their neighboring routers of this mis-happening and those routers will in-turn update other neighboring routers in chain. This all process will un-stabilize the network and CPU processing on all routers will increase. Same will happen at the time when back up control plane comes up. So you guessed it right, the use of NSR in that case is to minimize this un-stability.

Initially, to control this un-stability, GR (Graceful Restart) principle was proposed, where on router’s control plane switchover, router doesn’t report the switchover information immediately to its own neighbor rather it wait for certain period of time (which is called grace interval) and this saves the network from impact. However to have this GR capability all the neighbors should support GR which may not be the case everywhere like on small routers in Enterprise Networks..So they proposed NSR..

In NSR, router’s backup routing-engine/processor keeps the information of routing-protocol i.e. OSPF, LDP, IS-IS state as well and as this information is already with backup processors, switchover is transparent to neighbors. So why this doesn’t impact small routers? Because NSR is vendor specific and neighboring router doesn’t have to support it unlike GR.

Different vendors use all these terms differently. Juniper, for example, calls its graceful restart implementation as Graceful Restart, whereas Cisco calls it’s as Non-Stop Forwarding Awareness Also people consider Juniper’s GRES and GR as same however if you read above they both are two different things.

So, that’s all for NSF, GR and NSR. I hope you find this information useful and I am able to lessen your confusion. If you still have any questions, please let me know. 🙂

Thanks

Regards

Mohit Mittal