Category Archives: Junos

RSVP Messages in Juniper JunOS

6 Jul 2017Juniper, Junos, MPLS, Networking, RSVPCCC, Juniper, Junos, LSP, MPLS, Networking, RSVP, TCP/IPMohit

RSVP (Resource Reservation Protocol) is a transport layer protocol designed to reserve resources across a network for an integrated services Internet. RSVP is not a routing protocol and was designed to interoperate with current and future routing protocols.

RSVP by itself is rarely deployed in telecom networks today but the traffic engineering extension of RSVP, or RSVP-TE, is becoming more widely accepted nowadays in many QoS-oriented networks

In this blog we will see the RSVP messages which flows while setting up the E2E LSP between 2 PEs.

Following model will be used to understand the behaviour.

LSP we will configure is TEST-MX960-MX104 between MX960 (Hostname : Bentley) and MX104 (Hostname Pagani) via M320 and M120.

Let’s configure the LSP as below from MX960 to MX104 (loopback IP: 10.198.123.100) with strict path through M320 and M120.

re1.bentley> show configuration protocols mpls label-switched-path TEST-MX960-MX104
to 10.198.123.100;
bandwidth 100m;
optimize-timer 900;
preference 200;
priority 5 0;
primary Bentley-Pagani;

re1.bentley> show configuration protocols mpls path Bentley-Pagani
10.0.0.93 strict;
10.0.0.41 strict;
10.0.0.170 strict;

Before we see the RSVP session details, lets see the message interactions happening at each device from Ingress to Egress. We enabled the RSVP traceoptions in order to capture the packets.

As soon as LSP is configured, RSVP new session is built with tunnel ID (44394 in our case) which is unique for this LSP and will be present in all messages.

Jun 25 18:32:31.822264 RSVP new Session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0, session ID 51419

Jun 25 18:32:31.822301 RSVP new path state, session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0

Path Messages:

Path message will be sent by Ingress PE MX960 towards MX104 hop by hop using the strict path we configured or will be based on IGP path in case no path has been defined.

MX960 will send the RSVP Send path message which will be received by Transit routers which in turn will send their own Path messages.

On MX960:

Jun 25 18:32:31.824365 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 ge-1/1/7.0 flags=0x1 ttl=255
Jun 25 18:32:31.824385 Integty Len 36 flag 0x0 key 0x00005e00000a seq 0xbf015059de530a00 digest 0x75c574bd 0x3c7e8ecb 0x435976f8 0x408b3263
Jun 25 18:32:31.824399 MessageID Len 12 Msg_ID: 878279 Epoch: 2641670 (Ack Desired)
Jun 25 18:32:31.824415 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.824431 Hop Len 12 10.0.0.94/0x80000009
Jun 25 18:32:31.824443 Time Len 8 30000 ms
Jun 25 18:32:31.824464 SrcRoute Len 28 10.0.0.93 S 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.824477 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.824492 Properties Len 12 Primary path
Jun 25 18:32:31.824505 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.824520 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.824546 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.824560 ADspec Len 48 MTU 1500
Jun 25 18:32:31.824575 RecRoute Len 12 10.0.0.94

M120:

Jun 25 18:32:31.941242 RSVP recv Path 10.0.0.94->10.0.0.93 Len=272 ge-2/0/0.0 flags=0x1 ttl=255
Jun 25 18:32:31.941261 Integty Len 36 flag 0x0 key 0x00005e00000a seq 0xbf015059de530a00 digest 0x75c574bd 0x3c7e8ecb 0x435976f8 0x408b3263
Jun 25 18:32:31.941273 MessageID Len 12 Msg_ID: 878279 Epoch: 2641670 (Ack Desired)
Jun 25 18:32:31.941287 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.941299 Hop Len 12 10.0.0.94/0x80000009
Jun 25 18:32:31.941310 Time Len 8 30000 ms
Jun 25 18:32:31.941328 SrcRoute Len 28 10.0.0.93 S 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.941338 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.941349 Properties Len 12 Primary path
Jun 25 18:32:31.941359 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.941372 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.941393 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.941405 ADspec Len 48 MTU 1500
Jun 25 18:32:31.941417 RecRoute Len 12 10.0.0.94

Jun 25 18:32:31.943251 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 so-2/1/0.1 flags=0x1 ttl=254
Jun 25 18:32:31.943266 Integty Len 36 flag 0x0 key 0x00002a00000a seq 0xbf0150594b670e00 digest 0xc5bc0316 0x87716529 0xf2ca9320 0xd0fdd978
Jun 25 18:32:31.943277 MessageID Len 12 Msg_ID: 211 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:31.943290 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:31.943303 Hop Len 12 10.0.0.42/0x80000003
Jun 25 18:32:31.943313 Time Len 8 30000 ms
Jun 25 18:32:31.943328 SrcRoute Len 20 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:31.943338 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:31.943349 Properties Len 12 Primary path
Jun 25 18:32:31.943359 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:31.943372 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:31.943390 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:31.943402 ADspec Len 48 MTU 1500
Jun 25 18:32:31.943416 RecRoute Len 20 10.0.0.42 10.0.0.94

M320:

Jun 25 18:32:32.029412 RSVP recv Path 10.0.0.42->10.0.0.41 Len=272 so-0/3/0.1
Jun 25 18:32:32.029465 Integty Len 36 flag 0x0 key 0x00002a00000a seq 0xbf0150594b670e00 digest 0xc5bc0316 0x87716529 0xf2ca9320 0xd0fdd978
Jun 25 18:32:32.029477 MessageID Len 12 Msg_ID: 211 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.029488 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.029498 Hop Len 12 10.0.0.42/0x80000003
Jun 25 18:32:32.029506 Time Len 8 30000 ms
Jun 25 18:32:32.029519 SrcRoute Len 20 10.0.0.41 S 10.0.0.170 S
Jun 25 18:32:32.029527 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.029537 Properties Len 12 Primary path
Jun 25 18:32:32.029547 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.029556 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.029580 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.029590 ADspec Len 48 MTU 1500
Jun 25 18:32:32.029600 RecRoute Len 20 10.0.0.42 10.0.0.94

Jun 25 18:32:32.031527 RSVP send Path 10.198.123.205->10.198.123.100 Len=272 ge-1/3/3.0
Jun 25 18:32:32.031541 Integty Len 36 flag 0x0 key 0x0000a900000a seq 0xbf015059f47d0a00 digest 0xbb579467 0x457e455a 0x915f3fa4 0x6eeb2319
Jun 25 18:32:32.031550 MessageID Len 12 Msg_ID: 5484 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.031560 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.031569 Hop Len 12 10.0.0.169/0x091a536c
Jun 25 18:32:32.031577 Time Len 8 30000 ms
Jun 25 18:32:32.031586 SrcRoute Len 12 10.0.0.170 S
Jun 25 18:32:32.031594 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.031603 Properties Len 12 Primary path
Jun 25 18:32:32.031652 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.031662 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.031676 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.031686 ADspec Len 48 MTU 1500
Jun 25 18:32:32.031697 RecRoute Len 28 10.0.0.169 10.0.0.42 10.0.0.94

MX104:

Jun 25 18:32:32.149670 RSVP recv Path 10.0.0.169->10.0.0.170 Len=272 ge-0/0/1.0 flags=0x1 ttl=253
Jun 25 18:32:32.149787 Integty Len 36 flag 0x0 key 0x00000a0000a9 seq 0x595001bf000a7df4 digest 0x679457bb 0x5a457e45 0xa43f5f91 0x1923eb6e
Jun 25 18:32:32.149813 MessageID Len 12 Msg_ID: 5484 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.149840 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.149867 Hop Len 12 10.0.0.169/0x091a536c
Jun 25 18:32:32.149891 Time Len 8 30000 ms
Jun 25 18:32:32.149918 SrcRoute Len 12 10.0.0.170 S
Jun 25 18:32:32.149943 LabelRequest Len 8 EtherType 0x800
Jun 25 18:32:32.149968 Properties Len 12 Primary path
Jun 25 18:32:32.149993 SessionAttribute Len 24 Prio (5,0) flag 0x0 "TEST-MX960-MX104"
Jun 25 18:32:32.150018 Sender7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.150069 Tspec Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.150094 ADspec Len 48 MTU 1500
Jun 25 18:32:32.150121 RecRoute Len 28 10.0.0.169 10.0.0.42 10.0.0.94

RESV Messages

Once MX104 has received Path message, it will generate the RESV message containing the MPLS Label value towards its next-hop.

MX104:

Jun 25 18:32:32.151356 RSVP send Resv 10.0.0.170->10.0.0.169 Len=168 ge-0/0/1.0 flags=0x1 ttl=255
Jun 25 18:32:32.151402 Integty Len 36 flag 0x0 key 0x00000a0000aa seq 0x595001c00001e237 digest 0x2f64cc8a 0x402a4baf 0xbd34ce62 0x9436192e
Jun 25 18:32:32.151427 MessageID Len 12 Msg_ID: 1121 Epoch: 1236180 (Ack Desired)
Jun 25 18:32:32.151453 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.151479 Hop Len 12 10.0.0.170/0x091a536c
Jun 25 18:32:32.151503 Time Len 8 30000 ms
Jun 25 18:32:32.151527 Style Len 8 FF
Jun 25 18:32:32.151575 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.151600 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.151624 Label Len 8 301456
Jun 25 18:32:32.151650 RecRoute Len 12 10.0.0.170

M320:

Jun 25 18:32:32.235459 RSVP recv Resv 10.0.0.170->10.0.0.169 Len=168 ge-1/3/3.0
Jun 25 18:32:32.235476 Integty Len 36 flag 0x0 key 0x0000aa00000a seq 0xc001505937e20100 digest 0x8acc642f 0xaf4b2a40 0x62ce34bd 0x2e193694
Jun 25 18:32:32.235486 MessageID Len 12 Msg_ID: 1121 Epoch: 1236180 (Ack Desired)
Jun 25 18:32:32.235496 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.235506 Hop Len 12 10.0.0.170/0x091a536c
Jun 25 18:32:32.235514 Time Len 8 30000 ms
Jun 25 18:32:32.235523 Style Len 8 FF
Jun 25 18:32:32.235537 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.235547 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.235556 Label Len 8 301456
Jun 25 18:32:32.235565 RecRoute Len 12 10.0.0.170
Jun 25 18:32:32.235669 RSVP new resv state, session 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0

Jun 25 18:32:32.240512 RSVP send Resv 10.0.0.41->10.0.0.42 Len=176 so-0/3/0.1
Jun 25 18:32:32.240530 Integty Len 36 flag 0x0 key 0x00002900000a seq 0xbf01505945ae0d00 digest 0xa61d34f1 0x42d26c8a 0x33b66d12 0xdd26b232
Jun 25 18:32:32.240540 MessageID Len 12 Msg_ID: 5485 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.240551 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.240561 Hop Len 12 10.0.0.41/0x80000003
Jun 25 18:32:32.240569 Time Len 8 30000 ms
Jun 25 18:32:32.240577 Style Len 8 FF
Jun 25 18:32:32.240598 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.240608 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.240617 Label Len 8 315600
Jun 25 18:32:32.240629 RecRoute Len 20 10.0.0.41 10.0.0.170

M120:

Jun 25 18:32:32.357134 RSVP recv Resv 10.0.0.41->10.0.0.42 Len=176 so-2/1/0.1 flags=0x1 ttl=255
Jun 25 18:32:32.357151 Integty Len 36 flag 0x0 key 0x00002900000a seq 0xbf01505945ae0d00 digest 0xa61d34f1 0x42d26c8a 0x33b66d12 0xdd26b232
Jun 25 18:32:32.357162 MessageID Len 12 Msg_ID: 5485 Epoch: 8616743 (Ack Desired)
Jun 25 18:32:32.357177 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.357190 Hop Len 12 10.0.0.41/0x80000003
Jun 25 18:32:32.357200 Time Len 8 30000 ms
Jun 25 18:32:32.357210 Style Len 8 FF
Jun 25 18:32:32.357235 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.357249 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.357259 Label Len 8 315600
Jun 25 18:32:32.357274 RecRoute Len 20 10.0.0.41 10.0.0.170

Jun 25 18:32:32.379175 RSVP send Resv 10.0.0.93->10.0.0.94 Len=184 ge-2/0/0.0 flags=0x1 ttl=255
Jun 25 18:32:32.379194 Integty Len 36 flag 0x0 key 0x00005d00000a seq 0xc0015059ddcb0500 digest 0x123882a6 0xc852ee76 0x2564233e 0x68cb222c
Jun 25 18:32:32.379206 MessageID Len 12 Msg_ID: 212 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.379220 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.379233 Hop Len 12 10.0.0.93/0x80000009
Jun 25 18:32:32.379244 Time Len 8 30000 ms
Jun 25 18:32:32.379253 Style Len 8 FF
Jun 25 18:32:32.379281 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.379326 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.379338 Label Len 8 301728
Jun 25 18:32:32.379356 RecRoute Len 28 10.0.0.93 10.0.0.41 10.0.0.170

MX960:

Jun 25 18:32:32.465718 RSVP recv Resv 10.0.0.93->10.0.0.94 Len=184 ge-1/1/7.0 flags=0x1 ttl=255
Jun 25 18:32:32.465736 Integty Len 36 flag 0x0 key 0x00005d00000a seq 0xc0015059ddcb0500 digest 0x123882a6 0xc852ee76 0x2564233e 0x68cb222c
Jun 25 18:32:32.465750 MessageID Len 12 Msg_ID: 212 Epoch: 11650457 (Ack Desired)
Jun 25 18:32:32.465767 Session7 Len 16 10.198.123.100(port/tunnel ID 44394 Ext-ID 10.198.123.205) Proto 0
Jun 25 18:32:32.465785 Hop Len 12 10.0.0.93/0x80000009
Jun 25 18:32:32.465798 Time Len 8 30000 ms
Jun 25 18:32:32.465811 Style Len 8 FF
Jun 25 18:32:32.465841 Flow Len 36 rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
Jun 25 18:32:32.465856 Filter7 Len 12 10.198.123.205(port/lsp ID 1)
Jun 25 18:32:32.465869 Label Len 8 301728
Jun 25 18:32:32.465890 RecRoute Len 28 10.0.0.93 10.0.0.41 10.0.0.170

re1.bentley> show rsvp session name TEST-MX960-MX104 detail
Ingress RSVP: 30 sessions
10.198.123.100
 From: 10.198.123.205, LSPstate: Up, ActiveRoute: 0
 LSPname: TEST-MX960-MX104, LSPpath: Primary
 LSPtype: Static Configured
 Suggested label received: -, Suggested label sent: -
 Recovery label received: -, Recovery label sent: 301728
 Resv style: 1 FF, Label in: -, Label out: 301728
 Time left: -, Since: Sun Jun 25 18:32:31 2017
 Tspec: rate 100Mbps size 100Mbps peak Infbps m 20 M 1500
 Port number: sender 1 receiver 44394 protocol 0
 PATH rcvfrom: localclient
 Adspec: sent MTU 1500
 Path MTU: received 1500
 PATH sentto: 10.0.0.93 (ge-1/1/7.0) 3 pkts
 RESV rcvfrom: 10.0.0.93 (ge-1/1/7.0) 1 pkts, Entropy label: No
 Explct route: 10.0.0.93 10.0.0.41 10.0.0.170
 Record route: <self> 10.0.0.93 10.0.0.41 10.0.0.170
Total 1 displayed, Up 1, Down 0

As this service was part of L2VPN CCC configuration, hence no explicit null label was sent by penultimate hop router resulting in label sent to MX960 PE.

xe-2/0/0.601 (1 entry, 1 announced)

TSI:

KRT in-kernel xe-2/0/0.601.0 /32 -> {Push 301728}

*CCC Preference: 200/1

Next hop type: Router, Next hop index: 1255

Address: 0xa5dba0c

Next-hop reference count: 2

Next hop: 10.0.0.93 via ge-1/1/7.0 weight 0x1, selected

Label-switched-path TEST-MX960-MX104

Label operation: Push 301728

Label TTL action: no-prop-ttl

Load balance label: Label 301728: None;

Label element ptr: 0xa7cc2c0

Label parent element ptr: 0x0

Label element references: 3

Label element child references: 0

Label element lsp id: 0

Session Id: 0xbcf

State: <Active Int>

Local AS: 65004

Age: 10:45 Metric: 425

Validation State: unverified

Task: MPLS global

Announcement bits (1): 1-KRT

AS path: I

So that’s all for RSVP in Junos. I hope you liked the blog and let me know if there are any queries.

Mohit Mittal

vrf-table-label on Juniper JunOS

16 Jun 2017BGP, Cisco, Juniper, Junos, MPLS, NetworkingBGP, Cisco, Juniper, Junos, L3VPN, MPLS, MVPN, Networking, tunnel-pic, vrf, vrf-table-labelMohit

In this blog we will discuss about one important knob in JunOS i.e vrf-table-label.

Vrf-table-label is useful for 2 purposes in Junos

Save label space
Perform 2 lookup on packet

So let’s understand it more. We will start with 1^st point above

Junos by default allocates same VPN Label to prefixes recieved from one CE Interface. So for example if you have 2 CEs connected via 2 different interfaces and they are in same VPN on PE then Junos will allocate 2 different VPN labels to the prefixes recieved. In Cisco this is different where VPN label is allocated on per prefix which according to some is not optimal but we are not comparing anything here.

Currently in our configuration vrf-table-label is not configured. If you see below, we have 2 CEs connected to Juniper M320 PE1 via 2 different interfaces and we have Ebgp relationship between them and we are receiving some routes over it.

PE1-re1> show route 10.203.20.6
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

10.203.20.4/30 *[Direct/0] 3d 00:21:55
> via ge-0/3/2.20

PE1-re1> show route 10.203.12.2
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

10.203.12.0/30 *[Direct/0] 00:10:26
> via so-1/0/0.12

PE1-re1> show route receive-protocol bgp 10.203.12.2 table MVPN-1.inet.0
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
* 10.1.225.128/32 10.203.12.2 65012 I
10.203.12.0/30 10.203.12.2 65012 I

PE1-re1> show route receive-protocol bgp 10.203.20.6 table MVPN-1.inet.0
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
* 10.0.233.0/30 10.203.20.6 65020 I

Now if we look at the VPN label which is being tagged by this PE1 for the routes received by CE, we can see that Junos is allocating separate VPN Labels to both of the routes which is what I mentioned earlier.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.0.233.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.233.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300448
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] 65020 I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300480
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

Now if we configure the vrf-table-label under routing instance on PE1, we can see the difference.

[edit routing-instances MVPN-1]
PE1-re1# set vrf-table-label

edit routing-instances MVPN-1]
PE1-re1# commit
re1:
configuration check succeeds
re0:
commit complete
re1:
commit complete

See the difference below, now only one VPN label is being allocated for the whole VRF and this really saves the label space.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 39
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.0.233.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.233.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 39
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] 65020 I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

So this completes one part. Now moving over to 2nd part.
Junos by default looks at the incoming MPLS packet, Pops the label and sends the underlying packet to CE without looking at IP packet at all. This situation is fine in case you have PE connected to CE via P2P links like Serial links however if you have Broadcast medium like Ethernet in between then router can’t just send the packet like this without first building the frame and to build frame it needs to do ARP lookup to get the MAC Address of the CE. So it needs to do extra lookup apart from MPLS lookup.
Vrf-table-label actually allows the router to do 2 lookups. The first lookup is done on the VPN label to determine which VRF table to refer to, and the second lookup is done on the IP header to determine how to forward packets to the correct end hosts on the shared medium. This can be useful for number of applications like ingress firewall filters, CoS etc. Now a days VT interface (tunnel-pic) is also used to do the same however if router doesn’t support tunnel-pic then vrf-table-label can be used in its place to do the same thing. With VTL, lsi interface is created which allows it to handle the first lookup before a second ARP/IP lookup is carried out through the PFE.

Lets rollback the changes we did above and come back to same situation where unique label is assigned per CE port.

VPN Label 300560 is assigned for the route by PE1 and when mpls table is checked for that particular label we can see action is Pop plus to send the packet directly to interface.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300560
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route table mpls.0 label 300560
mpls.0: 57 destinations, 57 routes (57 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
300560 *[VPN/170] 00:00:41
> via so-1/0/0.12, Pop

If we enable the vrf-table-label now and check the same route and corresponding label. Lets see what we see.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 40
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route table mpls.0 label 40
mpls.0: 53 destinations, 53 routes (53 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

40 *[VPN/0] 00:00:12
to table MVPN-1.inet.0, Pop

So we can see, label 40 is basically pointing to routing-table now and not to interface as in our previous case. You can see the corresponding LSI interface allocated by looking at following command

PE1-re1> show route instance MVPN-1 detail
MVPN-1:
Router ID: 10.14.233.1
Type: vrf State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
lsi.24
so-1/0/0.12
ge-0/3/3.50
ge-0/3/2.20
vt-1/2/0.20
Route-distinguisher: 10.198.123.203:32764
Vrf-import: [ __vrf-import-MVPN-1-internal__ ]
Vrf-export: [ __vrf-export-MVPN-1-internal__ ]
Vrf-import-target: [ target:65000:321 ]
Vrf-export-target: [ target:65000:321 ]
Fast-reroute-priority: low
Tables:
MVPN-1.inet.0 : 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
MVPN-1.inet.1 : 11 routes (9 active, 0 holddown, 0 hidden)
Restart Complete
MVPN-1.mvpn.0 : 77 routes (42 active, 7 holddown, 0 hidden)
Restart Complete

Ok so that’s all. I hope you liked the blog and I was able to resolve some of your confusion on this command. If you still have any queries, please let me know and I would be happy to discuss.

Regards
Mohit Mittal

DHCP Server on Juniper MX104

2 Jun 2017Alcatel, Cisco, Juniper, Junos, NetworkingAlcatel, Cisco, DHCP, Juniper, Junos, Networking, TCP/IPMohit

In this blog, we will discuss about configuration of DHCP for IPv4 on Junos particularly for MX104. MX router will act as a DHCP Local server which will assign IP Addresses to clients from the DHCP pool configured.

To configure DHCP as local server we need to apply the following license on MX which is paid license over the top.

subscriber-address-assignment – Radius/SRC Address Pool Assignment

subscriber-ip – Dynamic and Static IP

For those who doesn’t want to buy license, they have option of configuring the DHCP as relay however for which server will be external and not internal.

With this blog, we will look at configuration of router acting as DHCP server. Relay configuration is not part of this current blog.

Below model topology will be used where clients (Windows Laptop) is connected to MX104 PE via switch. VRRP is configured with MX104 CE-1 and MX104 CE-2 and both are acting as DHCP Server, however we will be looking at configuration of MX104 CE-1 as same configuration needs to be configured on both.

MX104 PE is connected to MX960 PE over L2VPN which is just extending the L2 domain from client over to DHCP server.

Ok Lets start by looking at Interface configuration on MX104-CE-1 where xe-2/0/3 link is connected to EX4550 switch and VRRP is running with VRRP VIP as 50.50.50.1 and address on logical interface is 50.50.50.101.

Nothing special till here and no DHCP configuration even.

MX104-CE-1> show configuration logical-systems LS2-CLMB interfaces xe-2/0/3
unit 601 {
 vlan-id 601;
 family inet {
 address 50.50.50.101/24 {
 vrrp-group 201 {
 virtual-address 50.50.50.1;
 priority 200;
 accept-data;
 track {
 route 0.0.0.0/0 routing-instance default priority-cost 101;
 }
 }
 }
 }
}

Ok now lets add DHCP configuration by defining the dhcp-local server under system services hierarchy.

Here we need to define the group with any arbitrary name and interface which will be participating in DHCP msg exchange.

system {
 services {
 dhcp-local-server {
 group dhcp {
 interface xe-2/0/3.601;
 }
 }
 }
}

Once dhcp server has been defined, we will configure DHCP pools to provide addresses to clients.

In same heirachy we can define the dhcp-attributes like lease time, DNS servers and router which suggests the ip address of router in the subnetwork. We have 2 routers providing the DHCP services however as its under VRRP it will be better to give just one address which will be VRRP VIP. In this way in case of any issues on CE-1, VIP will move over to CE-2 and it will be able to assign the addresses.

Range is defined as ip addresses which DHCP server will assign. Lease time is 24 hours in seconds i.e 86400

access {
 address-assignment {
 pool dhcp {
 family inet {
 network 50.50.50.0/24;
 range dhcp {
 low 50.50.50.4;
 high 50.50.50.100;
 }
 dhcp-attributes {
 maximum-lease-time 86400;
 name-server {
 8.8.8.8;
 }
 router {
 50.50.50.1;
 }
 }
 }
 }
 }
}

Once everything is done, as soon as Laptop comes online it will send the request and MX104 will assign the ip address. We will see the messages in just a while but one thing to note is that if you have protect-RE firewall filter configured on loopback0 interface of MX104, it is essential to allow bootps and bootpc messages

term dhcp {
from {
 protocol udp;
 port [ bootpc bootps ];
}
then accept;
}

MX104_CE-1> show dhcp server binding logical-system LS2-CLMB
IP address Session Id Hardware address  Expires State Interface
50.50.50.5 2          68:f7:28:45:14:91 85495   BOUND xe-2/0/3.601

As you can see above, 50.50.50.5 address has been assigned by MX104 and state is BOUND and also listing the hardware address of client machine.

Now lets see how DHCP messages flow. I have shown below the snapshots of wireshark capture for the DHCP messages.

As soon as Laptop comes online or it is connected to LAN, first message it sent is DHCP discover message which is basically a broadcast BOOTP message with frame field as its own mac address as source and all FFs as destination MAC. UDP port number is 68 with destination as 67 so it is basically looks like

UDP 0.0.0.0:68 -> 255.255.255.255:67

As client doesn’t have IP address at this time, it uses 0.0.0.0 as src ip.

68 is standard UDP port assigned for bootp client and 67 for bootp server.

Once client broadcasts the DHCP discover request, DHCP server sends a DHCP Offer. Src IP Address is physical IP of router which is currently holding the VIP in VRRP case. In our case its MX104 CE-1.

Offer will contain the IP Address 50.50.50.5 as we have already seen in CLI output above along with other parameters which we configured like Lease time, Subnet Mask, Router address, DNS Server etc etc.

After receiving the Offer and before accepting it, client again sends the broadcast message by including the IP 50.50.50.5 for confirmation.

At this point, DHCP server sends unicast acknowledgment for it to keep the address and connection is complete.

DHCP Client will periodically sends DHCP Inform messages (both Unicast and Broadcast) to let others know of the address being used.

Ok so that’s all for DHCP, i hope you liked the post and let me know if you have any feedback or queries.

Mohit Mittal

Junos Telemetry

27 May 2017Cisco, Juniper, Junos, Monitoring, Networking, SDN, SNMPCisco, Juniper, Junos, Networking, Northstar, SDN, SNMP, TelemetryMohit

Hi All

Recently I attended a Juniper workshop in their London office and heard about Junos Telemetry concept which was really a new one for me and I quite liked it.

The basic idea is to replace traditional methods of collecting the data from devices on Management stations which helps Operations teams in more automated solution for managing their vast networks.

Traditional method which I am talking about here is SNMP which works on Pull model where Management station polls the network devices to gather useful information using MIBs and in turn displays the data to Network Admins/Operations Team. This method is being used currently and have succeed a lot. However as Hardware vendors are providing more and more APIs in their products which can be used by users to configure their devices in lots of innovative ways, polling or gather statistics via SNMP is not scalable in those scenario. Also SNMP polls the devices at regular interval which is again an operational challenge as something can happen on device between the intervals which wont be captured.

Junos Telemetry or Telemetry concept in general provides a Push model where we can configure the device to send the real time data based upon any trigger or in general for various parameters.

Telemetry

Source: Juniper Networks

In this blog, we are not going to see how its configured in CLI but who knows when I can get hold of appropriate Junos code and have a play on it 🙂 but till then let’s see what are its other features.

Junos Telemetry interface (JIT) as I mentioned above works on Push model where it streams the results to collector or even to Controller like Northstar to drive MPLS LSPs. Format of data what is being sent is either in form of Google Protocol buffer GPB or can be JSON based.

Juniper provides the collector software however there are open source collectors as well called OpenNTI collector which is basically a docker container consisting of 3 open-source components.

FluentD (data collection, http://www.fluentd.org/)
InfluxDB (database, https://influxdata.com/)
Grafana (visualization, http://grafana.org/)

Shown below is one of the Visualization chart using Grafana,

Graphna

From application point of view, i think its one of the application could be to re-route the LSPs or create a LSP from Northstar Controller based upon the bandwidth statistics from interface. Once interface statistics reported to collector exceeds certain threshholds, Application can instruct Northstar controller to create a LSP via other route which can in long term works towards Self Driving Networks.

Other Application could be to provide more user-friendly stats about routers/network device to Operations like Memory, CPU usage in environment where thousands of routes or control packets are going via routers and memory hog can be created because of this.

Junos Telemetry Interface was introduced in Junos OS Release 15.1F3, on MX Series routers with interfaces configured on MPC1 through MPC6E, and on PTX Series routers with interfaces configured on FPC3.

So that’s all for Telemetry. I haven’t added much details on this as this is really a new concept for me and as n when I read more about it or get a chance to do hand-on on it, I will write more. Let me know your views on it and if you have used or planning to use this in your network.

Regards

Mohit

JUNIPER JUNOS COMMAND SERIES – 2

20 May 2017Cisco, Juniper, Junos, NetworkingCisco, Juniper, Junos, Junos_commands, NetworkingMohit

Hi All, lets continue our useful Junos command series by looking at 2 more interesting commands. One is really a way of doing same thing as in Cisco however 2^nd is completely different command n I doubt available in other vendor CLIs.

We will look at configuration from interface stanza but can be applied to other areas.

So this is our example interface config from one of the interface.

re0.MX104_PE> show configuration interfaces ge-0/0/1
description "Test";
mtu 1600;
hold-time up 0 down 1000;
unit 0 {
 family inet {
 address 10.0.0.170/30;
 }
 family mpls;
}

Now due to any reason the interface which you were using has changed and now you need to put the same config on lets support ge-0/0/3

Lets look at current config of ge-0/0/3

re0.MX104_PE> show configuration interfaces ge-0/0/3
re0.MX104_PE>

As expected, config is empty and nothing has been configured.

Ok to configure the same parameters on new interface, one method is to go n set each configuration stanza individually. i.e..

edit
edit interface ge-0/0/3
set description “Test”
etc etc…

which is valid method but time consuming. Junos gives us facility to do the same thing by using command “copy”

Using this command, you can copy the config from one interface to another without going through all those lengthy steps.

re0.MX104_PE> edit
Entering configuration mode
[edit]
re0.MX104_PE# copy interfaces ge-0/0/1 to ge-0/0/3

[edit]
re0.MX104_PE# show | compare
[edit interfaces]
+ ge-0/0/3 {
+ description "Test";
+ mtu 1600;
+ hold-time up 0 down 1000;
+ unit 0 {
+ family inet {
+ address 10.0.0.170/30;
+ }
+ family mpls;
+ }
+ }


re0.MX104_PE# delete interfaces ge-0/0/1

re0.MX104_PE# show | compare
[edit interfaces]
- ge-0/0/1 {
- description "Test";
- mtu 1600;
- hold-time up 0 down 1000;
- unit 0 {
- family inet {
- address 10.0.0.170/30;
- }
- family mpls;
- }
- }
+ ge-0/0/3 {
+ description "Test";
+ mtu 1600;
+ hold-time up 0 down 1000;
+ unit 0 {
+ family inet {
+ address 10.0.0.170/30;
+ }
+ family mpls;
+ }
+ }

So you can see this has made the configuration easy to move.

Only catch here is that target interface in which you want to copy the configuration should be totally empty of any configuration otherwise you will see error like this.

re0.MX104_PE# copy interfaces ge-0/0/1 to ge-0/0/3
error: target statement 'ge-0/0/3' already exists

Ok so that’s was one command

Lets move over to next command which is similar to Cisco or might be to other vendors but most of the Juniper engineers are not aware of this.

This is to delete the whole interface config and put that into default mode.

In Cisco IOS, we would be doing something like default interface <interface name> under config mode to put the config into default config.

In Juniper to achieve the same thing, you need to either delete individual statements under interface config or you can just mention delete at the top interface level which would prompt you for confirmation and will delete everything.

[edit]
re0.MX104_PE# edit interfaces ge-0/0/1

[edit interfaces ge-0/0/1]
re0.MX104_PE# show
description "Test";
mtu 1600;
hold-time up 0 down 1000;
unit 0 {
 family inet {
 address 10.0.0.170/30;
 }
 family mpls;
}

[edit interfaces ge-0/0/1]
re0.MX104_PE# delete
Delete everything under this level? [yes,no] (no) yes

[edit interfaces ge-0/0/1]
re0.MX104_PE# show | compare
[edit interfaces ge-0/0/1]
- description "Test";
- mtu 1600;
- hold-time up 0 down 1000;
- unit 0 {
- family inet {
- address 10.0.0.170/30;
- }
- family mpls;
- }

Only difference is that in Cisco using “default”, there will still be configuration present under interface like “no ip address” etc etc however in Junos, this will delete everything under it.

So that’s all, I hope you liked this article as well and will make use of these commands in your day to day operational work or troubleshooting.

Regards

Mohit Mittal

Juniper JunOS Command Series – 1

8 May 2017JNCIP, JNCIS, Juniper, Junos, NetworkingCisco vs Juniper, Juniper, Junos, Junos cheat sheet, Junos_commands, NetworkingMohit

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