Category Archives: Networking

Missing Interfaces in

2000px-Former_Ubuntu_logo.svg

Have you have ever been in a situation (typically in a virtualised environment) where you have added another network adapter & it didn’t seem to appear in Ubuntu? In the following example, I added a second interface, however it didn’t just simply appear. The following is this issue was resolved.

~$ ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.115.199 netmask 255.255.255.0 broadcast 192.168.115.255
inet6 fe80::250:56ff:fe9c:a2df prefixlen 64 scopeid 0x20<link>
ether 00:50:56:9c:a2:df txqueuelen 1000 (Ethernet)
RX packets 2846 bytes 359600 (359.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 159 bytes 18009 (18.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 358 bytes 26926 (26.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 358 bytes 26926 (26.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

As you can see in the ‘ifconfig’ output, there is no additional ethernet interface. So lets use the command ‘ip link’

~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:9c:a2:df brd ff:ff:ff:ff:ff:ff
3: ens192: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:50:56:9c:56:c4 brd ff:ff:ff:ff:ff:ff

You can see that there is in fact an additional interface, however it hasn’t been configured yet. So lets use nano to edit the interfaces file and add it.

~$ sudo nano /etc/network/interfaces

 

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens160
iface ens160 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.0
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
auto ens192
iface ens192 inet dhcp

We add the additional information underlined in this example, exit & save, then we need to restart the network service

~$ sudo systemctl restart networking

Be warned, if you are logged into the server via SSH, your connection will drop, as you’re restarting the whole networking service. Run the ‘ifconfig’ command again to verify that you have your new interface.

~$ ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.115.199 netmask 255.255.255.0 broadcast 192.168.115.255
inet6 fe80::250:56ff:fe9c:a2df prefixlen 64 scopeid 0x20<link>
ether 00:50:56:9c:a2:df txqueuelen 1000 (Ethernet)
RX packets 622 bytes 74509 (74.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 79 bytes 10801 (10.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::250:56ff:fe9c:56c4 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:9c:56:c4 txqueuelen 1000 (Ethernet)
RX packets 25 bytes 4043 (4.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19 bytes 2897 (2.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 367 bytes 27739 (27.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 367 bytes 27739 (27.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

As we can see by the output, we now have the new interface.

 

Advertisements

Avaya ACE-Fx

url

This week I took the Avaya ACE-Fx 5 day course & exam (7501C). The course is made up of 4 days with two exams, a lab (7582X) & a theory / written exam (7590X) both on the 5th day. Simply passing the theory exam will earn you an Avaya ‘ACIS’ certification. In addition to passing theory, once you successfully complete the lab exam you have completed ACE-Fx Part 1 & are then ACE-Fx certified. But only for 2 years, then you will need to re-certify or complete Part 2 (7502C). What do I mean by Part 2 you may be asking.. Well I was asking the same question. It seems that Part 1 covers the basics of Fabric Connect, Fabric Attach & a bit of Fabric Extend. Part 2 goes for a deeper dive on those topics, along with specialised topics, such as complex multicast deployments.

All that to say that I passed & was quite pleased with the result. 100% on the lab & 88% on the theory.

 

Avaya Fabric Connect !!!

imgresurl

Anyone who knows me will know I’m pretty excited about what Avaya are doing with the IEEE 802.1aq standard “Shortest Path Bridging”. Avaya’s implementation is called “Fabric Connect”. I’ll be discussing my real world use case of Fabric Connect while I work through my next project, which is an all Avaya deployment in a high definition broadcast environment. Essentially Avaya is replacing an existing all Cisco infrastructure as the business needs for high bandwidth multicast rises well above email, web & SQL traffic. For now, please check out the Packet Pushers podcasts & view these videos from previous Network Field Day’s during their visit to Avaya for briefings on SPB & Fabric Connect.

Show 136: Avaya – Considerations for Turning your Network into an Ethernet Fabric

Show 147 – Avaya Fabric Connect Makes Multicast Simple (Really)

Show 158 – Avaya – Software Defined Data Centre & Fabric Connect

Show 179 – Avaya Efficient Data Center Design at Fujitsu & the Sochi 2014 Winter Games

Show 202 – Avaya & The Critical Importance of the SDN Underlay

Show 204 – Reducing Your Attack Surface with Avaya Stealth Networks

Juniper Virtual Chassis (over Ethernet) on EX series switches

ex4500-left

Recently while working on a Juniper deployment, I configured three EX4500’s in a Virtual-Chassis configuration as the (temporary) distributed core of a temporary network for an event. I’ve detailed an easy configuration to get VC up and running using any of the 40x 10G interfaces. This allows you to use the appropriate optics and spread your switches over longer distances, be it at only 10G per link, however multiple links are supported natively on virtual chassis ethernet ports, so no need to configure link aggregation. The method I used this time is known as Nonprovisioned. This means that nodes can dynamically join & leave the VC stack.

Configure the SFP / SFP+ ports to be used as Virtual Chassis Ethernet Ports (VCEP). In my case I had two ports linking each switch in a triangle topology. *This command is issued in Operation Mode. Apply this to all switches operating in the VC stack.

> request virtual-chassis vc-port set pic-slot 0 port 36

> request virtual-chassis vc-port set pic-slot 0 port 37

> request virtual-chassis vc-port set pic-slot 0 port 38

> request virtual-chassis vc-port set pic-slot 0 port 39

Verify your port configurations at any time.

> show virtual-chassis vc-port

Choose the VC member that you would like to use as your Master Routing Engine (RE).

# set member 0 mastership-priority 255

Choose the VC member that you would like to use as your Back-Up RE (BK RE)

# set member 1 mastership-priority 250

Then configure the remaining switches as Line Cards (LC)

# set member 2 mastership-priority 128

Juniper has a great document explaining in more detail about configuring the mastership priority here if your looking for more information.

Now connect the switches once you have committed the configuration on each node. Once all the switches have established links, issue the following command to verify your Virtual Chassis configuration. The CLI output will be fairly obvious if your virtual chassis stack is running.

> show virtual-chassis

Set a virtual management interface for the VC stack. This will be available from any MGMT interface on any switch in your stack.

# set interfaces vme unit 0 family inet address 10.0.0.1/24

Remember to commit, however once you have established a virtual chassis, you will want to use the commit synchronize command to make sure all nodes commit the configuration change.

# commit synchronize

If your topology is like mine was, with only 2 – 3 switches acting as the core, high availability, fail-over speed & constant connectivity is critical. You may want to use the following command to guarantee the behavior of split detection. For more information regarding this, check Junipers documentation here.

# set virtual-chassis no-split-detection

# commit synchronize

To save typing commit synchronize every time in the future (as well as mistakes), there is an option to set the standard commit command to always synchronize across all nodes.

# set system commit synchronize

# commit synchronize   (for the last time)

Configuring Link Aggregation (LACP) on Juniper EX series switches

imgres

After spending some time on Juniper switches, you quickly become familiar with the Junos operating system. Its very different to Cisco IOS/XE/XR or Arista EOS in that it uses hierarchical CLI structure. Very easy to read through a configuration. Heres how simple the configuration is to group a pair of ports into a link aggregation (LACP) bundle.

First, tell the switch how many aggregate ethernet interfaces are required.

#set chassis aggregated0devices ethernet device-count 1

Then configure the interfaces that you want to be part of the LACP bundle, which is known as ‘ae0’.

#set interface xe-1/0/0 ether-options 802.1ad ae0

#set interface xe-1/0/1 ether-options 802.1ad ae0

Configure the LACP mode on the new aggregate ethernet interface

#set interface ae0 aggregated-ether-options lacp active

#set interface ae0 aggregated-ether-options lacp periodic fast

Now configure the port mode of you new aggregated ethernet interface.

#set interface ae0 unit 0 family ethernet-switching port mode trunk vlan members all

And don’t forget to commit (or commit check).

#commit 

Use the following command to check the status of the ae interfaces

>show lacp interfaces

Tagged , , ,

Upgrading Junos (via USB) on Juniper EX series switches

juniper-ex4500

Very recently I have been working on a few Juniper EX4500 & EX4200 series switches. Wanting to configure them into a distributed Virtual Chassis arrangement, I needed to upgrade Junos from 10.3 to 12.3. Quickest and easiest way was to simply drop the jinstall-ex-xx.tgz file onto a freshly (FAT) formatted USB thumb drives & plug them straight into each switch.

The following syntax is whats required to mount the USB drive, copy junos to the switch & perform the upgrade. Once in the shell, you will need to create a path.

#mkdir /mnt/usb

Now mount the the USB device to the path

#mount -t msdosfs /dev/da1s1 /mnt/usb

Copy the Junos install package over to the switch

#cp /mnt/usb/jinstall-ex-4500-12.3R9.4-domestic-signed.tgz /var/tmp

Unmount the USB

#umount /mnt/usb

Now enter the Command Line Interface

#cli

At the CLI prompt, enter the following to start the upgrade along with the instruction to reboot.

>request system software add /var/tmp/jinstall-ex-4500-12.3R9.4-domestic-signed.tgz reboot

Once the switch has rebooted, it will ask you to log in. Run a command to show the version to confirm the upgrade was successful.

>show system software

Introduction to A/V over ethernet networks

In this string of blog posts i’ll be discussing the latest generations of concept, standards & protocols being deployed by A/V vendors to simplify & lower the costs of infrastructure with the use of standards based (IEEE 802.3) ethernet & IP. I will be writing more specifically about vendors specific protocols, but in doing so, will also aim to educate the community on the basic subjects of ethernet & IP. I’ll be using tools like Wireshark to capture the traffic & dissect the ethernet frames to further learn more about the protocols used.

The starting vendors proprietary protocol will be Audinate’s Dante, at the same time we’ll look at the basics of the OSI model, layer 1 (physical), layer 2 (data link), layer 3 (network), unicast vs multicast, UDP & TCP packets along the way. Hardware will also be discussed as each hardware vendors implementation of these proprietary protocols differs slightly to allow for certain functionality within a closed system.