Category Archives: Cisco

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

ARP, InARP, RARP, Proxy ARP & Gratuitous ARP?? Whats this all about!!

There are lots of Arp terms in Network field today i.e. ARP, RARP, InARP, Proxy ARP and Gratuitous ARP. This was really confusing for me atleast in my early networking days and I am sure people who are new to networking must be in same situation. So I thought of putting the details here in order to alleviate their confusion. So let’s start

 1) ARP (Address Resolution Protocol)

ARP or Address Resolution protocol is a protocol as its name states which works on TCP/IP Layer 2. Networking between devices can’t be done without using this protocol which basically helps in getting the mac-address of connected router or gateway from IP Address. So for example, host/computer is connected to Router over Ethernet and we have manually configured IP Addresses on both sides with Router acting as Gateway for Host computer. Before Host can send packet to Router, it needs to build Layer 2 Frame and this frame encapsulates Packet including Payload/Date. You know that Frame has Source MAC-Address and Destination MAC-Address fields apart from other fields. So host can take out source-mac address from value burned in its NIC (Network Interface card) however it won’t be knowing the destination mac-address and in order to get the value of destination mac address host uses ARP. So Host will send broadcast ARP request message (destination FF:FF:FF:FF:FF:FF MAC address), which is accepted by all computers, requesting an answer for router’s gateway mac-address which is returned by Router in form for Arp-reply as a unicast.

APR_Packet Format

54:1e:56:f7:7d:4a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 602, p 0, ethertype ARP, arp who-has 20.20.20.20 tell 20.20.20.200

00:00:00:5e:00:00 > 54:1e:56:f7:7d:4a, ethertype 802.1Q (0x8100), length 64: vlan 602, p 0, ethertype ARP, arp reply 20.20.20.20 is-at 00:00:00:5e:00:00

2) InARP ( Inverse ARP)

Now what is Inverse Arp then? Inverse ARP as you might guess is the opposite of ARP.  Instead of using layer 3 IP address to find a layer 2 MAC address, Inverse ARP uses layer 2 MAC addresses to find a layer 3 IP address.

Inverse ARP was mostly used by Framerelay and ATM Networks to map the DLCI to IP Address. So router basically asks the IP Address of destination or other end of PVC by listing DLCI for that router.

3) RARP (Reverse ARP)

Reverse ARP is same as Inverse ARP however it was mainly used for device configuration. In InARP IP Address of remote end was being asked however RARP task is to get the IP Address for its own purpose.

A network administrator creates a table in a local area network’s gateway router that maps the physical machine (or Media Access Control – MAC address) addresses to corresponding IP Addresses. When a new machine is set up, its RARP client program requests it’s IP Address from the gateway router. Assuming that an entry has been set up in the router table, the RARP server will return the IP address to the machine which can store it for future use.

Reverse ARP has been deprecated and replaced by BOOTP which was then later replaced by DHCP.

4) Proxy ARP

As we mentioned above that the ARP is basically to find out Layer 2 address from Layer 3 IP Address. Now suppose host is connected to router over Ethernet and host has one address 10.10.0.1/16 and router has 10.10.10.0/24.

Host wants to resolve the ARP for 10.10.0.100 and thinks that Router is also in same subnet so should be able to get the mac-address however as Routers by design limit broadcast domains so won’t be sending the arp reply back and request will be rejected. If on the other hand router has any other interface connected to 10.10.0.0/16 network and proxy-arp is enabled, in that case Router will send the arp reply to host by listing its own mac-address basically acting as proxy for destination Network. In this case we don’t have to change the netmask of host and it will work fine.

On Cisco interfaces, when we configure “no ip proxy-arp”, we are disabling this behaviour.

5) Gratuitous ARP

Gratuitous ARP is by far the interesting version of ARP and lets see how gratuitous ARP works. We will go through 2 use cases here:

Firstly let’s discuss some of the properties of GARP

  • Both source and destination IP in the packet are the IP of the host issuing the gratuitous ARP
  • The destination MAC address is the broadcast MAC address (ff:ff:ff:ff:ff:ff) . This means the packet will be flooded to all ports on a switch
  • No reply is expected

1st use case of GARP is finding duplicate IP Address on LAN. Host which wakes up lets say after reboot sends GARP by putting the Sender IP address and Target IP Address as its own IP and broadcast the frame using Ethernet II destination address of all FFs.

It is not expecting any reply however if someone replies back with mac-address corresponding to Target IP Address then it means that IP address is being used somewhere else in LAN which is a problem. In this way host can detect duplicates.

2nd use case of GARP is case of redundancy protocols like VRRP/HSRP. VRRP (Virtual Redundancy Routing Protocol) or HSRP works by providing redundant physical gateways to host reachable over same Virtual address in order for Host to reach destination networks even though one physical router is down.

GARP_VRRP

VRRP has VIP (Virtual IP) concept which is shared among 2 VRRP routers and one of them is Active at any one time and holds Virtual MAC-Address corresponding to this VIP. Whenever host requests for ARP for 10.1.1.1, Master router will reply back with Virtual MAC Address.

Now we know that Switch updates its MAC Address table by looking at Mac address being learned on which port. Assuming Router 1 is Master currently, Switch will have entry in its table for Virtual Mac address learnt via Eth1 interface.

Let’s suppose that Router 1 goes down and in that case Router 2 sends GARP forcing switch to update its MAC-address table in order for it to update new location of Virtual MAC address reachable over new port i.e Eth2.

In this way, Host never sees an issue and packets sent by it will always egress a correct port.

Format of Gratuitous ARP

GARP Format

So that’s all, I hope you enjoyed this blog and I was able to clear some of your confusion. Let me know if you still have any doubt.

Thanks

Mohit Mittal

L2VPN via CCC in Junos!!!!

L2VPNs are another type of VPNs which Service providers have in their kitty to connect their customers over its MPLS environment. With L2VPNs, service providers extend the Customer LAN over the SP network and customer don’t have any idea that they are connected over the MPLS network. There are many variants of L2VPNs and majority of them use LDP/BGP schemes to configure this. However first method which was implemented for carrying layer 2 traffic over a MPLS network was CCC (Circuit Cross Connect) which we will talk here and still being used by many SPs to connect their customers.

CCC scheme always use an RSVP Signaled LSP which has advantage of taking Traffic Engineering properties of RSVP. For each connection between Customers we need to have a dedicated LSP which is different from LDP/BGP schemes which use same Transport LSP to send the traffic E2E.

As we have dedicated LSP between 2 End Point PEs, there is no concept of VPN Label to associate the corresponding VRF/Customer interface in case of CCC scheme. Also in CCC, as there is only label E2E, we need to disable the PHP (Penultimate Hop Popping) so that Penultimate Hop Router doesn’t Pop the label which would otherwise send plain Ethernet Frame to Egress PE and PE won’t be knowing what to do with this.

For a point-to-point CCC connection, the connection is bidirectional, so an RSVP-signaled LSP is required in each direction between the two PEs.

We will look at configuration of L2VPN via CCC method on Junos where we will use the below Network to configure it.

VPN CCC Model

As the connection needs to be bidirectional, we will only look at the forwarding path from Left to right however other direction would be using the same method.

On Ingress side, Customer CE-1 is connected to ge-0/1/8/.601 interface on MX104 PE and interface config would be:

Re1@Ingress_PE> show configuration interfaces ge-0/1/8
description "Connected to Customer CE-1";
vlan-tagging;
mtu 1522;
encapsulation vlan-ccc;
unit 601 {
    encapsulation vlan-ccc;
    vlan-id 601;
    family ccc;
}

Vlans 512-4094 are only reserved for vlan-ccc encapsulation so you need to use vlan greater than equal to 512.

On Egress side, Customer CE-2 is connected to xe-2/0/0.601 interface on MX960 PE and interface config would be:

Re1@Egress_PE> show configuration interfaces xe-2/0/0
description "Connected to Customer CE-2";
vlan-tagging;
mtu 1522;
encapsulation vlan-ccc;
unit 601 {
 encapsulation vlan-ccc;
 vlan-id 601;
 family ccc;
}

Next config is to create a Label switched path from Ingress to Egress with an optional strict ‘path’ to fully utilize the TE properties otherwise router will dynamically calculate the path towards Egress.

In our case, we have defined the path

So LSP from Ingress MX104 PE to Egress PE MX960 via Transit PE looks like:

Re1@Ingress_PE > show configuration protocols mpls label-switched-path MX104-MX960
to 10.198.123.205;
bandwidth 100m;
optimize-timer 900;
preference 200;
priority 5 0;
primary MX104-MX960; <<<<< Path

Re1@Ingress_PE > show mpls lsp name MX104-MX960
Ingress LSP: 11 sessions
To             From           State Rt P ActivePath LSPname
10.198.123.205 10.198.123.100 Up    0 * MX104-MX960 MX104-MX960
Total 1 displayed, Up 1

LSP is Up and everything looks fine from Ingress to Egress. In same way we have to configure the LSP from MX960 to MX104 in other direction. Once both LSPs are up, we have to bind these LSPs and Ingress Interface under one connection on MX104 and same way in MX960.

Lets check on MX104 Ingress

Re1@Ingress_PE > show configuration protocols connections remote-interface-switch L2VPN
interface ge-0/1/8.601;
transmit-lsp MX104-MX960; 
receive-lsp MX960-MX104;  

Once we have configured this on both sides, we should have this connection Up and running. Lets check this.

Re1@Ingress_PE > show connections remote-interface-switch L2VPN
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:

So we have UP state once config is done on both sides. Our L2VPN is ready to accept and switch the traffic to egress. For any chance if there is any issue in config like vlan-mismatch on other end or LSP is down because of any reason like path or Bandwidth issue, connection won’t be up and we can see from the various legend from the command output showing exactly where is the issue.

Now as Control plane is configured, let’s check how Forwarding plane looks like.

Lets see the label which has been allocated by Ingress PE for this LSP.

Re1@Ingress_PE > show rsvp session ingress up name MX104-MX960
Ingress RSVP: 11 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up    0 1 FF         - 307680   MX104-MX960
Total 1 displayed, Up 1, Down 0

Re1@Ingress_PE > show route table mpls.0 label-switched-path MX104-MX960 extensive
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Restart Complete
ge-0/1/8.601 (1 entry, 1 announced)
TSI:
KRT in-kernel ge-0/1/8.601.0 /32 -> {Push 307680}
 *CCC Preference: 200/1
 Next hop type: Router, Next hop index: 829
 Address: 0x2b4c224
 Next-hop reference count: 2
 Next hop: 10.0.0.169 via ge-0/0/1.0 weight 0x1, selected
 Label-switched-path MX104-MX960
 Label operation: Push 307680
 Label TTL action: no-prop-ttl
 Session Id: 0x3
 State: 
 Local AS: 65004
 Age: 19:10 Metric: 328
 Validation State: unverified
 Task: MPLS
 Announcement bits (1): 0-KRT
 AS path: I

Lets look at Transit PE-1. As you can see below, Label from MX104 Ingress is being swapped here with 300928.

Re1@Transit-PE-1> show rsvp session transit name MX104-MX960
Transit RSVP: 13 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      307680  300928 MX104-MX960
Total 1 displayed, Up 1, Down 0

Similarly on Transit PE-2

Re1@Transit-PE-2> show rsvp session transit name MX104-MX960
Transit RSVP: 7 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      300928  300427  MX104-MX960
Total 1 displayed, Up 1, Down 0

At Egress PE,

Re1@Egress-PE> show rsvp session egress up name MX104-MX960
Egress RSVP: 29 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      300427  -        MX104-MX960
Total 1 displayed, Up 1, Down 0

Re1@Egress-PE> show route table mpls.0 label 300427 extensive
mpls.0: 81 destinations, 81 routes (81 active, 0 holddown, 0 hidden)
Restart Complete
300427 (1 entry, 1 announced)
TSI:
KRT in-kernel 300427 /52 -> {Pop }
 *CCC Preference: 7
 Next hop type: Router, Next hop index: 1725
 Address: 0xe9414fc
 Next-hop reference count: 2
 Next hop: via xe-2/0/0.601, selected
 Label operation: Pop
 Load balance label: None;
 Label element ptr: 0xa7c8780
 Label parent element ptr: 0x0
 Label element references: 20
 Label element child references: 0
 Label element lsp id: 0
 Session Id: 0x0
 State: 
 Local AS: 65004
 Age: 2d 2:21:13
 Validation State: unverified
 Task: MPLS global
 Announcement bits (1): 1-KRT
 AS path: I

Just to confirm this all, you can use the below command on Ingress/Egress PE which shows what all labels being pushed and used for this LSP via CCC.

Re1@Ingress_PE > show connections remote-interface-switch L2VPN labels
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
  Outgoing labels: Push 307680

Re1@Egress_PE > show connections remote-interface-switch L2VPN labels
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
  Incoming labels: 300427
 Outgoing labels: Push 301040

Others labels shown in above commands are for opposite direction from Egress to Ingress.

So that’s all for L2VPN CCC. I hope I have been able to clear your doubts if you had any. if you have any queries, please let me know. In future blogs, we will discuss other methods of doing L2VPN.

Regards

Mohit