BGP, Cisco, Juniper, Junos, MPLS, Networking

vrf-table-label on Juniper JunOS

2 Comments

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
Alcatel, Cisco, Juniper, Junos, Networking

DHCP Server on Juniper MX104

Leave a comment

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

 

Cisco, Juniper, Junos, Monitoring, Networking, SDN, SNMP

Junos Telemetry

2 Comments

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, Cisco, Networking, Junos

JUNIPER JUNOS COMMAND SERIES – 2

3 Comments

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

Alcatel, Cisco, Ethernet, Juniper, Networking, VRRP

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

1 Comment

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

JNCIP, JNCIS, Juniper, Junos, Networking

Juniper JunOS Command Series – 1

Leave a comment

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

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

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

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

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

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

MX104>edit
Entering configuration mode

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

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

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

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

Final config is:

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

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

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

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

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

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

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

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

Let’s see it in action.

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

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

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

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

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

Pretty exciting and fast !!! 🙂

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

Let’s see this in action one more time.

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

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


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

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

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

 

Regards

Mohit Mittal

 

 


	

	
	

	
	
		

	

	





			

			

				Advertisements