Tag Archives: service-provider

IPv6 and Junos – VRRPv3

Reading Time: 5 minutes

With the Christmas season coming up, changes and the current course of projection slow down, so this is the perfect time to start messing around in the lab with things I wouldn’t normally get the chance to do. One thing I know will be happening in the future (but not the near future) on my work network is IPv6. We run IPv6 in the Internet Core however, it’s not to be seen anywhere else on the network, and I’ve heard they’re pushing hard to get IPv6 into our hosting datacentres. With this in mind, and having time to kill, it would be good to be proactive and start looking at how IPv6 and Junos work together!

From looking at the hosting and enterprise (a small bit of enterprise) network, I had a chat with a few of the seniors and we came up with list of things that we were most likely to be used on the network, and we agreed would be the best things to test:

Routing and Switching Features

  • VRRPv3
  • BGP
  • ACL
  • Virtual Routers (VRFs)
  • IGPs (OSPFv3, Static Routes & IS-IS)
  • SLAAC (Router Advertisements)
  • DHCPv6
  • Multicasting

Firewall Features

  • NAT64 / DNS64
  • Security Policies

Of course this list isn’t the be-all or end-all however, for now it’s a good base to get me started and from there we’ll see what happens next. Where I can, I’ll be mostly using IPv6 only, but there are a few features where I’ll have dual stacked setup as it will be good ‘real world’ testing! So with all that talk and explanation out of the way…. Let’s get cracking 😀

The first protocol on my list: Virtual Router Redundancy Protocol (VRRP). I’ve previously wrote a post on how to configure VRRP between Cisco and Juniper Switch, if you take look at that post it defines what VRRP is and why you would you use it within your network. When working with IPv6 (or in Dual Stacked environment) on the other hand you will need to make sure that we are using VRRPv3. VRRPv3 supports both IPv4 and IPv6 and can be defined best in RFC5798 for what the main advantages of VRRPv3:

The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.

For this test, I’ll have a similar topology as my other VRRP post, but I’ll be using 2x Juniper EX4200 switches and I’ll have ESXi Ubuntu 14.04LTS host configured with active-backup bond; the 2 physical NICs were connected into each switch.

VRRPv3 Topology

VRRP Configuration

Firstly will need to enable VRRPv3. By default VRRPv3 isn’t enabled and VRRPv2 doesn’t support inet6, you will need to have this enabled and is done under protocol vrrp stanza. In addition, as IPv6 doesn’t use Address Resolution Protocol (ARP) for Link Layer Discovery, we need to enable the IPv6 version of ARP, Neighbor Discovery Protocol (NDP). This will allow Neighbor Discoveries (ND) to be sent out to Host and other Network devices with that subnet with are needed to VRRPv3 to work affectively.

NOTE
For about IPv6 NDP check out RFC4861

ND is set under protocol router-advertisement stanza, and the logical interface set.

{master:0}[edit protocols]
[email protected]# show 
router-advertisement {
    interface vlan.100 {
        prefix 2001:192:168:1::/64;
}
vrrp {
    version-3;
}

Just like with VRRPv2 you will need to set the entire configuration under the interface stanza whether you have vlan or on physical interface. It is very important to note that you will need to manually set the link-local address on the interface and set a virtual link-local address (these both will need to in the same subnet) without these you will not be able to commit the configuration.

VRRP MasterVRRP Backup
{master:0}[edit interfaces vlan unit 100]
[email protected]# show 
family inet6 {
    address 2001:192:168:1::2/64 {
        vrrp-inet6-group 1 {
            virtual-inet6-address 2001:192:168:1::1;
            virtual-link-local-address fe80:192:168:1::1;
            priority 200;
            preempt;
            accept-data;
        }
    }
    address fe80:192:168:1::2/64;
}
{master:0}[edit interfaces vlan]
[email protected]# show 
unit 100 {
    family inet6 {
        address 2001:192:168:1::3/64 {
            vrrp-inet6-group 1 {
                virtual-inet6-address 2001:192:168:1::1;
                virtual-link-local-address fe80:192:168:1::1;
                priority 100;
                no-preempt;
                accept-data;
            }
        }
        address fe80:192:168:1::3/64;
    }
}

VRRP Verification

Depending on the level of detail you want to go into, you can run any of these commands show vrrp summary, show vrrp detail or show vrrp extensive. I checked both the Master and Backup to make sure everything was expected and differences between the two, by using show vvrp detail.

VRRP Master show vrrp detailVRRP Backup show vrrp detail
[email protected]> show vrrp detail    
Physical interface: vlan, Unit: 100, Address: 2001:192:168:1::2/64
  Index: 72, SNMP ifIndex: 709, VRRP-Traps: disabled, VRRP-Version: 3
  Interface state: up, Group: 1, 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:192:168:1::1, 2001:192:168:1::1
  Advertisement Timer: 0.530s, Master router: fe80:192:168:1::2
  Virtual router uptime: 00:00:20, Master router uptime: 00:00:17
  Virtual Mac: 00:00:5e:00:02:01 
  Tracking: disabled

[email protected]> show vrrp detail 
Physical interface: vlan, Unit: 100, Address: 2001:192:168:1::3/64
  Index: 72, SNMP ifIndex: 709, VRRP-Traps: disabled, VRRP-Version: 3
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 100, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: no, Accept-data mode: yes, VIP count: 2, VIP: fe80:192:168:1::1, 2001:192:168:1::1
  Dead timer: 3.244s, Master priority: 200, Master router: fe80:192:168:1::2 
  Virtual router uptime: 00:00:28
  Tracking: disabled 

In addition, we can confirm that, from the VRRP Master, we are receiving ND’s from the ESXi host as we can see an entry when we run the command show ipv6 neighbors

[email protected]> show ipv6 neighbors 
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
2001:192:168:1::3            cc:e1:7f:2b:82:81  stale       776 yes no      vlan.100    
2001:192:168:1::4            00:0c:29:d3:ac:77  stale       1070 no no      vlan.100   
fe80::20c:29ff:fed3:ac77     00:0c:29:d3:ac:77  stale       673 no  no      vlan.100    
fe80::20c:29ff:fed3:ac81     00:0c:29:d3:ac:81  stale       588 no  no      vlan.100    
fe80:192:168:1::3            cc:e1:7f:2b:82:81  stale       776 yes no      vlan.100

Failover Testing

Before testing the VRRP fail over, I enabled VRRP traceoptions on the master and backup, so that we will be able to see what’s happening under the bonnet. I found the logs from the backup were much simpler to understand compared to master however, on the master you were able to see what the VRRP daemon goes through the process of gaining mastership.

{master:0}[edit protocols vrrp]
[email protected]# show 
traceoptions {
    file vrrp.backup.log;
    flag all;
}

For the failover, the link down to the host and trunk link on the master were deactivated and from the logs on the VRRP Backup, we can see that VRRP daemon had received the vrrpd_process_ppmd_packet notifying that the VRRP master adjacency had gone down and then received another update ppmd_vrrp_delete_adj to remove the link-local address of the VRRP master and transition to become the VRRP Master.

Apr  2 14:43:03 vrrpd_process_ppmd_packet : PPMP_PACKET_ADJ_DOWN received
Apr  2 14:43:03 vrrpd_update_state_machine, vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state: backup
Apr  2 14:43:03 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: transition
Apr  2 14:43:03 vrrp_fsm_transition: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: backup
Apr  2 14:43:03 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: transition
Apr  2 14:43:03 ppmd_vrrp_delete_adj : VRRP neighbour fe80:192:168:1::2 on interface <72 1 1> deleted
Apr  2 14:43:03 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: master
Apr  2 14:43:03 vrrp_fsm_active: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: transition
Apr  2 14:43:03 VRRPD_NEW_MASTER: Interface vlan.100 (local address 2001:192:168:1::3) became VRRP master for group 1 with master reason masterNoResponse
Apr  2 14:43:03 vrrpd_construct_pdu if: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001, checksum flag 0, checksum 17650
Apr  2 14:43:03 vrrpd_ppmd_program_send : Creating XMIT on IFL 72, Group 1, Distributed 0, enabled 1
Apr  2 14:43:03 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: master

When preempt has been configured on the Master, the two interfaces were reactivated, and it automatically takes over as VRRP Master. As we can see from the logs on the original backup switch, another vrrpd_process_ppmd_packet notification was received by the switch and the switch automatically transitions back to become VRRP Backup.

Apr  2 14:44:00 vrrpd_process_ppmd_packet : PPMP_PACKET_RECEIVE received
Apr  2 14:44:00 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: backup
Apr  2 14:44:00 vrrp_fsm_backup: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: master
Apr  2 14:44:00 VRRPD_NEW_BACKUP: Interface vlan.100 (local address 2001:192:168:1::3) became VRRP backup for group 1
Apr  2 14:44:00 vrrpd_construct_pdu if: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001, checksum flag 0, checksum 17650
Apr  2 14:44:00 vrrpd_ppmd_program_send : Creating XMIT on IFL 72, Group 1, Distributed 0, enabled 0
Apr  2 14:44:00 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: backup
Apr  2 14:44:00 Signalled dcd (PID 1225) to reconfig
Apr  2 14:44:00 ppmd_vrrp_set_adj : Created adjacency for neighbor fe80:192:168:1::2 on interface <72 1 1> with hold-time <3 609000000>, Distributed 0
Apr  2 14:44:00 ppmd_vrrp_program_send : Programmed periodic send on interface <72 1 1> with enabled = 0, Distribute = 0, MASTER RE = 1
Apr  2 14:44:00 vrrpd_rts_async_ifa_msg, Received Async message for: (null) index: 72, family 0x1c op: 0x3 address : 2001:192:168:1::1
Apr  2 14:44:00 vrrpd_rts_async_ifa_msg, Received Async message for: (null) index: 72, family 0x1c op: 0x3 address : fe80:192:168:1::1
Apr  2 14:44:00 vrrpd_rts_async_ifl_msg, Received Async message for: vlan index: 72, flags 0xc000 op: 0x2
Apr  2 14:44:00 vrrpd_if_find_by_ifname_internal, Found vlan.000.100: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 in run 1
Apr  2 14:44:00 vrrpd_find_track_if_entry_array_by_name: vlan.100

In addition, you can check to see how many transitional changes were made by using the show vrrp extensive command:

[email protected]> show vrrp extensive | match Backup 
    Idle to backup transitions               :4         
    Backup to master transitions             :4         
    Master to backup transitions             :0

From the host point of view, I had a rolling ping going to gateway during the failover testing and the results were as expected.

--- 2001:192:168:1::1 ping statistics ---
123 packets transmitted, 95 received, 22% packet loss, time 122275ms
rtt min/avg/max/mdev = 1.058/96.186/3257.648/494.372 ms, pipe 4

Although you see packet loss, this is normal due to the bond type (active-backup) and one of the two NICs was unavailable. In addition, the connectivity never completely dropped out and having a host running on 50% capacity is better than a host with no accessibility.

The full logs and ping6 outputs are available here: vrrp.master.log, vrrp.backup.log, ping6.

VRRPv3 has very similar configuration to VRRPv2 but it took me a while to work out that without small differences, i.e. enabling router-advertisement and version-3 , you could be looking at the screen scratching your head! And with that we’ve got another post in the books. Keep an eye for future posts on IPv6 and Junos 🙂

Share this:
Share

Configuring a Virtual Chassis on QFX5100

Reading Time: 2 minutes

When configuring a 2 member Virtual Chassis using 2xQFX5100, there is a slight difference compared to EX Series but it’s very much similar. As this is the case, I thought I’d do a quick post (And it doubles up as documentation writing for work lol). The QFX doesn’t have dedicated VC ports or a VC module, so with this in mind you’ll have to use either 10GB SPF+ port(s) or 40GB QSFP(s) ports to connect the switches together. The method is same as Configuring Virtual Chassis on EX switch using VCEP ports, the one difference is that with the QFX you can do the entire configuration with the VCEP port pre-connected, but this wasn’t the case with EX Series. However, similarly, it’s recommended that you have Backup Routing Engine (RE) or Linecard powered off if you’re using the preprovisioned method like I am 🙂

Let’s get cracking 😀

In one of my previous post, Configuring Virtual Chassis on Juniper EX Series, it’s recommended that you have the following commands set before processing with configuring a Virtual Chassis:

set system commit synchronize
set chassis redundancy graceful-switchover
set routing-options nonstop-routing
set protocols layer2-control nonstop-bridging
Note
The QFX non-bridging command is under the protocols layer2-control stanza NOT ethernet-switching-options stanza as on the EX Series

Once these have been committed, you can configure the virtual-chassis stanza.

[email protected]> show configuration virtual-chassis | display set 
set virtual-chassis preprovisioned
set virtual-chassis no-split-detection
set virtual-chassis member 0 role routing-engine
set virtual-chassis member 0 serial-number TA3715110057
set virtual-chassis member 1 role routing-engine
set virtual-chassis member 1 serial-number TA3715110028

Just like on EX Series, you have to set the VC-Ports on the Master Routing Engine for them to know those ports are being used as the Virtual Chassis interconnects

[email protected]> request virtual-chassis vc-port set pic-slot 0 port 48 
[email protected]> request virtual-chassis vc-port set pic-slot 0 port 50

You can power up (the Backup RE), having completed the entire configuration on the Master RE. Once the Backup has booted, as done on the Master, you have to set the 40GB QSFPs ports as the VC-Ports

[email protected]> request virtual-chassis vc-port set pic-slot 0 port 48 
[email protected]> request virtual-chassis vc-port set pic-slot 0 port 50

Once this is done, the Virtual Chassis is created and you’ll be kicked out of the Backup RE and will have to log back into the switch, where you will be logged into the Master Routing Engine. To verify that everything is working as expected you can run the commands show virtual-chassis vc-port and show virtual-chassis

show virtual-chassis vc-portshow virtual-chassis
[email protected]> show virtual-chassis vc-port    
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
0/48        Configured          5    Up           40000        1   vcp-255/0/48
0/50        Configured          5    Up           40000        1   vcp-255/0/50

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
0/48        Configured          5    Up           40000        0   vcp-255/0/48
0/50        Configured          5    Up           40000        0   vcp-255/0/50
[email protected]> show virtual-chassis 

Preprovisioned Virtual Chassis
Virtual Chassis ID: 1165.24bd.5581
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    TA3715110057 qfx5100-48s-6q 129   Master*      N  VC   1  vcp-255/0/48
                                                                           1  vcp-255/0/50
1 (FPC 1)  Prsnt    TA3715110028 qfx5100-48s-6q 129   Backup       N  VC   0  vcp-255/0/48
                                                                           0  vcp-255/0/50

And you’re done! As I said, it’s very similar to configuring a Virtual Chassis on EX Series, except for a couple of small changes that could throw someone off if they didn’t know!

For more in-depth detail you can check Juniper’s TechLibrary page

Share this:
Share

Configuring BGP using Bird on Ubuntu 14.04LTS

Reading Time: 3 minutes

As part of the QFX testing I’ve been doing at work, I’ve had to do the testing of running BGP between a switch and server. Although one of my seniors advised I could just test BGP between two switches, as BGP is BGP, and should work whether it’s a switch or server, the protocol is the same and should simply work. However, given the chance to learn something new, I went with it and thought this would be the perfect chance for a new post! I found out that our production servers use EXaBGP daemon. I looked into the configuration and the specs for EXaBGP…. Let just say was pretty lost very quickly (being polite)! I then started looking into alternative daemons and found BIRD. I had heard of BIRD before and from my research it didn’t look as complex as EXaBGP.

The BIRD project was developed as a school project at the Faculty of Mathematics and Physics at Charles University in Prague, with major contributions from developers Martin Mares, Pavel Machek, Ondrej Zajicek, Libor Forst and Ondrej Filip. Designed for a UNIX based system, BIRD is an open source daemon that runs an Internet protocol suite. It can run a number of Dynamic Routing Protocols: BGP, OSPF, RIP, Static Routing, Both IPv4 and IPv6 and can hold Multiple Routing Tables.

I had found a perfect post from mindless.gr that went into detail on how to configure a simple IPv4/IPv6 BGP session using BIRD, which was exactly what I needed.

With that in mind, this post will detail how to configure a simple IPv4 BGP session using BIRD on Ubuntu 14.04LTS

Let’s get Cracking 😛

You will need sudo and root privileges

You will be able to make the changes here with sudo privileges. You need to install the BIRD package, which is nicely available via Ubuntu’s Advanced Packaging Tool apt-get install bird

[email protected]:~$ apt-get install bird6

By default any modern Linux distribution will have IP Forwarding disabled; we’ll need the server to basically act as a router and we’ll need to have IP Forwarding enabled. Running the command sysctl net.ipv4.ip_forward=1 will enable IPv4 forwarding. You can also make this a permanent change so that on boot, IP forwarding will always been enabled. You will need to edit /etc/sysctl.conf file. Check below for what you need to look out for and uncomment:

[email protected]:~$ cat /etc/sysctl.conf
{...}
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1
{...}

Backup the original bird.conf by running something like cp bird.conf bird.old.conf (always need to cover your ass :p lol)

The config file looks quite complex at first appearance (when this was written I didn’t have a clue about any of it!!). If you want more detailed information about the config file and the different options available you can find them on the Bird Internet Routing Daemon: User’s Guide Page

For my example, I needed a simple configuration that had the server advertise 4 routes (3 x /24 and /22) and accept all routes. This was the same setup on the switch side, which is a Juniper QFX5100.

To edit the bird.conf file, you’ll need it to be root. I tried a sudo nano however I got Permission Denied! So I sudo -s down to root and edited the conf file

[email protected]:~$ sudo -s
[sudo] password for marquk01: 
[email protected]:~# nano /etc/bird/bird.conf
Bird.confSwitch Configuration
[email protected]:~$ sudo cat /etc/bird/bird.conf
[sudo] password for marquk01: 
/*
 *	This is an example configuration file.
 */

# Yes, even shell-like comments work...

# Configure logging
log syslog all;

# Override router ID
router id 192.31.1.3;

# This pseudo-protocol performs synchronization between BIRD's routing
# tables and the kernel. If your kernel supports multiple routing tables
# (as Linux 2.2.x does), you can run multiple instances of the kernel
# protocol and synchronize different kernel tables with different BIRD tables.
protocol kernel {
#	learn;			# Learn all alien routes from the kernel
	persist;		# Don't remove routes on bird shutdown
	scan time 20;		# Scan kernel routing table every 20 seconds
#	import none;		# Default is import all
	export all;		# Default is export none
#	kernel table 5;		# Kernel table to synchronize with (default: main)
}

# This pseudo-protocol watches all interface up/down events.
protocol device {
	scan time 10;		# Scan interfaces every 10 seconds
}

# Static routes (again, there can be multiple instances, so that you
# can disable/enable various groups of static routes on the fly).
protocol static static_bgp {
	route 192.70.0.0:255.255.252.0 via 192.31.1.3;
	route 192.70.1.0:255.255.255.0 via 192.31.1.3;
	route 192.70.1.0:255.255.255.0 via 192.31.1.3;
	route 192.70.2.0:255.255.255.0 via 192.31.1.3;
	route 192.70.3.0:255.255.255.0 via 192.31.1.3;
}

#BGP Configuration
protocol bgp {
        import all;
        export where proto = "static_bgp";

        local as 3000;
        neighbor 192.31.1.2 as 4000;
}
set interfaces xe-0/0/4 description "km-vm3 10GB"
set interfaces xe-0/0/4 enable
set interfaces xe-0/0/4 unit 0 family inet address 192.31.1.2/31
set routing-options static route 192.69.0.0/24 reject
set routing-options static route 192.69.1.0/24 reject
set routing-options static route 192.69.2.0/24 reject
set routing-options static route 192.69.3.0/24 reject
set routing-options autonomous-system 4000
set protocols bgp enable
set protocols bgp local-as 4000
set protocols bgp group test local-address 192.31.1.2
set protocols bgp group test family inet unicast
set protocols bgp group test neighbor 192.31.1.3 export BGP-Export
set protocols bgp group test neighbor 192.31.1.3 peer-as 3000
set policy-options policy-statement BGP-Export from protocol static
set policy-options policy-statement BGP-Export then accept

Having configured the switch and the server, I needed to enable to the bird daemon. This was done by running the command invoke-rc.d bird start

[email protected]:~$ invoke-rc.d bird start

To enter the bird client, you will need to run the command birdc and from there you’re able to run a verification command to check that routes are being advertised and received from server to the switch.

[email protected]:~$ sudo birdc
[sudo] password for marquk01: 
BIRD 1.4.0 ready.
bird>

From the bird client, you can run show route to see the RIB table and to check the BGP status you will run show protocols all bgp1

show routeshow protocols all bgp1
bird> show route 
192.69.0.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.1.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.2.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.3.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.70.0.0/22      via 192.31.1.3 on eth1 [static_bgp 13:50:05] ! (200)
192.70.1.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
192.70.2.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
192.70.3.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
bird> show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     11:35:14    Established   
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  (unnamed)
  Routes:         4 imported, 4 exported, 4 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              4          0          0          0          4
    Import withdraws:            0          0        ---          0          0
    Export updates:              9          4          0        ---          5
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 192.31.1.2
    Neighbor AS:      4000
    Neighbor ID:      10.1.0.241
    Neighbor caps:    refresh AS4
    Session:          external AS4
    Source address:   192.31.1.3
    Hold timer:       52/90
    Keepalive timer:  18/30

On the switch, we can check when the BGP session is up and can see what routes that are being adverted and what routes are being received:

show bgp summaryshow route advertising-protocol bgpshow route receive-protocol bgp
{master:0}
[email protected]> show bgp summary group test    
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       4          4          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.31.1.3             3000         79         79       0       1       33:43 4/4/4/0              0/0/0/0
{master:0}
[email protected]> show route advertising-protocol bgp 192.31.1.3

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 192.69.0.0/24           Self                                    I
* 192.69.1.0/24           Self                                    I
* 192.69.2.0/24           Self                                    I
* 192.69.3.0/24           Self                                    I
{master:0}
[email protected]> show route receive-protocol bgp 192.31.1.3                                                          

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 192.70.0.0/22           192.31.1.3                              3000 I
* 192.70.1.0/24           192.31.1.3                              3000 I
* 192.70.2.0/24           192.31.1.3                              3000 I
* 192.70.3.0/24           192.31.1.3                              3000 I

You can enable BIRD for IPv6 as well. The editing and process is exactly the same however you’ll need to edit the /etc/bird/bird6.conf file with the appropriate IPv6 addressing. To enter the IPv6 BIRD client you’ll use the command birdc6.

Being able to spin up VMs and have them configured as “dumb” BGP nodes is such a useful thing to have in a lab when you don’t have as many switches/routers as you need. From what I can see Bird can be a extremely useful tool for connecting BGP routes and I see that many Internet Exchange Points (IXPs) such as London Internet Exchange (LINX), London Network Access Point (LONAP), Deutscher Commercial Internet Exchange (DE-CIX), Amsterdam Internet Exchange (AMS-IX) and many more use BIRD for their Route Server. When I get a chance I will defiantly look into how to get the most out of BIRD!

You can find all the documentation and user guides on BIRD on the official website here

Share this:
Share

Configuring Virtual Private LAN Service

Reading Time: 4 minutes

As normal on a Friday, it’s a bit of slow day at work 😐 but it does give me the chance to mess about in the lab! We were talking about the VPLS instances that we have going at in the office and I had never configured it up for myself, so I thought this would be the perfect time to set something up and give it a punt!

This post is just about how to configure a VPLS instance. I will write another post going into the inner working of VPLS, however right now I know and understand how it VPLS works but couldn’t explain it!

So that is for future, but for the today…. Let’s begin 😀

I will be using 1x EX4200 with routing instances to separate the routing tables and 3x SRX220h2 as the Provider Edge (PE) routers. I will have 3 routing instances on the EX4200, each will represent a different Site location and will have a single VPLS instances across the 3x PE routers. As shown below, Logical Topology that will be used for this VPLS lab will be:

To have create a VPLS instance you will need to have the following configured:

IGP – On all PE and P routers, with traffic-engineering enabled
MPLS – You will need Label Switched Paths (LSPs) configured between the PE routers
BGP – You will need BGP configured between the PE routers (BGP enabling VPLS method)

This is my base configuration for my 3 PE routers

Base configuration
PE Router 1PE router 2PE router 3
[email protected]_SRX> show configuration 
## Last commit: 2015-05-15 15:47:03 UTC by root
version 12.1X44-D45.2;
system {
    host-name Top_SRX;
    root-authentication {
        encrypted-password "$1$n8lY2iyW$5gx34QuELucAjscTH.vTe1"; ## SECRET-DATA
    }
    services {
        ssh {
            protocol-version v2;
        }
    }
}
interfaces {
    ge-0/0/0 {
        description "Other SRX g0/0/0";
        enable;
        unit 0 {
            family inet {
                address 1.1.1.6/31;
        }
    }
    ge-0/0/1 {
        description "Bottom SRX g0/0/1";
        unit 0 {
            family inet {
                address 1.1.1.4/31;
        }        
    }
    ge-0/0/2 {
        description "EX g0/0/2";
    }
    ge-0/0/6 {
        enable;
        unit 0 {
            family inet {
                address 10.1.0.201/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 1.1.1.1/32;
            }                           
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 {
            next-hop 10.1.0.1;
            no-readvertise;
        }
    }
    autonomous-system 200;
}
protocols {
    lldp {                              
        interface all;
    }
security {
    forwarding-options {
        family {
            inet6 {
                mode packet-based;
            }
            mpls {
                mode packet-based;
            }
            iso {
                mode packet-based;
            }
        }
    }
}
[email protected]> show configuration 
## Last commit: 2015-05-15 15:56:47 UTC by root
version 12.1X44-D45.2;
system {
    host-name BottomSRX;
    root-authentication {
        encrypted-password "$1$8zJP2rqE$aNbSmTjuldkr99uQIp4J30"; ## SECRET-DATA
    }
    services {
        ssh {
            protocol-version v2;
        }
    }
}
interfaces {
    ge-0/0/0 {
        description "Other SRX g0/0/1";
        unit 0 {
            family inet {
                address 1.1.1.9/31;
            }
    }
    ge-0/0/1 {
        description "Top SRX g0/0/1";
        unit 0 {
            family inet {
                address 1.1.1.5/31;
            }                           
    }
    ge-0/0/2 {
        description "EX g0/0/2";
    }
    ge-0/0/6 {
        enable;
        unit 0 {
            family inet {
                address 10.1.0.202/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 2.2.2.2/32;
            }
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 {
            next-hop 10.1.0.1;          
            no-readvertise;
        }
    }
}
protocols {
    lldp {                              
        interface all;
    }
}
security {
    forwarding-options {
        family {
            inet6 {
                mode packet-based;
            }                           
            mpls {
                mode packet-based;
            }
            iso {
                mode packet-based;
            }
        }
    }
}
[email protected]_SRX> show configuration 
## Last commit: 2015-05-15 16:03:13 UTC by root
version 12.1X44-D45.2;
system {
    host-name Single_SRX;
    root-authentication {
        encrypted-password "$1$0pm5C2Ie$5ss3qkj8WZxBFU2bTwlyE."; ## SECRET-DATA
    }
    name-server {
        8.8.8.8;
        8.8.4.4;
    }
    services {
        ssh {
            protocol-version v2;
        }
    }
}
interfaces {
    ge-0/0/0 {
        description "Bottom SRX g0/0/0";
        enable;
        unit 0 {
            family inet {
                address 1.1.1.8/31;
        }
    }
    ge-0/0/1 {
        description "Top SRX g0/0/0";
        enable;
        unit 0 {
            family inet {
                address 1.1.1.7/31;
        }
    }
    ge-0/0/2 {  
    	description "EX SRX g0/0/2";                        
    }
    ge-0/0/7 {
        description "Lab Management";
        enable;
        unit 0 {
            family inet {
                address 10.1.0.207/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 3.3.3.3/32;
            }
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 {
            next-hop 10.1.0.1;
            no-readvertise;
        }
    }
    autonomous-system 200;
}
protocols {
    lldp {                              
        interface all;
    }
}
security {
    forwarding-options {
        family {
            inet6 {
                mode packet-based;
            }
            mpls {
                mode packet-based;
            }
            iso {
                mode packet-based;
            }
        }
    }
}
routing-instances {
    vpls {
        instance-type vpls;
        interface ge-0/0/2.0;
        protocols {
            vpls {
                no-tunnel-services;
                vpls-id 1;
                neighbor 1.1.1.1;
                neighbor 2.2.2.2;
            }
        }
    }
}

This is the configuration I have on the EX4200, which will be used as the 3 different locations. I have enabled OSPF at the each of the sites

EX4200 Configuration
root> show configuration 
## Last commit: 2015-03-08 18:33:10 UTC by root
version 12.3R9.4;
system {
    root-authentication {
        encrypted-password "$1$kgkXgKFb$plTKQqiKNknDciGKJ8i8V/"; ## SECRET-DATA
    }
    services {
        ssh {
            protocol-version v2;
        }
    }
}
interfaces {
    ge-0/0/0 {
        description "Top SRX";
        unit 0 {
            family inet {
                address 172.16.1.4/24;
            }
        }
    }
    ge-0/0/1 {
        description "Bottom SRX";
        unit 0 {                        
            family inet {               
                address 172.16.1.2/24;
            }
        }
    }
    ge-0/0/2 {
        description "Other SRX";
        unit 0 {
            family inet {
                address 172.16.1.3/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 7.7.7.7/32;
            }
        }
        unit 1 {
            family inet {
                address 8.8.8.8/32;
            }
        }                               
        unit 2 {
            family inet {
                address 9.9.9.9/32;
            }
        }
    }
    me0 {
        unit 0 {
            family inet {
                address 10.1.0.200/24;
            }
        }
    }
}
protocols {
    lldp {
        interface all;
    }
}
routing-instances {
    SiteA {
        instance-type virtual-router;
        interface ge-0/0/0.0;           
        interface lo0.0;
        protocols {
            ospf {
                area 0.0.0.0 {
                    interface ge-0/0/0.0;
                    interface lo0.0;
                }
            }
        }
    }
    SiteB {
        instance-type virtual-router;
        interface ge-0/0/1.0;
        interface lo0.1;
        protocols {
            ospf {
                area 0.0.0.0 {
                    interface ge-0/0/1.0;
                    interface lo0.1;
                }
            }
        }
    }                                   
    SiteC {
        instance-type virtual-router;
        interface ge-0/0/2.0;
        interface lo0.2;
        protocols {
            ospf {
                area 0.0.0.0 {
                    interface lo0.2;
                    interface ge-0/0/2.0;
                }
            }
        }
    }
}

LDP

Ill be working off PE1, all the other routers have been configured. Once we have PE1 sorted, we will have a VPLS instance with LDP signaling 🙂

Firstly, I will configure the interface that is connected the Customer Edge (CE) device, so that the router knows this is apart of the VPLS. We will need to set the encapsulation to VPLS and set the logical interface.

[email protected]_SRX> show configuration interfaces ge-0/0/2                        
description "EX g0/0/2";
encapsulation ethernet-vpls;
unit 0;

Out of the 3 ways of configuring a VPLS instance using LDP, configuration wise, is the most straightforward. Under the protocols stanza, we will need to make sure all the related protocols are enabled, in addition we will need to make sure the MPLS LSPs correctly configured. It is important to know that, you will only need to set LDP on the loopback address not on any other interfaces that has MPLS configured. This is because the LDP peering with only the other PE and not the interlinks between the routers, this is also why you need to have an IGP configured to get connectivity to the loopback.

protocols {
    rsvp {
        interface ge-0/0/0.0;
        interface ge-0/0/1.0;
        interface lo0.0;
    }
    mpls {
        no-cspf;
        label-switched-path to_3.3.3.3 {
            from 1.1.1.1;
            to 3.3.3.3;
        }
        label-switched-path to_2.2.2.2 {
            from 1.1.1.1;
            to 2.2.2.2;
        }
        interface ge-0/0/0.0;
        interface ge-0/0/1.0;
    }
    ospf {
        traffic-engineering;
        area 0.0.0.0 {
            interface ge-0/0/0.0;
            interface ge-0/0/1.0;
            interface lo0.0;
        }                               
    }
    ldp {
        interface lo0.0;
    }

It is key to remember with all VPNs, their goal is to isolate their routing tables from other networks; this is no different with VPLS. We will need to create an isolated VPLS instance, to allow traffic between Sites A, B and C to be independent from the rest of the network. With this in mind, we will need to configure a Routing-Instance and include statement instance-type vpls

[email protected]_SRX> show configuration routing-instances 
vpls {
    instance-type vpls;
    interface ge-0/0/2.0;
    protocols {
        vpls {
            no-tunnel-services;
Note
no-tunnel-services needs to be configured, as device I’m using (SRX220h2) doesn’t have Tunnel Service PIC. This statement creates a label-switched interface (LSI) to provide VPLS functionality. For more information check here

We can see everything is working, when I do a show route we can see that all 3 sites have learnt the loopback address via OSPF

Site A Routing TableSite B Routing TableSite C Routing Table
SiteA.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[Direct/0] 17:54:17
                    > via lo0.0
8.8.8.8/32         *[OSPF/10] 01:05:51, metric 1
                    > to 172.16.1.2 via ge-0/0/0.0
9.9.9.9/32         *[OSPF/10] 01:05:51, metric 1
                    > to 172.16.1.3 via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 17:54:17, metric 1
                      MultiRecv
SiteB.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 01:05:51, metric 1
                    > to 172.16.1.4 via ge-0/0/1.0
8.8.8.8/32         *[Direct/0] 17:54:17
                    > via lo0.1
9.9.9.9/32         *[OSPF/10] 01:05:56, metric 1
                    > to 172.16.1.3 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 17:54:17, metric 1
                      MultiRecv
SiteC.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 01:05:51, metric 1
                    > to 172.16.1.4 via ge-0/0/2.0
8.8.8.8/32         *[OSPF/10] 01:05:56, metric 1
                    > to 172.16.1.2 via ge-0/0/2.0
9.9.9.9/32         *[Direct/0] 17:54:17
                    > via lo0.2
224.0.0.5/32       *[OSPF/10] 17:54:17, metric 1
                      MultiRecv

BGP

Time to move onto the BGP version of configuration a VPLS. We will keep the same configuration above keep on the all the PEs. Using BGP configuration for VPLS is extremely useful as if more scalable and if you already have BGP running on your network, you don’t need to create any new BGP sessions for the VPLS session!

Firstly we will need to set the autonomous system (AS) number and have our BGP peering session with the other PEs. Note that we have selected the family l2vpn signaling

[edit]
[email protected]_SRX# show routing-options autonomous-system 
200;

[edit]
[email protected]_SRX# show protocols bgp 
group PE-routers {
    type internal;
    local-address 1.1.1.1;
    family l2vpn {
        signaling;
    }
    peer-as 200;
    neighbor 2.2.2.2;
    neighbor 3.3.3.3;
}

As similar with L3VPNs, under the VPLS routing-instance, we will need to add Route-Target and Route-Distinguisher. This is because unlike with we used LDP, we don’t have defined neighbor under the VPLS stanza. Additionally under the VPLS protocol site-identifiers have to be added.

Note
The Route-Target and Route-Distinguisher on all the PEs in the VPLS instance have to be same
[edit routing-instances vpls]
[email protected]_SRX# show 
instance-type vpls;
interface ge-0/0/2.0;
route-distinguisher 200:100;
vrf-target target:200:100;
protocols {
    vpls {
        no-tunnel-services;
        site SiteC {
            site-identifier 3;
        }
    }
}

We can see everything is working, when I do a show route we can see that all 3 sites have learnt the loopback address via OSPF still 😀

Site A Routing TableSite B Routing TableSite C Routing Table
SiteA.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[OSPF/10] 00:02:11, metric 1
                    > to 172.16.1.2 via ge-0/0/0.0
9.9.9.9/32         *[OSPF/10] 00:02:16, metric 1
                    > to 172.16.1.3 via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 22:38:49, metric 1
                      MultiRecv
SiteB.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 00:02:11, metric 1
                    > to 172.16.1.4 via ge-0/0/1.0
9.9.9.9/32         *[OSPF/10] 00:02:11, metric 1
                    > to 172.16.1.3 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 22:38:49, metric 1
                      MultiRecv
SiteC.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 00:02:16, metric 1
                    > to 172.16.1.4 via ge-0/0/2.0
8.8.8.8/32         *[OSPF/10] 00:02:11, metric 1
                    > to 172.16.1.2 via ge-0/0/2.0
224.0.0.5/32       *[OSPF/10] 22:38:49, metric 1
                      MultiRecv

LDP & BGP

We are also able to configure a VPLS instance with LDP and BGP. We will use the same configure as above, as we will only need a few changes. We will need to change the family l2vpn stanza in the BGP session from signaling to auto-discovery-only, add l2vpn-id and remove the entire configuration under the protocol vpls (except no-tunnel-services) stanza in VPLS routing instance.

[email protected]_SRX# show protocols bgp  
group PE-routers {
    type internal;
    local-address 1.1.1.1;
    family l2vpn {
        auto-discovery-only;
    }
    peer-as 200;
    neighbor 2.2.2.2;
    neighbor 3.3.3.3;
}


[email protected]_SRX# show routing-instances vpls 
instance-type vpls;
interface ge-0/0/2.0;
route-distinguisher 200:100;
l2vpn-id l2vpn-id:200:100;
vrf-target target:200:100;
protocols {
    vpls {
        no-tunnel-services;
    }
}

We can see everything is working, when I do a show route protocol ospf we can see that all 3 sites have learnt the loopback address via OSPF still 😀

Site A OSPF Routing TableSite B OSPF Routing TableSite C OSPF Routing Table
SiteA.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[OSPF/10] 00:00:18, metric 1
                    > to 172.16.1.2 via ge-0/0/0.0
9.9.9.9/32         *[OSPF/10] 00:00:18, metric 1
                    > to 172.16.1.3 via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 23:48:35, metric 1
                      MultiRecv
SiteB.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 00:00:18, metric 1
                    > to 172.16.1.4 via ge-0/0/1.0
9.9.9.9/32         *[OSPF/10] 00:00:23, metric 1
                    > to 172.16.1.3 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 23:48:35, metric 1
                      MultiRecv
SiteC.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[OSPF/10] 00:00:18, metric 1
                    > to 172.16.1.4 via ge-0/0/2.0
8.8.8.8/32         *[OSPF/10] 00:00:23, metric 1
                    > to 172.16.1.2 via ge-0/0/2.0
224.0.0.5/32       *[OSPF/10] 23:48:35, metric 1
                      MultiRecv

You can get indepth detail about VPLS from Juniper Website here

Share this:
Share