Monthly Archives: October 2015

VRRP Between Cisco and Juniper Switches

For one of the many projects that I’ve been assigned at work, I got the chance to join the InfoSec Team and help design and configure their second site for their expanding network. Of course, any network engineer always wants to design and provision a network, they can call his/her own! So we were put on a plane and off to Sunny Glasgow, with a plan of attack and 4 days to get this first phase done.

To say it was a busy few days would be the understatement of the year, long days and nights on the data floor stacking, racking, patching and configuring. We had hard deadline to get everything configured and remotely accessible, so making sure the network was sorted was key! But one good thing was that the data floor was in one of our office buildings and it had a window! Inserts shameless instagram plug!

 

 
For those who haven’t worked in a dedicated datacentre, you wouldn’t understand how great natural light and view can be after 10 hours of work haha
In the end, phase one was completed on time (just), with everything working as expected. Inserts another shameless instagram plug

 


Missing from that post above was a Cisco 3750X that was used for vendor redundancy as part of the network. The guys had a HP c7000 Blade Chassis with 2 HP Virtual Connects Chassis Switches which needed to be connected to the edge switches, a Juniper EX4300 and the Cisco. This meant that I would have to span a vlan across two switches and share a default gateway between them. With this being the case, I had use a First-hop Redundancy Protocol (FHRP) and as I was using a multiple vendor topology, the FHRP of choice would have to be VRRP (Virtual Router Redundancy Protocol).

VRRP is best defined in RFC3768:

The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable.

As VRRP is an open standard, it’s interoperable between both Cisco and Juniper devices. If it were just using Cisco devices, I would have had a choice between VRRP or HSRP (Hot Standby Router Protocol). HSRP works similar as VRRP but it’s a Cisco Proprietary Protocol, which means it’s only compatible between Cisco devices. You can see more detail on HSRP in RFC2281

Due to the upstream routing requirements and the EX4300 being higher specced switch, it was decided that the EX4300 was going to be the Master. The topology I was working with is shown below.

VRRP Topology
With that all explained, Let’s get cracking 😀

Juniper Configuration

Physical Interface ConfigurationIntegrated Routing & Bridging ConfigurationVlan Configuration
xe-0/2/3 {
    description "TRUNK to Edge Cisco";
    enable;
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members reith;
            }
        }
    }
}
irb {
    enable;
    unit 100 {                          
        enable;
        family inet {
            address 10.199.6.1/23 {
                vrrp-group 1 {
                    virtual-address 10.199.7.254;
                    priority 150;
                    no-preempt;
                    accept-data;
                }
            }
        }
    }
}
vlans {
    reith {
        vlan-id 100;
        l3-interface irb.100;
    }
}
Note
With the irb configuration, under the vrrp-group stanza, I had to add the command accept-data. Adding this command it will enable the master router to accept all packets destined for the Virtual IP (VIP) address. If this isn’t enabled when the EX4300 is set/becomes master, it will not respond to any packets sent to the VIP address!

Cisco Configuration

Physical Interface t1/1/2Routed VLAN Interface
egde-cisco#show run int t1/1/2 
Building configuration...

Current configuration : 137 bytes
!
interface TenGigabitEthernet1/1/2
 description "TRUNK to Edge Juniper"
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100
 switchport mode trunk
end
egde-cisco#show run int vlan100
Building configuration...

Current configuration : 176 bytes
!
interface Vlan100
 ip address 10.199.6.2 255.255.254.0
 vrrp 1 description "TRUNK to Edge Juniper"
 vrrp 1 ip 10.199.7.254
 no vrrp 1 preempt
 vrrp 1 priority 145
end

Juniper Verification

Depending on the level of detail you want to go into, you can run of any of these commands show vrrp summary, show vrrp detail or show vrrp extensive. I mostly use show vrrp summary or show vrrp detail as ive found (most of time) that you get want you need from either useless you’ve had a big issue and extensive detail is needed!

Show VRRP SummaryShow VRRP Detail
[email protected]> show vrrp summary     
Interface     State       Group   VR state       VR Mode    Type   Address 
irb.100       up              1   master          Active    lcl    10.199.6.1         
                                                            vip    10.199.7.254
[email protected]> show vrrp detail       
Physical interface: irb, Unit: 100, Address: 10.199.6.1/23
  Index: 547, SNMP ifIndex: 567, VRRP-Traps: disabled, VRRP-Version: 2
  Interface state: up, Group: 1, State: master, VRRP Mode: Active
  Priority: 150, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: no, Accept-data mode: yes, VIP count: 1, VIP: 10.199.7.254       
  Advertisement Timer: 0.064s, Master router: 10.199.6.1
  Virtual router uptime: 19:40:12, Master router uptime: 19:40:04
  Virtual Mac: 00:00:5e:00:01:01 
  Tracking: disabled

Cisco Verification

On a Cisco, you can check VRRP status by running the command show vrrp

egde-cisco#show vrrp 
Vlan100 - Group 1  
"TRUNK to Edge Juniper"
  State is Backup  
  Virtual IP address is 10.199.7.254
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption disabled
  Priority is 145 
  Master Router is 10.199.6.1, priority is 145 
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.433 sec

And with that we are done! Confirmed VRRP is working as expected! To be honest, before getting started I was a little worried that ill be running into plenty of issues running cross vendor but it was pretty straightforward, which is always good when you’re under the gun 🙂

Share this:
Share

Configuring a Virtual Chassis on QFX5100

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

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

marquk01[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