Category Archives: VRRP

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

12 May 2017Alcatel, Cisco, Ethernet, Juniper, Networking, VRRPAlcatel, ARP, Cisco, Gratuitous ARP, Inverse ARP, Juniper, Networking, Proxy Arp, Reverse ARP, TCP/IPMohit

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

1^st 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.

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

eBGP using IPv6 in Juniper JunOS

27 Apr 2017BGP, IPv6, Juniper, Networking, VRRPBGP, IPv6, Juniper, Junos, NetworkingMohit

Hi All

In my earlier post on VRRP https://networkzblogger.com/2017/04/15/vrrpv6-and-tracking-in-junos/ we looked at VRRPv6 and how VRRP tracking is working on receiving the Ipv6 default route. As that blog was mainly focusing on VRRP, so didn’t explained anything on Ebgp relationship over Ipv6 and IPV6 default route however in this post I will be mainly focusing on it.

Let’s start.

We will be using same Model as we used in earlier post, but in condensed form. Rather than looking at redundant configs, we will concentrate on one EBGP between 2 neighbors.

Below mentioned topology will be used where MX104 CE is connected to Juniper CE-1 ISP and we will have EBGP over IPV6 running between them and MX104 CE in turn receiving Ipv6 default route from ISP.

eBGP_IPv6

Lets look at Interface configs first on both sides.

MX104_CE> show configuration logical-systems LS1-Tower
interfaces {
    ge-0/0/4 {
        unit 600 {
            description "Connected to ISP-CE-1_ge-0/2/0.600";
            vlan-id 600;
            family inet6 {
                address 2a00:2380:3013:1000:0:0:0:3/127;
            }
        }
    }

ISP_CE-1> show configuration interfaces ge-0/2/0
description "Connected to MX104 CE_ge-0/0/4 ";
vlan-tagging;
mtu 1600;
hold-time up 0 down 1000;
link-mode full-duplex;
unit 600 {
    vlan-id 600;
    family inet6 {
        address 2a00:2380:3013:1000:0:0:0:2/127;
    }
}

Fairly straightforward configuration where we used statically configured IPV6 addresses. We could have also used 128-bit IPv6 addresses or we can use link local addresses but only requirement is that with link-local addressing we need to use statement “local-interface”. You can also use eui-64 address where we just need to know the /64 subnet and router auto calculates the ipv6 addresses by concatenating the subnet address with 48 bit mac-address and 16 bit 0xFFFE

Once this is done, let’s see the Ebgp config.

MX104_CE > show configuration logical-systems LS1-Tower protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
export [ Main_Subnets_IPV6 Backup_Subnets_IPV6 ];
local-as 65004;
neighbor 2a00:2380:3013:1000:0:0:0:2 {
    peer-as 2856;
}

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
       peer-as 65004;
}

Again a straightforward configuration on the same lines as Ipv4 where we defined separate group btnet6 for IPV6 config and added the neighbor command with corresponding peer autonomous system.

Now let’s see the bgp status

MX104_CE > show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2  2856          3                      4       0       1           3 Establ
  inet6.0: 0/0/0/0

BGP is up on MX104 CE however it is not receiving anything so let’s advertise IPV6 default route from ISP CE.

We need to manually add the static route under routing-options with discard or reject option (one will send ICMP unreachable and other will silently reject). You can notice the difference from IPV4 static route where there was no need to define the rib.

ISP_CE-1> show configuration routing-instances Internet-600
instance-type vrf;
interface fe-0/1/2.0;
interface ge-0/2/0.600;
interface ge-0/2/0.602;
route-distinguisher 2856:1;
vrf-target target:2856:1;
routing-options {
    rib Internet-600.inet6.0 {
        static {
            route ::/0 discard;
        }
    }
}

Once this is done, configure this under policy-statement and reference that policy as export under neighbor statement.

ISP_CE-1> show configuration policy-options policy-statement default-export-ipv6
from {
    route-filter ::/0 exact;
}
then accept;

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IGUK-IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
    export default-export-ipv6;
    peer-as 65004;
}

Now let’s check the default route on MX104:

Ok we see some activity now.

MX104_CE> show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2   2856                 7                       8       0       2             2:03              Establ
  inet6.0: 1/1/1/0

MX104_CE> show route logical-system LS1-Tower receive-protocol bgp 2a00:2380:3013:1000::2 extensive
inet6.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
* ::/0 (1 entry, 1 announced)
     Accepted
     Nexthop: 2a00:2380:3013:1000::2
     AS path: 2856 I

So we have this default route under MX104 and we used this to under VRRP tracking to track outgoing interface towards ISP.

So that’s all for this blog. If you have any queries, please let me know.

Regards

Mohit

VRRPv6 and Tracking in Junos

15 Apr 2017IPv6, Juniper, Networking, VRRPIPv6, Juniper, Junos, Networking, VRRP, VRRPv6Mohit

In this blog, we will look at VRRP (Virtual Redundancy Routing Protocol) and specifically VRRPv6 which as you must have guessed works for IPv6 Protocol.

VRRP is standardized version of redundancy protocol in comparison to Cisco proprietary HSRP both of which provides redundant Default Gateway address for EU clients or devices. The VRRP routers share the IP address corresponding to the default gateway configured on the hosts. At any time, one of the VRRP routers is the master (active) and the others are backups. If the master fails, one of the backup routers becomes the new master router, thus always providing a virtual default router and allowing traffic on the LAN to be routed without relying on a single router.

We will look at 2 scenarios in this blog

1) VRRPv6 configs and what additional things we need to take care

2) VRRP Tracking

This can become lengthy blog so please bear with me till the end 🙂

Below topology will be used for these scenarios where we have 2 Juniper EX4550 switches connected to Juniper MX104 CE (Junos 13.3). Even though 2 MX104 CEs are shown we will using 2 Logical systems inside one MX104 to simulate 2 CEs. Clients are connected behind EX4500 (not shown in picture). MX104 is connected in-turn to ISP CEs over eBGP and receiving IPv6 Default route from ISP. Fairly straightforward setup as you can see.

VRRP

Below is the configuration for VRRPv6 on both logical-systems where we are configuring higher VRRP priority for CE1 in order for it to be Master and holds virtual mac-address and router replies with this mac-address when arp (or specifically neighbour solicitation message in case of IPv6) request comes from Client who wants to send packet to Virtual gateway address. Virtual MAC address is always in format 00:00:5e:00:02:XX where XX is Virtual Router-ID or group ID configured under VRRP configuration.

re1.MX104_CE1> show configuration logical-systems LS2-CLMB
 xe-2/0/3 {
 unit 601 {
 vlan-id 601;
 family inet6 {
 address 2001:db9::3/64 {
 vrrp-inet6-group 201 {
 virtual-inet6-address 2001:db9::1;
 virtual-link-local-address fe80:db9::1;
 priority 200;
 accept-data;
 }
 }
 address fe80:db9::3/64;
 }
 }
 }
}
protocols {
 router-advertisement {
 interface xe-2/0/3.601 {
 max-advertisement-interval 4;
 virtual-router-only;
 prefix fc80::/64;
 }
}

re1.MX104_CE2> show configuration logical-systems LS2-Tower
 xe-2/0/1 {
 unit 601 {
 vlan-id 601;
 family inet6 {
 address 2001:db9::2/64 {
 vrrp-inet6-group 201 {
 virtual-inet6-address 2001:db9::1;
 virtual-link-local-address fe80:db9::1;
 priority 100;
 accept-data;
 }
 }
 address fe80:db9::2/64;
 }
 }
 }
}
protocols {
 router-advertisement {
 interface xe-2/0/1.601 {
 max-advertisement-interval 4;
 virtual-router-only;
 prefix fc80::/64;
 }
}

VRRPv6 configuration is very similar to VRRP with some difference related to syntax which is understandable however there are 3 additional commands (highlighted in Red above) we need to know. First of them is virtual-link-local-address which according to Juniper must be explicitly defined in VRRP for IPv6 as this field is used as source IPv6 address when sending packet from this router. 2nd requirement is that link-local address and virtual-link-local-address must share netmask otherwise Junos won’t allow us to commit and this is where I have configured address fe80:db9::2/64.

3^rd requirement which is very interesting one is usage of virtual-router-only command under router-advertisements. The master VRRP for an IPv6 router must respond to a router solicitation message with the virtual IP address of the router. However, when the interface statement is included at the [edit protocols router-advertisement] hierarchy level, the backup VRRP for an IPv6 router might send a response before the VRRP master responds, so that the default route of the client is not set to the master VRRP router’s virtual IP address. To avoid this situation, we need to include the virtual-router-only statement at the [edit protocols router-advertisement interface interface-name] hierarchy level. When this statement is included, router advertisements are sent only for VRRP IPv6 groups configured on the interface.

So with these configurations, let’s see how our VRRP is working

re1.MX104_CE1> show vrrp summary logical-system LS2-CLMB
Interface State Group VR state VR Mode Type Address
xe-2/0/3.601 up 201 master Active lcl 2001:db9::3
                                  vip fe80:db9::1
                                  vip 2001:db9::1

re1.MX104_CE2> show vrrp summary logical-system LS2-Tower
Interface State Group VR state VR Mode Type Address
xe-2/0/1.601 up 201 backup Active lcl 2001:db9::2
                                  vip fe80:db9::1
                                  vip 2001:db9::1

So as you can see, VRRP is working fine with CE1 acting as Master and CE2 acting as Backup.

Let’s see extract from extensive version of the command. Main thing to note here is Virtual mac which as I mentioned above is in format 00:00:5e:00:02:XX and XX in our case is c9 which is hex of Group ID 201.

re1.MX104_CE1> show vrrp extensive logical-system LS2-CLMB
.
.
Physical interface: xe-2/0/3, Unit: 601, Vlan-id: 601, Address: 2001:db9::3/64
 Index: 358, SNMP ifIndex: 611, VRRP-Traps: enabled, VRRP-Version: 2
 Interface state: up, Group: 201, State: master, VRRP Mode: Active
 Priority: 200, Advertisement interval: 1, Authentication type: none
 Advertisement threshold: 3, Computed send rate: 0
 Preempt: yes, Accept-data mode: yes, VIP count: 2, VIP: fe80:db9::1, 2001:db9::1
 Advertisement Timer: 0.698s, Master router: fe80:db9::3
 Virtual router uptime: 1d 20:59, Master router uptime: 1d 17:38
 Virtual Mac: 00:00:5e:00:02:c9
 
re1.MX104_CE2> show vrrp extensive logical-system LS2-Tower
.
.
Physical interface: xe-2/0/1, Unit: 601, Vlan-id: 601, Address: 2001:db9::2/64
 Index: 354, SNMP ifIndex: 607, VRRP-Traps: enabled, VRRP-Version: 2
 Interface state: up, Group: 201, State: backup, VRRP Mode: Active
 Priority: 100, Advertisement interval: 1, Authentication type: none
 Advertisement threshold: 3, Computed send rate: 0
 Preempt: yes, Accept-data mode: yes, VIP count: 2, VIP: fe80:db9::1, 2001:db9::1
 Dead timer: 3.002s, Master priority: 200, Master router: fe80:db9::3
 Virtual router uptime: 1d 21:01

Now as VRRP is working, we come to 2^nd part of this blog where as per config VRRP will protect us against Default gateway failure on Master Router so that EU clients can always have access to remote Internet destinations. Now till this stage everything is fine however what will happen in case we lose link to ISP CE-1 from Master router?

In case of link failure, VRRP is still active on Master router and EU client are still getting access to default gateway however they are not able to reach the destinations because link to ISP is down. In these situations, VRRP tracking comes to rescue.

MX104 CEs routers are having Ebgp neighorship with ISP CEs and in turn receiving IPv6 default route only to reach all destinations in Internet.

re1.MX104_CE1> show route logical-system LS2-CLMB receive-protocol bgp 2001:db7:0:8:219:e202:5b5c:805d

inet6.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
 Prefix Nexthop                        MED Lclpref AS path
* ::/0 2001:db7:0:8:219:e202:5b5c:805d             2856 I

re1.MX104_CE2> show route logical-system LS2-Tower receive-protocol bgp 2001:db7:0:4:219:e202:595c:805d

inet6.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
 Prefix Nexthop                        MED Lclpref AS path
* ::/0 2001:db7:0:4:219:e202:595c:805d             2856 I

We will add the following command highlighted in Red on CE1 to track this default route under VRRP so that for any chance if link from Master router to ISP fails, it will drop the VRRP priority by 101 so that ultimately VRRP priority of Master router drops to 99 (200-101) and backup router takes over the role of Master.

family inet6 {
 address 2001:db9::3/64 {
 vrrp-inet6-group 201 {
 virtual-inet6-address 2001:db9::1;
 virtual-link-local-address fe80:db9::1;
 priority 200;
 accept-data;
 track {
 route ::/0 routing-instance default priority-cost 101;
 }
 }
 }
 address fe80:db9::3/64;
 }

Lets see this in action.

To simulate the failure, we will disable the CE1 outgoing interface towards ISP

[edit]
re1.MX104_CE1# set logical-systems LS2-CLMB interfaces ge-0/0/6.601 disable

[edit]
re1.MX104_CE1# commit
re1:
configuration check succeeds
re0:
commit complete
re1:
commit complete

Now you can see no default-route is being learned from the ebgp neighbour.

re1.MX104_CE1> show route logical-system LS2-CLMB receive-protocol bgp 2001:db7:0:8:219:e202:5b5c:805d

inet6.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

However default route is still available from other ebgp neighbour and it is good if Master ship is switched over!!!

re1.MX104_CE2> show route logical-system LS2-Tower receive-protocol bgp 2001:db7:0:4:219:e202:595c:805d

inet6.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
 Prefix Nexthop                          MED Lclpref AS path
* ::/0 2001:db7:0:4:219:e202:595c:805d              2856 I

And as we expected, you can see VRRP state has gone into Backup state on CE1 and Master on CE2.

re1.MX104_CE1> show vrrp summary logical-system LS2-CLMB
Interface State Group VR state VR Mode Type Address
xe-2/0/3.601 up 201 backup Active lcl 2001:db9::3
                                  vip fe80:db9::1
                                  vip 2001:db9::1

re1.MX104_CE2> show vrrp summary logical-system LS2-Tower
Interface State Group VR state VR Mode Type Address
xe-2/0/1.601 up 201 master Active lcl 2001:db9::2
                                  vip fe80:db9::1
                                  vip 2001:db9::1

re1.MX104_CE1> show vrrp track logical-system LS2-CLMB
Track route State Cost Interface    Group Cfg Run VR State
::/0        down  101  xe-2/0/3.601 201 200 99 backup

Lets see extensive command output as well:

re1.MX104_CE1> show vrrp extensive logical-system LS2-CLMB
.
.
Physical interface: xe-2/0/3, Unit: 601, Vlan-id: 601, Address: 2001:db9::3/64
 Index: 358, SNMP ifIndex: 611, VRRP-Traps: enabled, VRRP-Version: 2
 Interface state: up, Group: 201, State: backup, VRRP Mode: Active
 Priority: 99, Advertisement interval: 1, Authentication type: none
 Advertisement threshold: 3, Computed send rate: 0
 Preempt: yes, Accept-data mode: yes, VIP count: 2, VIP: fe80:db9::1, 2001:db9::1
 Dead timer: 2.907s, Master priority: 100, Master router: fe80:db9::2
 Virtual router uptime: 2d 03:45
 Tracking: enabled
 Current priority: 99, Configured priority: 200
 Priority hold time: disabled
 Interface tracking: disabled
 Route tracking: enabled, Route count: 1
 Route VRF name Route state Priority cost
 ::/0 default down 101
 
re1.MX104_CE2> show vrrp extensive logical-system LS2-Tower
.
.
Physical interface: xe-2/0/1, Unit: 601, Vlan-id: 601, Address: 2001:db9::2/64
 Index: 354, SNMP ifIndex: 607, VRRP-Traps: enabled, VRRP-Version: 2
 Interface state: up, Group: 201, State: master, VRRP Mode: Active
 Priority: 100, Advertisement interval: 1, Authentication type: none
 Advertisement threshold: 3, Computed send rate: 0
 Preempt: yes, Accept-data mode: yes, VIP count: 2, VIP: fe80:db9::1, 2001:db9::1
 Advertisement Timer: 0.931s, Master router: fe80:db9::2
 Virtual router uptime: 2d 03:45, Master router uptime: 00:01:19
 Virtual Mac: 00:00:5e:00:02:c9

So that’s all in this blog. I hope I was able to clearly define the problem and solution. If you have any comments/feedback on this or any of my previous blogs, do let me know.

Regards

Mohit