Configurations

Route Summarization for the ERS8600

As networks grow in size the routing tables on each router grows as well. As a result the overhead to process the routes can grow exponentially and take resources away from other functions the router can be performing. As well, large routing tables can be difficult to read quickly, efficiently and troubleshoot. You can make your life extremely easy if you engineer your IP addressing using an harmonious numbering system and avoid using a discontinuous network address scheme. If you adhere to these methods and use CIDR addresses you can also take advantage of Route Summarization (aka Route Aggregation)

An example of a route summariztion would be: If you have an ASBR that manages five 24bit networks.

172.16.0.1/24
172.16.1.1/24
172.16.2.1/24
172.16.3.1/24
172.16.4.1/24

In a neighbouring router’s table, these networks will be listed as attached networks with a next hop and value. And each route will be advertised to the LSDB. We can reduce the amount of advertisements by summerizing these 5 networks on the ASBR as one large Network so the neighbouring router will only receive one advertisement. This is accomplished by using a CIDR mask length that will encompass the entire range of the 5 example networks.

The five networks listed above consist of the range 172.16.0.1 – 172.16.4.255. This can be summarized as 172.16.0.0/21 or 172.16.0.0/255.255.248.0

To accomplish this you will need to understand CIDR, VLSM, IP, and binary Math.  The best site I have found that explains the math behind the calculations is.  http://subnettingmadeeasy.blogspot.com/2007/11/router-summarization.html note: the author of this article makes some great observations on how summarizing your routes can cause issues. He also describes some great work arounds.

or if you are like me. You can use an online calculator. The best one I have found is http://buchananweb.co.uk/security51.aspx

An ERS8600 CLI example of the route summary described above would look like this.

ip ospf admin-state enable
ip ospf router-id 172.16.0.0
ip ospf enable
ip ospf area 0.0.0.1 create
ip ospf area 0.0.0.1 range 172.16.0.0/255.255.248.0 create advertise-mode summarize lsa-type summary-link advertise-metric 10
OSPF RIP BGP Nortel Lab -v1

Interconnecting Avaya(Nortel) OSPF and RIP Network Devices.

It is a safe assumption that most “greenfield” networks are built using OSPF. But a time could come when you have to add a RIP network device to your OSPF network.  In the Nortel/Avaya world this case could be true if you have an existing OSPF Network consisting of ERS8600′s and you wish to add an ERS5500, ERS4500 or a legacy Cisco Device. Should this requirement arise you will need to research OSPF Redistribute functions. OSPF Redistribute configurations will accept external routes from devices running different routing protocols into the OSPF domain at the ASBR.

The Setup
In the scenario I have built for you I have three ERS8600′s participating in a simple OSPF area. Each ERS8600 has two vlans, as well as two BRouter ports configured as the OSPF Broadcast interfaces.  The BRouter ports act as the interconnections for the three routers.  The fourth router added to the network is an ERS5510. The ERS5510 only supports RIP so it will be connected to Router #3 because Router #3 will assume the role of the ASBR for the OSPF Area. The role of the ASBR is important because it will be the router that will manage of the RIP routes from the ERS5510 and will need to be configured according with the appropriate routing Redistribute policies.

The Configuration

ERS8600#3 BRouter Port Config

ethernet 1/5 ip create 192.168.13.1/255.255.255.0 13 mac_offset 4

ERS5510 BRouter Port Config

brouter port 1 vlan 13 subnet 192.168.13.2/24

ERS8600#3 OSPF Config

ip ospf admin-state enable
ip ospf as-boundary-router enable
ip ospf router-id 172.16.5.1
ip ospf enable

ERS8600#3 RIP Config

ip ospf redistribute rip create
ip ospf redistribute rip metric 10
ip ospf redistribute rip enable
ethernet 1/5 ip rip enable

ERS8600#3 Route Policy

ip route-policy "to other domain" seq 1 create
ip route-policy "to other domain" seq 1 enable
ip route-policy "to other domain" seq 1 action permit
ip route-policy "to other domain" seq 1 match-protocol local|static|ospf
ip route-policy "to other domain" seq 1 set-metric 10
ip rip interface  192.168.13.1 out-policy "to other domain"

ERS8600#3 OSPF Redistribute Function.

ip ospf redistribute rip create
ip ospf redistribute rip metric 10
ip ospf redistribute rip enable

Outcome
Now that Router#3 is configured as the ASBR and configured to accept the RIP routes from the 5510 the two vlans on the 5510 will be visible to the other devices in the OSPF area.

Telnet ACL Based On Network Source

This is something quick and easy if you wish to limit Telnet access based on network source.

The Setup:
On one Avaya ERS8600 I have the management interface configured for a 192.168.1.0/24 network.
I have the native Vlan1 configured as a mock user network with the address 10.10.10.0/24.
The goal is to only grant Telnet access to users that are from the 192.168.1.0 network.

The Configuration:
You will be configuring two policies and then enabling access policies globally. Policy #2 will be the “allow” policy specifying the telnet service and the allowed network. Policy #3 will be the “deny” equivalent for the user network. Note that you can not delete the native policy #1.

sys access-policy enable true
sys access-policy policy 1 service http disable
sys access-policy policy 1 service ssh disable
sys access-policy policy 1 service telnet disable
sys access-policy policy 2 create
sys access-policy policy 2 accesslevel rwa
sys access-policy policy 2 access-strict true
sys access-policy policy 2 name "allow telnet"
sys access-policy policy 2 username ""
sys access-policy policy 2 network 192.168.1.0/24
sys access-policy policy 2 service snmpv3 enable
sys access-policy policy 2 service telnet enable
sys access-policy policy 3 create
sys access-policy policy 3 accesslevel rwa
sys access-policy policy 3 access-strict true
sys access-policy policy 3 mode deny
sys access-policy policy 3 name "telnet  deny"
sys access-policy policy 3 precedence 11
sys access-policy policy 3 username ""
sys access-policy policy 3 network 10.10.10.0/24
sys access-policy policy 3 service telnet enable

Outcome:
Any attempt to login with telnet from the user network 10.10.10.0 is instantly dropped by the 8600 an the event is recorded into the log.

vyatta_lab

Vyatta Core v6.1 Evaluation: Home Router Replacement

Late last year I was researching for platforms to experiment with so I can improve my networking security, NAT, firewall, load balancing, routing interoperability, IPv6 and VPN skill sets. So my search began for a Nortel Contivity router, a Cisco PIX/ASA and a Nortel Alteon 2424. All expensive options. But during my research I stumbled across Vyatta. A Free, open source router and firewall solution that utilizes a standard PCx86 hardware platform. With nothing to lose I downloaded the ISO image, burnt the CD and dusted off an eight year old PC and three 3Com PCI NICs I had laying around. After a quick install of the hardware and the Vyatta software I now had a fully functional 4 port Vyatta v6.1 Core router added into my lab.

To test my new Vyatta router I configured it to replace my Linksys WRT54G home router. It would be an exercise to test the simplicity, ease of use of the Vyatta CLI and to learn some additional key networking principles. It would also double as a functional test because I was loosing faith in my linksys router. To add a small level of complexity to my experiment I added a second vlan on the inside LAN and URL filtering.(see image)

Vyatta Configuration Checklist.

IP interfaces / VLANs

DHCP interface to receive address from TeleCo.

DHCP pools for inside hosts.

NAT

Web filtering

Telnet enabling

Observations and Conclusions:

I was able to research, design, configure and validate the PCx86 router configuration in less than 60 minutes.  Much less time than I expected it would take. The online resources are amazing. Between the Vyatta user forum, the Vyatta documentation (which is spectacular), other blogs and DIY youtube videos you can probably accomplish anything you want with this platform.  I had no hardware issues during the install and initial configuration. I was using an old ASUS AMD 1.67GHz system with 512mb of ram. The router software had no issue discovering the on-board NIC. For the other NICs Vyatta recommends using 10/100 3com PCI nics “the older the better”. Lucky for us PCI NICs grow on trees and you can buy them used online for under $5 each.

The biggest learning curve was learning the new CLI syntax and figuring out that you can’t “Tab key” to complete phrases.  The CLI itself is adequate but not as easy to use as you would find on a Cisco or Avaya/Nortel device. The CLI does have an “Open and Close” bracket structure that is a little annoying to look at. This became more of an annoyance as the complexity of my configuration grew. It sometimes became difficult to make sense of what I was looking at.  It is much cleaner to read if you export it, (see below)

As for value, v6.1 Core is free and the cost of my system is under $40. And the fact that you can configure IP routing (RIP, OSPF, BGP), IPv6, NAT, Stateful Firewalls, URL filtering, VPN, Load-balancing and QoS makes it very attractive.  I would certainly recommend the Core v6.1 platform for the home networking user, hobbyist, and the extremely small business owner.  I am impressed with my initial trial and will certainly continue to experiment with the product’s other features and blog again.

 

here is my final configuration that I used to replace my Linksys home router.

eth0 is the WAN interface.

eth1 and 2 are the inside LANs with their dedicated DHCP pools.

As well,  I experimented with blocking and allowing Webmail, Porn, gaming sites, facebook etc etc.

vyatta@vyatta:~$ show configuration
interfaces {
ethernet eth0 {
address dhcp
duplex auto
hw-id 00:0e:a6:a4:05:f1
smp_affinity auto
speed auto
}
ethernet eth1 {
address 192.168.2.1/24
duplex auto
hw-id 00:60:08:16:a8:0f
smp_affinity auto
speed auto
}
ethernet eth2 {
address 10.10.10.1/24
duplex auto
hw-id 00:a0:24:cb:7a:32
smp_affinity auto
speed auto
}
ethernet eth3 {
duplex auto
hw-id 00:50:ba:c6:be:34
smp_affinity auto
speed auto
}
loopback lo {
}
}
service {
dhcp-server {
disabled false
shared-network-name POOL1 {
authoritative disable
subnet 192.168.2.0/24 {
default-router 192.168.2.1
dns-server 192.168.2.1
domain-name Leroux.local1
lease 86400
start 192.168.2.50 {
stop 192.168.2.200
}
}
}
shared-network-name POOL2 {
authoritative disable
subnet 10.10.10.0/24 {
default-router 10.10.10.1
dns-server 10.10.10.1
lease 86400
start 10.10.10.105 {
stop 10.10.10.200
}
}
}
}
dns {
forwarding {
cache-size 150
listen-on eth1
listen-on eth2
name-server 8.8.8.8
name-server 8.8.8.4
}
}
nat {
rule 10 {
outbound-interface eth0
source {
address 192.168.2.0/24
}
type masquerade
}
rule 20 {
outbound-interface eth0
source {
address 10.10.10.0/24
}
type masquerade
}
}
telnet {
allow-root
port 23
}
webproxy {
cache-size 100
default-port 3128
listen-address 192.168.2.1 {
}
url-filtering {
squidguard {
allow-category webmail
auto-update {
update-hour 23
}
block-category malware
block-category porn
block-category warez
block-category proxy
block-category games
default-action allow
local-block facebook.com
local-block yahoo.com
local-block-url facebook.com
redirect-url http://www.google.com
}
}
}
}
system {
host-name vyatta
login {
user vyatta {
authentication {
encrypted-password ****************
}
level admin
}
}
ntp-server 0.vyatta.pool.ntp.org
package {
auto-sync 1
repository community {
components main
distribution stable
password ****************
url http://packages.vyatta.com/vyatta
username ""
}
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone GMT
}
vyatta@vyatta:~$

SSH for the Avaya ERS8600

SSH is a protocol developed to address the inherent weakness within Telnet.  Telnet of course transfers all information and passwords in plaintext, that can be captured and reconstituted by anyone who is sniffing on your network.  SSH enabled devices will offer you that extra layer of security within your network and will protect you from IP Spoofing, DNS Spoofing, TCP hijacking attacks, and password sniffing. This is accomplished by enhanced authentication and encryption that SSH provides.

Before you begin enabling SSH on your ERS 8600 you will require the following.

Please note: For my experiment I used a 8603 chassis with a 8691/256SF running v4.1.8.5

1- Nortel/Avaya console cable. Avaya recommends that you perform this configuration at the local console.
2- The 3DES image file copied to the flash of the Switch Fabric.  “p80c4XXX.img”
3- A maintenance window because you are required to re-boot the switch.

So lets begin……………….

***First you must disable the SSH Daemon, SNMP, rlogin, tftp, ftp, and telnet. Once that is complete you must load the 3DES encryption module.

config bootconfig flags sshd false
config bootconfig flags block-snmp true
config bootconfig flags rlogind false
config bootconfig flags telnetd false
config bootconfig flags ftpd false
config load-encryption-module 3DES

Once the services listed above have been disabled we will now re-enable the SSH Daemon, save the bootconfig, and ****reboot the switch.

config bootconfig flags sshd true
save bootconfig
boot -y

Upon reboot, log back into the switch. This series of commands will create a basic SSH server on your ERS8600.
NOTE: These are default settings.

config sys set ssh action rsa-keygen 1024
config sys set ssh action dsa-keygen 1024
config sys set ssh dsa-auth true
config sys set ssh max-sessions 4
config sys set ssh pass-auth true
config sys set ssh port 22
config sys set ssh rsa-auth true
config sys set ssh timeout 60
config sys set ssh version v2only
config sys set ssh enable true
config sys set ssh info
save config.

Verify your work: The following command will show you the current SSH settings on your ERS8600

show sys ssh global|session

You will soon notice that you can no longer utilize your normal Telnet and SNMP tools to manage your switch. Supported SSH clients you can use are Tera Term Pro and OpenSSH. Other options are PuTTY, and of course CLImanager.

References and Further Reading.
- http://forums.networkinfrastructure.info/ Mike’s Nortel/Avaya user form.
Nortel Ethernet Routing Switch 8600: Configuring and Managing Security NN46205-601

***UPDATE: As per Mike’s comments below. You are not required to disable SNMP, TFTP, FTP, Rlogin and Telnet.  They are the recommendations I gleaned from the NN46205-601 Guide
***** Mike has also brought it to my attention that a reboot is not required. But it is recommended by Nortel/Avaya

lock

Securing Your ERS8600: Disable Unused Accounts

When working with any network device a good Network Engineer understands how dangerous default settings can be. Especially when it comes to local and remote access.  Once a device has been powered on for the first time it has become an instinct for many to configure new telnet passwords, configure ssh, disable SNMP and configure SNMPv3 accounts. When an engineer wants to harden a device even further an Engineer can also consider changing user-names, creating access lists, using strong passwords or even configuring a RADIUS or TACACS solution. But all of this effort can be for not if a little door is left open.

For the ERS8600, the Management Access Control is the little back door. Every ERS8600 has 12 levels of access, each with their own default user-name and password. Each access-level has varying levels of controls and visibility from read only to full access. But to prying eyes even a little bit of information can cascade into further problems for any Network Engineer that wants to maintain a secure network. The access-levels are as follows; l1, l2, l3, l4admin, l4oper, oper, ro, rw, rwa, slbadmin, slboper, ssladmin. The weakness with each access-level is that for each access-level the default password string is the user-name.

The description for each access-level and the access they grant are:

Read only:  This level lets you view the device settings, but you
cannot change any of the settings.
Layer 1 Read Write: This level lets you view switch configuration and status
information and change only physical port
parameters.
Layer 2 Read Write: This level lets you view and edit device settings
related to Layer 2 (bridging) functionality. The Layer 3
settings (such as OSPF, DHCP) are not accessible.
You cannot change the security and password
settings.
Layer 3 Read Write: This level lets you view and edit device settings
related to Layer 2 (bridging) and Layer 3 (routing). You
cannot change the security and password settings.
Read Write: This level lets you view and edit most device settings.
You cannot change the security and password
Read Write All : This level lets you do everything. You have all the
privileges of read-write access and the ability to
change the security settings. The security settings
include access passwords and the Web-based
management user names and passwords.
ssladmin: This level lets you login to connect to and configure
the SAM (ssl acceleration module).
User, SLB Operator, Layer 4 Operator, Operator: Each one of these access-levles will grant read access if the Web Switching Module is present.

The common Network Engineer will use the Read Write ALL “rwa” account to manage all aspects of the switch exclusively. And in common environments a Read Only “ro” account can be created for technicians. But rarely would someone want to delegate out granular and varying controls of the ERS utilising the other 10 access-levels. The problems this poses are too numerous and obvious to list.

So what are your solutions? You can give each access-level a new password. This can still haunt you if you use weak passwords. Or you can simply disable the unused access-level accounts.

This command, repeated for all access-levels except rwa will disable all remaining access-levels.

Note: this is a hidden command. You can not short type the word “password”

ERS-8603:3/config/cli/password# access-level l1 disable
ERS-8603:3/config/cli/password# access-level l2 disable
ERS-8603:3/config/cli/password# access-level l3 disable
ERS-8603:3/config/cli/password# access-level l4admin disable
ERS-8603:3/config/cli/password# access-level l4oper disable
ERS-8603:3/config/cli/password# access-level oper disable
ERS-8603:3/config/cli/password# access-level ro disable
ERS-8603:3/config/cli/password# access-level rw disable
ERS-8603:3/config/cli/password# access-level slbadmin disable
ERS-8603:3/config/cli/password# access-level slboper disable
ERS-8603:3/config/cli/password# access-level ssladmin disable

In addition to disabling all unused access-levels. You can also set the “hsecure” flag in the bootconfig. This will ensure that all future passwords are over 8 characters in length.

In conclusion. If you have a requirement to hand out varying access-levels make sure that the passwords are strong. And that the technicians with this access have the proper training and understanding of their control. If you have no requirement for the other access-levels other than “rwa”, you can simply save yourself the headache and possible threat of a hack and disable the other accounts.

Pick your tool / Weapon

Ghosts, Goblins, Gremlins, and Bugs: The Joy of Troubleshooting

I set aside my Saturday afternoon to work on my QoS/Diffserv experiments in my lab. I was making all kinds of progress. I was able to …….

-get my two ERS8603′s communicating with each other.
-I was able to configure Diffserv access ports and Diffserv Core ports
-and configure a DSCP filter.

all very basic, but a good refresh before my tests.

Before I moved onto the next step of configuring a IP traffic filter I “fortunately” ran into some issues. Before I continue with the description of my lab problems, I will preface it with acknowledgement that my lab is a completely unsupported environment (as per Nortel). I am running two 8691SF’s, with an unsupported version of v5.1.1 for that switch fabric. And those 8691SF’s are not supported for the ERS8603 chassis running version 4.0 or higher. In actual fact, my hardware configuration would only work with version 3. But I ask you. “what fun is that?”

when I built my lab, I ran all the usual Nortel ERS8600 built-in diagnostic tests to make sure I would not have any serious problems.

test artable|fabric|loopback
sho sys info
sho tech

and everything came back 100 over 100. so I hit the ground running.

But half way through my labs I began to see some problems with my routers.

Pick your tool / Weapon

It would appear that after upgrading my second 8691 to version 5.1.1 I forgot to format-flash the switch fabric. So I backed up all software images and config files, and dos-formated the flash on both routers. After I re-imaged the routers I noticed that they would not let me build or save a new config file. I see the error message, "Licenses.dat missing your trial has expired". I had forgotten to back up the license file, it was now gone for good. With my options limited I had no choice but to downgrade both routers to v4.1.1. This would not be the end of the world, for educational purposes there is nothing in v5 that I can't do in v4. But I ran into more problems after downgrading. My problems became compounded because I forgot to do a dos-format of the switch fabrics after downgrading. It would appear that the 8691 flash is very sensitive to what version it is running and what code version performed the dos-format of the flash. You can't run v4 on a switch fabric that was flashed with v5 and vica versa.

But my problems were not finished there. Unbeknown to me, not only do you have to mindful what version was used to dos-format your flash (v5 or v4). The PCMCIA card is also just as sensitive. My upgrades and downgrades were very eventful because I was downgrading to from v5 to v4, with a PCMCI card that had been built with a v5 switch fabric. It took about an hour to clean up my mess. But as I mentioned above, "I "fortunately" ran into some issues."

I say Fortunately, because I am never going to forget this exercise.

so what did I learn this weekend.

1- always be mindful what version was used to dos-format the flash on the 8691 switch fabric.
2- always be mindful what version was used to format the PCMCIA card used to upgrade or downgrade your switch fabric.
3- when messing around with your v5 software, ALWAYS back up your "licenses.dat" file.

lastly

4- when you are in your lab working problems, there is no such thing as wasted time.

slpp-example

SLPP For Medium Sized Enterprise

When it comes to Data Networking, one common problem I encounter when engineering a redundancy solution is “the technology can sometimes be its own worst enemy”.

This can be said for Avaya’s Multi Link Trunk (MLT & DMLT) and Split Multi Link Trunk (SMLT). Both technologies are extremely robust ways of providing link redundancy and increased throughput by utilizing an aggregated group of multiple links. All links participating in the MLT/SMLT are none blocking and completely load balanced between a core switch (or dual core in a SMLT configuration) and an edge switch.

The single deficiency of MLT/SMLT is the redundancy it provides does not protect your network against Layer 2 broadcast storms. In-fact the MLT itself could be the root cause of the broadcast storm. In a MLT/SMLT configured network a layer 2 network loop can be initiated in many scenarios. But these are the common three.

1- An edge switch rebooting with a default configuration.
2- MLT misconfiguration on an edge switch.
3- Improper port allocation when connecting the edge switch to the core switch.

Scenarios 2 and 3 are both “layer 8” issues and can happen to anyone at anytime. Fortunately Avaya has released SLPP with version 4.1 and above for ERS 8600. How SLPP works and what environments it can be implemented in has been well documents in Avaya’s “Small Campus Technical Solution Guide” and “Switch Clustering using Split Multi-Link Trunking (SMLT) with ERS 8600, 8300, 5500 and 1600 Series Technical Configuration Guide”.

The one curious thing about SLPP is that all of Avaya’s documentation only depict it in a dual ERS8600 core IST/SMLT Switch Cluster configuration. ERS8600#1 would have a unique SLPP configuration, and the connecting ERS8600#2 would have the supporting SLPP configuration. So I thought to myself, “could SLPP work in a single core MLT or DMLT configuration”. So with that thought in my mind, I tested out a few topologies in my lab.

What I was able to configure was the same SLPP ERS8600#1 and #2 configuration on a single ERS8600 by envisioning the I/O modules of a single ERS8600 as the two ERS8600#1 and #2.

ERS-8603:3/config/sys# slpp add 1
ERS-8603:3/config/sys# slpp operation en
ERS-8603:3/config/ethernet/1/1# slpp packet-rx en
ERS-8603:3/config/ethernet/1/1# slpp packet-rx-threshold 5

on the same ERS8603, the secondary slpp packet-rx-threshold config is configured on the second half of the DMLT port on module 2.

ERS-8603:3/config/ethernet/2/1# slpp packet-rx en
ERS-8603:3/config/ethernet/2/1# slpp packet-rx-threshold 500

In this scenario because SLPP is configured on a single ERS8600, a loop at the edge will take down both ports of the DMLT.

ERS-8603:3/show/ports/info# state
================================================================================
Port State
================================================================================
PORT NUM   ADMINSTATUS  PORTSTATE   REASON     DATE
--------------------------------------------------------------------------------
1/1        up           down        SLPP       07/25/10 22:18:42
2/1        up           down        SLPP       07/25/10 22:18:42

Ideally, the varying packet-rx-threshold settings on the MLT ports will stagger the disabling of the ports in the event of a MLT failure. So in the perfect case an edge switch will not become isolated because one link will remain enabled. But if the broadcast storm at the edge switch is triggered by a loop at the access port the packet-rx-threshold will be exceeded on all ports of the MLT and both ports will go into a disabled state. This scenario will be undesirable for the services or users connected to that switch. But it’s a sacrifice that would be at the benefit of the rest of the network.

In conclusion, it is possible to implement SLPP in a single ERS8600 configuration. And it is an added ounce of prevention for your network.

Go to Top