Tag Archives: Junos

Juniper JunOS Command Series – 1

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

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

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

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

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

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

MX104>edit
Entering configuration mode

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

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

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

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

Final config is:

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

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

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

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

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

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

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

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

Let’s see it in action.

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

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

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

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

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

Pretty exciting and fast !!! 🙂

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

Let’s see this in action one more time.

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

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


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

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

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

 

Regards

Mohit Mittal

 

 


			

L2VPN using Kompella – Junos

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

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

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

L2VPN Kompella

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

For BGP based L2VPNs, following configuration needs to be configured

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

Let’s start with Juniper l2vpn configuration.

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

BGP neighborship between M10i and one of the RR.

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

BGP neighborship between M10i and one of the RR.

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

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

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

Fairly simple configuration which is using encapsulation vlan-ccc.

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

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

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

In same way we will be configuring the MX960 PE

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

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

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

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

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

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

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

So this completes our BGP control signalling path.

L2VPN connection state is up between both PEs

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

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

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

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

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

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

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

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

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

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

Formula to calculate VPN label is

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

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

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

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

So as per our equation above,

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

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

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

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

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

 

Regards

Mohit Mittal


eBGP using IPv6 in Juniper JunOS

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

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.

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