Tag Archives: Junos

vrf-table-label on Juniper JunOS

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

  1. Save label space
  2. Perform 2 lookup on packet

So let’s understand it more. We will start with 1st 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

 

 

Advertisements

DHCP Server on Juniper MX104

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.

DHCP Model

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.

DHCP_1

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.

DHCP_2

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

DHCP_3

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.

DHCP_4

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

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.

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

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 2nd 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

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

 

 


	

L2VPN using Kompella – Junos

In my earlier blog on L2VPN via CCC https://networkzblogger.com/2017/04/23/l2vpn-via-ccc-in-junos/ we saw in that method customer interface needs to be bind with LSP and for each customer we need to have separate LSP configured which is not ideal from operational perspective. In this blog we will look at another method of achieving this where BGP is used as signalling protocol which automates the connections, so manual configuration of the association between the LSP and the customer edge interface is not required.

This config is also called Kompella after its author (https://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00) where BGP is used to signal the control plane and it uses a two label stack as Martini. The VC (VPN) label is signalled via BGP and transport label can be signaled via either RSVP or LDP.

We would be looking at below topology where we will be configuring the MPLS L2VPN or Juniper L2CIRCUIT between M10i and MX960 PEs. M320s in between are just acting as Transit P/PE nodes and no configuration specifically needed on them for L2VPN however normal RSVP/LDP/MPLS/IGP config needs to be configured for transport label same as how L3VPN works.

L2VPN Kompella

MX104s are acting as RR so BGP neighborship will appropriate family needs to be activated between PEs-RRs.

For BGP based L2VPNs, following configuration needs to be configured

  1. BGP group with family l2vpn signalling
  2. Routing instance using instance type “l2vpn”
  3. Ethernet link needs to be established with Customer and same needs to be defined under Routing-instance.

Let’s start with Juniper l2vpn configuration.

First BGP Group where l2vpn signalling family needs to be enabled for PE-RR group.

BGP neighborship between M10i and one of the RR.

M10i-PE> show configuration protocols bgp group L2VPN-RRs
type internal;
family l2vpn {
    signaling;
}
authentication-algorithm md5;
authentication-key-chain BGP-L2VPN-key-chain;
neighbor 10.198.123.234;  <<<<<<<<< Loopback of RR1
neighbor 10.198.123.237;  <<<<<<<<< Loopback of RR2

BGP neighborship between M10i and one of the RR.

M10i-PE > show bgp neighbor 10.198.123.234
Peer: 10.198.123.234+179 AS 65004 Local: 10.198.123.213+50453 AS 65004
 Group: L2VPN-RRs Routing-Instance: master
 Type: Internal State: Established Flags: <Sync>
 Options: <Preference LocalAddress GracefulRestart LogUpDown AddressFamily Rib-group Refresh>
 Address families configured: l2vpn-signaling
 Local Address: 10.198.123.213 Holdtime: 90 Preference: 170
 Peer ID: 10.198.123.234 Local ID: 10.198.123.213 Active Holdtime: 90
 NLRI for restart configured on peer: l2vpn
 NLRI advertised by peer: l2vpn
 NLRI for this session: l2vpn
 Peer supports Refresh capability (2)
 Restart time configured on the peer: 120
 Stale routes from peer are kept for: 300
 Restart time requested by this peer: 120
 NLRI that peer supports restart for: l2vpn
 NLRI peer can save forwarding state: l2vpn
 NLRI that peer saved forwarding for: l2vpn
 NLRI that restart is negotiated for: l2vpn
 NLRI of received end-of-rib markers: l2vpn
 NLRI of all end-of-rib markers sent: l2vpn.
.
.

Even though customer facing config is not part of MPLS L2VPN, I will define it here which is using l2vpn encapsulation vlan-ccc.

M10i-PE > show configuration interfaces fe-0/1/1
description "Connected to CE-1";
vlan-tagging;
link-mode full-duplex;
encapsulation vlan-ccc;
unit 2 {
 encapsulation vlan-ccc;
 vlan-id 1001;
 family ccc;
}

Fairly simple configuration which is using encapsulation vlan-ccc.

OK, lets move to 2nd and 3rd part which is routing-instance configuration. I have highlighted important bits below. Off course for this L2VPN type you need to define RD, RT, and Interface which I am not mentioning specifically but you can see below.

M10i-PE > show configuration routing-instances L2VPN
instance-type l2vpn;
interface fe-0/1/1.2;
route-distinguisher 10.198.123.213:2;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Audi {
 site-identifier 2;
 interface fe-0/1/1.2 {
 remote-site-id 3;
 }
 }
 }
}

Important bit is instance-type l2vpn which enables this routing-instance for L2VPN. Under protocols l2vpn we have to enable the encap type as ethernet-vlan and then under site parameters we need to be define local site-identifier which is in our case is 2 and an optional remote-site-id. I have defined remote-site-id as 3 which will be configured on MX960 Remote-PE as its local site-identifier.

In same way we will be configuring the MX960 PE

MX960-PE> show configuration interfaces ge-1/1/9.700
encapsulation vlan-ccc;
vlan-id 700;
family ccc;

MX960-PE> show configuration routing-instances L2VPN
instance-type l2vpn;
interface ge-1/1/9.700;
route-distinguisher 10.198.123.205:3;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Bentley {
 site-identifier 3;
 interface ge-1/1/9.700 {
 remote-site-id 2;
 }
 }
 }
}

Once this is configured, let’s check the routing table on M10i

M10i-PE > show route table L2VPN.l2vpn.0
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.198.123.205:3:3:1/96 <<<<<<<<<------------ Learnt from MX960
 *[BGP/170] 13:56:58, localpref 100, from 10.198.123.237
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
 [BGP/170] 13:56:58, localpref 100, from 10.198.123.234
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
.
.
.
10.198.123.213:2:2:3/96 <<<<<<<<-------------- Local route on M10i
 *[L2VPN/170/-101] 16:56:08, metric2 1
 Indirect

This output is showing us RD value of 10.198.123.205:3 plus value of remote-side identifier which is 3 as well plus label-offset value which is 1

In same way, local route has RD value of 10.198.123.213:2 plus value of remote-side identifier which is 2 and label-offset value of 3. Will explain label-offset later.

So this completes our BGP control signalling path.

L2VPN connection state is up between both PEs

M10i-PE > show l2vpn connections up
Layer-2 VPN connections:

Instance: L2VPN
Edge protection: Not-Primary
 Local site: Audi (2)
 connection-site Type St Time last up # Up trans
 3               rmt  Up May 2 20:53:51 2017 1
 Remote PE: 10.198.123.205, Negotiated control-word: Yes (Null)
 Incoming label: 800006, Outgoing label: 800003
 Local interface: fe-0/1/1.2, Status: Up, Encapsulation: VLAN

Now we can move over to forwarding path where we will see MPLS labels. As in case of L3VPNs, we have 2 Labels on each packet i.e. VPN Label and other is transport label.

Transport label is calculated in same way where label is assigned for next-hop which in our case is remote-PE MX960 loopback address and this label can be learnt by any method LDP or RSVP and will be advertised to M10i PE by its immediate neighbour which in our case is M320.

So to check the label stack which is being pushed at M10i, we can see the MPLS.0 table.

M10i-PE > show route table mpls.0
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
.
.
.
fe-0/1/1.2 *[L2VPN/7] 14:27:18, metric2 1
 > via so-0/0/0.0, Push 800003, Push 299888(top) Offset: 252

So you can see two labels are being pushed, TOP (transport) label is 299888 which is advertised by M320

M320-Transit-P-1> show ldp database session 10.198.123.213
.
.

Output label database, 10.198.123.202:0--10.198.123.213:0
 Label Prefix
 306336 10.198.123.100/32
 299808 10.198.123.201/32
 3      10.198.123.202/32
 299792 10.198.123.203/32
 308832 10.198.123.204/32
 299888 10.198.123.205/32
 304288 10.198.123.211/32

VPN Label is 800003 which is calculated little bit differently in case of L2VPNs and not directly advertised by Remote-Pes.

Formula to calculate VPN label is

L2VPN label = Label-Base (remote) + Site-Id(Local) – Label-Offset (remote)

Label-base (remote) value is what we can get from MX960 by looking at its L2VPN.l2vpn table

MX960-PE > show route table L2VPN.l2vpn.0 extensive
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
.
.
 Advertised metrics:
 Flags: Nexthop Change
 Nexthop: Self
 Localpref: 100
 AS path: [65004] I
Path 10.198.123.205:3:3:1 Vector len 4. Val: 0
 *L2VPN Preference: 170/-101
 Next hop type: Indirect, Next hop index: 0
 Address: 0xa5d246c
.
.
.
 Label-base: 800002, range: 2, status-vector: 0x0, offset: 1
 Secondary Tables: L2VPN.l2id.0

You can see above that label-base is 800002 on MX960 and Label-offset value is 1

So as per our equation above,

L2VPN Label = 800002 + 2 (Site-id local on M10i)  – 1  = 800003

Once this VPN Label reaches MX960, it is pop as per normal MPLS procedures and out to CE-2 interface.

800003 *[L2VPN/7] 14:37:16
 > via ge-1/1/9.700, Pop Offset: 4

In same way, MX960 will also calculate the VPN label for traffic flowing from MX960 to M10i.

So that’s all for this blog. I hope you enjoyed it and let me know if you still have any issues.

 

Regards

Mohit Mittal