Category Archives: JNCIP

Juniper JunOS Command Series – 1

Hi All, from this series we will look at some useful JunOS commands and concepts where Juniper give us flexibility over other vendors and I hope this will help you in case you are switching from other vendor products to JunOS.

We will look at example from interface configuration however same can be applied to any stanza or part of configuration in Junos.

Lets start with configuration of interface ge-0/0/7 where 3 logical units have been defined and this link is made to participate in 3 vlans correspondingly.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

However later some requirement change and because of it you need to change the ip addressing on one of the unit from 10.10.10.5 to say 20.20.20.5.

Now one way of doing this in Junos is to configure the new address in below fashion!!

MX104>edit
Entering configuration mode

[edit]
MX104# edit interfaces ge-0/0/7

[edit interfaces ge-0/0/7]
MX104# set unit 100 family inet address 20.20.20.5/30

But this has created an additional row under the interface stanza for which we have to write one delete statement to delete previous 10.10.10.5 address.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}
 
[edit interfaces ge-0/0/7]
MX104#delete unit 100 family inet address 10.10.10.5/30

Final config is:

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

This method is fine for one change however not a very quick method. Junos gives us ability to change this value in very quick way by using “rename” command.

(NOTE: I did rollback the changes made above before proceeding further in order for interface configuration to be at same stage from where I started my blog)

Rename command renames the value of particular variable to new value and you need to mention the whole command hierarchy or go to level where you want the change to be applied. This is easy method to achieve same thing in less number of changes.

[edit interfaces ge-0/0/7]
MX104# rename unit 100 family inet address 10.10.10.5/30 to address 20.20.20.5/30

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

Now, what if you want to change all IP Addresses under interface ge-0/0/7 stanza to use 20.20.20.x address rather than 10.10.10.x.. 2 methods can be set/delete and rename as we saw above however we have to define 2 rename statements in our case to change the ip addresses on remaining unit 200 and unit 300.

Again Junos is to the rescue and this time we will use another command “replace”. Replace command replaces the pattern you want to be replaced with new pattern.

Let’s see it in action.

Below is our configuration after we changed unit 100 with new ip address using rename command.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
} 

Now we have to change the ip addresses on unit 200 and unit 300 and in that case we can achieve this by using below command:

[edit interfaces ge-0/0/7]
MX104# replace pattern 10.10.10 with 20.20.20

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}

Pretty exciting and fast !!! 🙂

One thing to remember is that you have to be in exact hierarchy where you want this pattern to be replaced. If you are at the Top level i.e under edit hierarchy only, then this will replace all instances of 10.10.10 with 20.20.20 whereever it is in whole config and not just ge-0/0/7.

Let’s see this in action one more time.

below is our configuration resulting from replace method. Now lets assume that we have to change all units and accordingly vlan’s last 2 digits from 00 to 10.. so unit and vlan id needs to be changed from 100, 200 and 300 to 110, 210, and 310 respectively.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}


[edit interfaces ge-0/0/7]
MX104# replace pattern 00 with 10

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 110 {
    vlan-id 110;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 210 {
    vlan-id 210;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 310 {
    vlan-id 310;
    family inet {
        address 20.20.20.13/30;
    }
}

So that’s all, I hope you liked this article and will make use of these commands in your day to day operational work or troubleshooting. In future blogs we will see more useful commands and till then, have a nice day..

 

Regards

Mohit Mittal

 

 


		
Advertisements

Route-Reflection in JunOS

Let’s talk about one important concept in Route-reflection configuration in Junos.

To start with, there are 2 main IPv4 routing-tables in Junos which are inet.0 and inet3.0. inet.0 is main global routing table and inet3.0 is used in MPLS Layer 3 VPN and this table stores the egress address of an MPLS label-switched path (LSP), the LSP name, and the outgoing interface name. Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses.

Now let’s configure the Route-reflection in Network. We will using 2 PEs and 1 RR

MPLS Network_1

Config on PE1:

PE1-re0> show configuration protocols bgp
local-address 10.198.123.204;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;   <<<<<<<<<<<<<<———- Router ID of RR
}

Config on PE2:

PE-2-re0> show configuration protocols bgp
local-address 10.198.123.205;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;
}

Config on RR (relevant configs only):

RR.re0> show configuration logical-systems l3vpn-RR
interfaces {
lo0 {
unit 3 {
family inet {
filter {
input Protect-RE;
}
address 10.198.123.235/32;
}
}
}
}
protocols {
bgp {
local-address 10.198.123.235;
mtu-discovery;
log-updown;
family inet-vpn {
unicast;
}
group l3vpn-client-group {
type internal;
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
cluster 10.198.123.235;
neighbor 10.198.123.204;
neighbor 10.198.123.205;
}
.
.
.
.
routing-options {
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
}

BGP is established between PEs and RR

PE-2-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004      19154     12204       0       5 3d 23:20:04 Establ

PE-1-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004     19154     12326       0       1 3d 23:20:38 Establ

RR-re0> show bgp summary logical-system l3vpn-RR | match 10.198.123.204
10.198.123.204       65004     12336     19179       0     34 3d 23:25:10 Establ

RR-re0show bgp summary logical-system l3vpn-RR | match 10.198.123.205
10.198.123.205       65004     12212     19179       0     10 3d 23:24:31 Establ

PE-1 is advertising routes towards RR with next-hop address as its own loopback. All well n good.

PE-1-re0> show route advertising-protocol bgp 10.198.123.235
Data-VPN.inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                          Nexthop             MED     Lclpref   AS path
* 10.12.204.128/32     Self                       100       I
* 10.12.240.0/30         Self                         100       65012 I
* 10.12.240.128/32     Self                        100       65012 I
* 10.204.12.0/30         Self                         100       I

M10i-L3VPN.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                         Nexthop            MED     Lclpref   AS path
* 10.0.0.240/30           Self                         100       65020 I
* 100.100.100.0/30   Self                         100       I

However wait a minute, we are not seeing any routes under BGP table on RR

RR-re0> show route receive-protocol bgp 10.198.123.204 logical-system l3vpn-RR
inet.0: 96 destinations, 96 routes (96 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l3vpn.0: 89 destinations, 178 routes (0 active, 0 holddown, 178 hidden)
Restart Complete

Why is this??.. Now this is fundamentally an issue with how the things were setup.

As I mentioned above inet.3 table stores the egress address of an MPLS label-switched path (LSP) which is used by BGP table to resolve next-hop addresses which in our case is loopback ip of PEs however as RR is not in forwarding path there are no MPLS LSPs configured on it and in-turn no inet.3 table entries which is a problem and that’s why you can see all entries in output above are hidden as bgp table is not able to resolve the next-hop IPs in inet3 table.

So there are number of ways to resolve this and will be discussing two of them here. Simplest one and most widely used method is to configure a static route for loopback IP subnet under inet.3 rib as below.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# load merge terminal relative
[Type ^D at a new line to end input]
rib inet.3 {
static {
route 10.198.123.0/24 {
discard;
metric 65535;
}
}
}
load complete
[edit logical-systems l3vpn-RR routing-options]
RR.re0# commit
re0:
configuration check succeeds
re0:
commit complete

Once you configure this, inet.3 table is populated with static entry and now BGP can use this to resolve the next-hop IP Address for each route and all entries are visible now in routing table.

RR.re0> show route logical-system l3vpn-RR table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
10.198.123.0/24   *[Static/5] 00:00:08, metric 65535
Discard
[edit logical-systems l3vpn-RR routing-options]
RR.re0# run show route logical-system l3vpn-RR table bgp.l3vpn.0
bgp.l3vpn.0: 89 destinations, 178 routes (89 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
.
.
.
.
10.198.123.204:12:10.0.0.240/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: 65020 I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: 65020 I, validation-state: unverified
to Discard
10.198.123.204:12:100.100.100.0/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard
10.198.123.204:116:10.0.0.24/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard

Another option is to let inet3.0 use the rib already calculated by inet.0 table by using the below command.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# show
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
resolution {
rib inet3.0 {
resolution-ribs inet.0;
}
}

Both of these methods are valid and it depends upon which one you want to use in your network. For 2nd method you can configure prefix-list to list down only the specific network you want to exchange.

So that’s all for today. I hope I was to make it easy for you to understand. Let me know in case you have any comments or queries. J

R
Mohit

4 Byte AS Number

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.

  1. asplain –> asplain is a simple decimal representation of the ASN, from 0 to 4294967295.
  2. 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. 
  3. 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??

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