UtilityMPLS.com

Securing MPLS Services - network edge

One question we are often asked — “Is MPLS secure?” and “How should edge security be designed and implemented?”. Obviously there are many ways to accomplish this task and you must first determine your specific security requirements and design a solution to meet your requirements. Not the other way around.

The diagram below shows one way that you could secure your access layer using a firewall located at the network edge. What I like about this solution is that it is highly scalable and additional IP services can be layered on at any time. Provided that your firewalls are centrally managed and you maintain uniform IP service to VLAN tag mappings this architecture allows for uniform security policies per service to be applied across all edge nodes in a simple and straightforward manner.

In this example the firewall operates as a transparent bridges that filters layer 3. I have shown both a VPRN and VPLS in the example, both are provisioned similarly on the 7705 (MPLS Service SAP maps to a unique dot1q tag) and are completely separate and isolated from each other. All virtual router instances (gateways), and network services such as DHCP are provided by the MPLS service and configured on the 7750.

As time permits I’ll post a modified diagram showing the firewalls operating at layer 3.

Cory

3600 Multiplexer (MSBM) going End-of-Life

3600 Mainstreet

After nearly 24 years of telecommunication service, the 3600 multi-service bandwidth manager (MSBM) is going to be discontinued. This comes as ALU ramps up development and production of the newer MPLS platforms – 7750-SR and 7705-SAR. The last date for purchase of the units is December 31, 2010.

During a trip to Kanata, ON in 2009 I saw a beer mug celebrating over 1 million units shipped (from an earlier time when the thought of a beer at the office was not a legal liability). If I’m not mistaken, a total of ~1.5 million units have been shipped so far.

Some very large shoes for MPLS to fill…

Clint

(You need a customer-portal account to login and read the official announcement)

Product Support Documentation Published in the last 7 days (ordered by most current)

09-0975, Discontinuation Notification Mainstreet 275X, 3600, 3600+

Last update date: Jan 5, 2010

Products: NN 27xx MainStreet IDSL Family DTUs, Alcatel-Lucent 3600 MS MSBM, NN 26xx MainStreet DNIC Family DTUs, Alcatel-Lucent 3600 MS MSBM, Alcatel-Lucent 275x MS DTU, Alcatel-Lucent 3600 MS MSBM, Alcatel-Lucent 3600 MS MSBM, Alcatel 2720 MainStreet Internet Termination Unit, Alcatel-Lucent 3600 MS MSBM, Alcatel 2721 MainStreet Router Termination Unit, Alcatel-Lucent 3600+ MS MSBM

Document type: Product Discontinuation Notifications

Happy Holidays / UtilityMPLS.com Update

With the holiday season upon us, Cory and I have taken some R&R time away from the office over the Christmas / New Year break. We will be continuing our work in 2010 as we plan for our field trials and eventual migration to the production network.

Until then however, we have several step in front of us:

On-going training
Order Pilot-phase hardware
5620-SAM server cluster to build
Kick-start official engineering (get the paper done)
Begin planning for equipment staging and base-config.

It will be a busy Q1, 2010 as the above steps start rolling and the project continues to take shape. We’ll post updates as things progress.

Until January – we hope everyone has a safe and happy holiday season.

UtilityMPLS.com (Clint & Cory)

P.S. If you have specific questions you would like to ask Cory or I, please post them in the comments section – We’ll respond and that way everyone can read our answers.

OSPF Point-to-Point Adjacency Formation and Troubleshooting

OSPF is arguably the most popular IGP in use today. It scales well, converges fast and is the IGP of choice within our MPLS network.

With this in mind, this post is #1 of 3 covering how OSPF creates adjacencies first in a point-to-point network, then in a broadcast environment, and finally what are the different LSA types and where they occur within the network.

OSPF Information:

Uses IP Protocol 89 to communicate

OSPF V2 is defined by RFC1853

SPF – Shortest Path First Algorithm=Created by Edsger Djikstra – defined by RFC2328

LSA – Link State Advertisements = OSPF protocol updates.

OSPF uses two multicast groups for flooding LSAs:

AllSPFRouters = 224.0.0.5

ALLDRouters = 224.0.0.6 (only in broadcast environments with DR Routers)

Stages

1 – Initial state, both routers are powered on, OSPF is in the DOWN state.

2 – When the routers send their initial HELLO packets to each other they are in state INIT.

3 – When each router receives the response to the HELLO packet which includes their own system ID they are in 2-WAY.

4 – Once 2-Way is established the routers are ready to exchange their Link State Databases. This state is known at Ex-Start.

5 – While in Ex-Start, both routers send DBD packets (Database Descriptor) to each other and confirm that their MTUs match. A master-slave relationship is also negotiated with the highest router ID becoming the master.

6 – Once the Master is determined, the slave router sends the master a summary list of the routes it knows about. The master then returns the favor and sends its route lists to the slave. At this point the router transitions state from Ex-Start to Loading.

7 – While in the Loading state, routers exchange LSAs to completely describe their link state databases. Once this information exchange is complete each router will have identical Link State Databases and will be considered Fully Adjacent.

OSPF Parameters which must match in order for an Adjacency to be formed.

Area ID Even if only 1 area exists)

Password (only if using MD5 protocol authentication)

Hello Interval (default 10 seconds)

Dead Interval (default 40 seconds – time a router waits without receiving a HELLO before marking a neighbor as down)

MTU (defaults to port MTU if not explicitly specified)

Troubleshooting

If ’show router ospf neighbor’ shows ‘STATE’ as Ex-Start, chances are:

- You have an MTU mismatch on your port configuration

- You have one router set for point-to-point and the other set for Broadcast.

- Areas mismatch.

Up next – Adjacency formation in Broadcast networks.

Cory

7705/7750 MPLS Synchronous Ethernet Configuration (Sync-E)

A less-known feature of the ALU MPLS switches is that they support Synchronous Ethernet on several interfaces. The primary benefit of this in our case, is that timing distribution can happen using already existing Ethernet connections (provided they are the correct type).

Timing distribution with Sync-E (Example)

For an overview of Sync-E and how it works, click here – links courtesy of Wikipedia (there are several more links available on Wiki – go there and do a search if you’re looking for more detailed info).

On the ALU MPLS units Sync-E has a few restrictions. These are as follows:

Only available on later releases of firmware / hardware. (7705 Ethernet card v2)
Must be optical connection – SFP-based (many, but not all SFP’s support Sync-E)
Not supported on Copper connections – these ports use their local oscillator as a reference.
Only one Sync-E capable port / MDA can be used as a sync reference (max of 2 / system)

Supported SFP’s

Part #	Short Description
3HE00027AA	PBA GIGE SX SFP OPTICS MODULE – LC
3HE00028AA	PBA GIGE LX SFP OPTICS MODULE – LC
3HE00867AA	KIT GIGE EX SFP OPTICS MODULE – LC
3HE00029AA	PBA GIGE ZX SFP OPTICS MODULE – LC
3HE01389AA	PBA GIGE ZX SFP OPTICS MODULE – LC
3HE00024AA	PBA 100FX SFP OPTICS MODULE – LC
3HE00266AA	KIT 100FX SFP OPTICS MODULE – SM 24km – L

In our case, we use the 3HE00027AA SFP. This is the basic MMF, Gig-E SFP used for most local connections (if not copper).

To setup sync-e on the 7705-SAR, Sync-E needs to be enabled on the MDA first. Here’s the steps:

Configuring Sync-E on 7705/7750 MPLS nodes

A:7705-A# configure card 1 mda 1
A:7705-A>config>card>mda# sync-e
access          + Configure access MDA parameters
clock-mode      – Configure clock mode and timestamp frequency
[no] fabric-stats-e* – Configure fabric stats for MDA
[no] mda-type        – Provisions/de-provisions an MDA to/from the device configuration for the slot
network         + Configure network MDA parameters
[no] shutdown        – Administratively shut down an mda
[no] sync-e          – Enable/Disable Synchronous Ethernet

This will enable Sync-E on the entire card, making (in the case of the Ethernet card for the 7705) both ports capable of becoming a timing master.

To verify Sync-E is enabled, you can do the following:

Check SYNC-E status on 7705 node (upstream Master) (assuming 7705 -> 7750 downstream)

A:7705-A# show mda 1 detail

===============================================================================
MDA 1/1 detail
===============================================================================
Slot Mda    Provisioned           Equipped              Admin     Operational
Mda-type                Mda-type             State         State
——————————————————————————-
1     1     a8-ethv2              a8-ethv2              up        up

MDA Specific Data
Maximum port count            : 8
Number of ports equipped      : 8
Transmit timing selected      : CPM Card A
Sync interface timing status : Qualified
Network ingress queue policy : default
Network ingress fabric policy : 1
Access ingress fabric policy : 1
Fabric Stats Enabled          : FALSE
Capabilities                  : Ethernet

With Sync-E enabled on the card either of the SFP-based ports, using a capable SFP, can be used as a timing reference. The next step is to configure the timing-slave ports to accept timing from the master port. In our case, a 7750 node is being slaved to the upstream 7705. The connection between the nodes is based on the required SFP/Gig-E link.

A:7750-A# configure card 1 mda 1   [Configure the MDA to enable Sync-E - same as for the 7705.]
A:7750-A>config>card>mda#
access          + Configure access MDA parameters
clock-mode      – Configure clock mode and timestamp frequency
egress          + Configure egress MDA parameters
ingress         + Configure ingress MDA parameters
[no] mda-type        – Provisions/de-provisions an MDA to/from the device
configuration for the slot
network         + Configure network MDA parameters
[no] shutdown        – Administratively shut down an mda
[no] sync-e          – Enable/Disable Synchronous Ethernet

A:7750-A>config>card>mda#

Next the timing ports for the node need to be configured. This is done via configuring the system timing:

A:7750-A# configure system sync-if-timing [Enter the configuration menu for node timing.]
A:7750-A>config>system>sync-if-timing#

A:7750-A>config>system>sync-if-timing# begin [Required to instruct the node to reconfigure timing sources.]
A:7750-A>config>system>sync-if-timing# ref1   [Specify reference source #1]
A:7750-A>config>system>sync-if-timing>ref1#
[no] bits-interface* – Configure the interface type of the BITS timing
reference
[no] shutdown        – Administratively shutdown the timing reference
[no] source-bits     – Configure the source bits for the first timing
reference
[no] source-port     – Configure the source port for the first timing
reference

A:7750-A>config>system>sync-if-timing>ref1# source-port 1/1/2 [Specify the desired port to be used as a timing reference.]
A:7750-A>config>system>sync-if-timing>ref1# back
A:7750-A>config>system>sync-if-timing# revert [ Tell the node to revert back to higher-stratum / performance sources when available.]

A:7750-A>config>system>sync-if-timing# commit [Save sync configuration and make active.]
A:7750-A>config>system>sync-if-timing#

7750 Node (Verify node is taking timing via Sync-E from upstream 7705)

A:7750-A# show system sync-if-timing

===============================================================================
System Interface Timing Operational Info
===============================================================================
System Status CPM A : Master Locked
Reference Input Mode : Revertive
Current Frequency Offset (ppm) : +0

Reference Order : ref1 ref2

Reference Input 1
Admin Status                   : up
Qualified For Use              : Yes
Selected For Use               : Yes
Source Port                    : 1/1/2 [<- this is the important line, as this is an Ethernet port.]

Reference Input 2
Admin Status                   : up
Qualified For Use              : Yes
Selected For Use               : No
Not Selected Due To        :     on standby
Source Port                    : 1/3/1
===============================================================================
A:7750-A#

A:7750-A# show mda 1 detail [You can also type this to check the sync status of the physical port itself.]

The commands to set this up are not complicated, but you need to have a map (obviously larger than the diagram I have shown above) to properly visualize where the nodes are to derive their timing sources. This diagram is imperative to avoid timing distribution loops.

As we verified in the lab, not having timing distribution setup properly will manifest itself in many ways -causing hits or errors that can be very difficult to troubleshoot. We observed random hits and errors on a circuit-emulation service (Rs-232 test circuit) when timing on all nodes was left to local oscillators. Once a master timing node was configured, the errors were eliminated.

More to follow (as always). I’m hoping to get IEEE-1588 configured as soon as my GrandMaster clocks arrive (hopefully by early December).

Clint – November 9, 2009

A:7705-A# configure card 1 mda 1
A:7705-A>config>card>mda#
access          + Configure access MDA parameters
clock-mode      – Configure clock mode and timestamp frequency
[no] fabric-stats-e* – Configure fabric stats for MDA
[no] mda-type        – Provisions/de-provisions an MDA to/from the device
configuration for the slot
network         + Configure network MDA parameters
[no] shutdown        – Administratively shut down an mda
[no] sync-e          – Enable/Disable Synchronous Ethernet

Alcatel 7750 SR Routing Protocol Preferences

When a router is running concurrent instances of different routing protocols it maintains a RIB (Routing Information Base) for each protocol. Each protocol will determine its best route to each destination network and install this into the RIB for that protocol. Since the metrics are different for each protocol, the router must make then decision as to which route(s) learned from which protocol should be installed into the FIB (Forwarding Information Base). The FIB is often referred to as the “Route Table”.

Assuming the destination network is the same length (prefix), the routes learned from the protocol with the lowest preference will be the routes installed in the route table.

All protocols preferences except for directly connected routes can be manually configured. You must make sure to assign a unique preference value to all protocols.

Route Type	Preference (lowest preferred)
Directly Connected	0
Static Route	5
OSPF Internal	10
IS-IS Level 1 Internal	15
IS-IS Level 2 Internal	18
RIP	100
OSPF External	150
IS-IS Level 1 External	160
IS-IS Level 2 External	165
BGP	170

Managing 685X nodes via SNMP

Further to Cory’s recent struggles to manage 6855 switch nodes via SAM, I started working on integrating our many 6855 nodes into a generic SNMP manager. In our case, we use SolarWinds to poll the nodes and generate alerts based on loss of connectivity, high ping latencies, or ports changing status (uplink ports). 6855 router

I started to review the steps Cory identified in his SAM posting earlier, but couldn’t make the switches respond. It was only then that we realized that the nodes would respond on the /30 router interface on the WAN link, and not on the LAN-side router. An email to Alcatel-Enterprise TAC brought forward the solution – 685X switches will only respond to SNMP polls on their primary interface (which I’m guessing is the first interface configured on the units). So, if you setup the WAN connection first, you need to be aware which interface will respond.

Next I wanted to ensure that we were polling the units using SNMP v2 and not v1 – this requires some config work on the 685X nodes to make them pollable. These steps are detailed next:

685X-CLI> aaa authentication snmp “local” – this ensures authentication checks are done against the local user database.

685X-CLI> snmp authentication trap enable – send in a trap when snmp authentication fails.

685X-CLI> snmp source ip preferred [xxx.xxx.xxx.xxx] – IP address of your preferred IP router interface. [In our case I selected the LAN-side IP router as if this works then I already know the WAN side is OK implicitly.]

685X-CLI> snmp security no security – ensure the switch will respond to snmp v2 requests.

685X-CLI> user [private] password [makeone] read-write snmp no auth – creates a new user and gives snmp privileges.
685X-CLI> user [private] password [makeone] read-write all – ensures this user account has access to all snmp rights. [This is important - miss this step and you won't be able to poll using this account.]
685X-CLI> snmp community map private user [private] on
685X-CLI> snmp station X.X.X.X 162 [private] v2 enable (where X.X.X.X is your snmp polling server IP)

685X-CLI> show user private (it should look like this)
User name = private,
Password expiration = None,
Password allow to be modified date = None,
Account lockout = None,
Password bad attempts = 0,
Read Only for domains = None,
Read/Write for domains = All , [***Make sure this reads 'All' and not 'snmp' - as it won't work with 'snmp'***]
Snmp allowed = YES,
Snmp authentication = NONE,
Snmp encryption = NONE

685X-CLI> trap 1 port link enable – this step can be added but isn’t necessary. This will have the 685X switch send a trap if any port on the switch changes state. [This can bombard you with traps if the switch is changing frequently.]

Save your work
685X-CLI> write memory
685X-CLI> copy working certified
685X-CLI> write terminal (to view working configuration)

*** 685X is now ready to be polled by SNMP v2 ***

Configuring the SNMP polling engine, the poller needs to be obviously set for SNMP v2c and the private user name entered as the base community string and read/write community string. Port 161 is used for SNMP polling and also needs to be verified open if there are firewalls in-between the poller and the remote host.

In our case, we also used a shareware utility called “Getif” to test out polling access and to verify that the config was indeed working. You can read more about it here. It’s a useful utility and has many more features than we were using in this configuration.

One last thing:

685X-CLI> show snmp community map – this will show what user accounts are mapped to which community names. You need to verify that the user account created in the steps above is mapped to the private snmp community string.

Hopefully this will get your nodes up and pollable via SNMP. More info to follow when we attempt to convert to SNMP v3.

Clint – Nov 4, 2009

Protocol Logging and Debugging.

Today while working in the lab and trying to get a firewall to play nicely with a VPRN, I wanted to debug and dump out the ICMP packets that I was directing at the VPRN virtual routers. A quick phone call to our Alcatel-Lucent IPD engineer and I had this cookbook in my hands. Cory

Configuring Logs

Two default Logs exist on all 7×50SR:

* Log 99 – records alarms of all severity levels from ‘Main’ source
* Log 100 – records only alarms with critical and major severity levels from ‘Main’ source

When SAM is used to manage the nodes, a log 98 must be created (along with snmp trap-target). It records alarms from ‘Main’ & ‘Security’ source and sends to particular SNMP trap group to SAM

There are 4 possible sources from which events can be logged:

* 1. Main – events related to 7×50 OS applications not assigned to other event categories/sources
* 2. Security – attempts to breach system, like failed login attempts. Generated by the SECURITY application
* 3. Change – events that change the configuration or operation of node. Generated by the USER application.
* 4. Debug – events generated when debug is enabled (debug & trace messages). Generated by the DEBUG application.

* Events are categorized by Application (e.g. APS, ATM, SECURITY, OSPF, etc..).
* Within an Application category, each event has an ID (note that this number is unique within an application category, but not across different application categories).
* Each event is assigned a severity level by default (Critical, Major, Minor, Warning, Info). These can be modified by user.
* Certain events are suppressed by default. This means when they occur an entry will not be generated in the logs. The count of suppressed events is maintained and can be viewed when running the ‘show log event-controller’ command. Most events do generate an entry in the logs. The ‘show log event-controller’ identifies which events are generated and which are suppressed by default.

There are 5 possible destinations to which the logged events can be sent/stored.

* 1. Console or session – Sent to first telnet/ssh session opened. Only valid for duration of session.
* 2 Memory – sent to circular buffer (oldest entry deleted when buffer full.
* 3. File – sent to a specified file located on CF. Need to configure a file-id first (specifies location rollover time of file – i.e. when file is closed and new one started – and retention time.
* 4. SYSLOG server – sent to a syslog server. Need to configure syslog target host first.
* 5. SNMP trap group – sent to SNMP trap group. need to configure snmp community and trap group first.

To view all events that can be logged on a node:

# show log event-controller

To view the event logged to Memory:

# show log log-id <#>

Steps to configure log

1. Configure a log ID with a number from 1 to 97.
2. Identify the source.
3. Specify an optional filter to filter events if required. Requires that the log filter be created first.
4. Identify the destination.

o File
o Syslog
o SNMP
o Memory
o Console or Session

Log Filters

LOG FILTER can be created and applied to a Log so as to only capture events, traps, alarms or debug traces matching particular criteria

Log-id configuration

A:ROUTER>config log log-id 100
*A:ROUTER>config>log>log-id# info detail

—————————————
description “Default Serious Errors Log”
filter 1001
time-format utc
from main
to memory 500
no shutdown
—————————————
Log Filter configuration
Similar to IP filters, where match criteria are specified with associated action of drop or forward.
*A:ROUTER>config>log>filter# info detail
———————————————-
default-action drop
description “Collect events for Serious Errors Log”
entry 10
action forward
description “Collect only events of major severity or higher”
match
no application # event category
no number # event ID
severity gte major # event severity
no router # router name representing VRF-id that generated the event
no subject # entity for which event is reported (e.g. a particular port) – can use regular expression to specify
exit
exit

File-id configuration

Event log files are always created in the \log directory on the specified compact flash device. The naming convention for event log files is:

logEEFF-timestamp
where:
EE is the event log ID
FF is the log file destination ID
timestamp is the timestamp when the file is created in the form of yyyymmdd-hhmmss

where:
yyyy is the four-digit year (for example, 2007)
mm is the two digit number representing the month (for example, 12 for December)
dd is the two digit number representing the day of the month (for example, 03 for the 3rd of the month)
hh is the two digit hour in a 24-hour clock (for example, 04 for 4 a.m.)
mm is the two digit minute (for example, 30 for 30 minutes past the hour)
ss is the two digit second (for example, 14 for 14 seconds)

e.g. log5010-20090206-172530

A file ID can only be assigned to one log-id.

To configure a file-id:

A:ALA-12>config>log# info
——————————————
file-id 10
description “This is a log file.”
location cf1:
rollover 600 retention 24
exit
———————————————-
Note: rollover time in minutes, retention time in hours.

To view the events logged to a file:
# file
# cd cf1:/log
>Cf1/log# type

Syslog Target configuration
A:ROUTER>config>log# syslog 1
A:ROUTER>config>log>syslog$ info detail
———————————————-
no description
no address # IP address of target host
no facility # The code should be entered in accordance with the syslog RFC (e.g.kernel, user, etc)
level info # specifies severity level. Events exceeding level will be sent to syslog
log-prefix “TMNX“ # RFC3164, The BSD syslog Protocol, allows a alphanumeric string (tag) to be prepended to the content of every log message sent to the syslog host. This alphanumeric string can, for example, be used to identify the node that generates the log entry no port
# UDP port that will be used to send syslog messages to the syslog target host. The port configuration is needed if the syslog target host uses a port other than the standard UDP syslog port 514.
———————————————-
SNMP Configuration

* A group specifies the types of SNMP traps and specifies the log ID which will receive the group of
* SNMP traps. A trap group must be configured in order for SNMP traps to be sent.
* Alarms and traps that are generated can be sent to one or more SNMP trap groups.
* Note that if the same trap-target name port port parameter value is specified in more than one SNMP trap group, each trap destination should be configured with a different notify-community value
* Debug events are NOT sent to SNMP trap groups.

Create community string
SR-1# configure system security snmp
SR-1>config>system>security>snmp# community “public” r version both
SR-1>config>system>security>snmp# no shutdown

Create a trap group

SR-1# configure log
SR-1>config>log# snmp-trap-group 50
SR-1>config>log>snmp-trap-group>$ trap-target primary_trap address 128.128.0.5 snmpv2c notify-community public
SR-1>config>log>snmp-trap-group>$ trap-target secondary_trap address 128.128.2.1 snmpv2c notify-community public

Create log-id to be used by trap-group 50

SR-1>config>log# log-id 50
SR-1>config>log>log-id>$ from main
SR-1>config>log>log-id># to snmp 1024
NOTE: The snmp-trap-id must be the same as the log-id

Configuring Service Routers to managed by 5620 SAM

Below is a cookbook for preparing new nodes so they can be managed with 5620 SAM.

7750-SR> configure router interface system address x.x.x.x/32
7750-SR> configure system snmp packet-size 9216
7750-SR> configure system security snmp community “private” rwa version both (“private” can be changed to another community string of your own choosing)
7750-SR> configure system snmp no shutdown

If not you are not running SSH, you need to enable FTP for node backups and firmware upgrades.
7750-SR> configure system security ftp-server
7750-SR> configure system security user admin access ftp

7750-SR> bof
7750-SR> bof persist on
7750-SR> bof save
7750-SR> admin save

At this point you can add your SR management or system IP address into the Discovery Manager, pick the appropriate Mediation policy, and SAM will be able manage your service router.
Cory

IP Services Testing - VPLS Example

After successfully testing a 3 node VPRN as I described a few days ago, I then moved onto testing the VPLS – Virtual Private LAN Service.

At first glance, the VPLS appeared much easier to wrap your head around, and was well understood by everyone from the first whiteboard designs of the proposed test. From a configuration standpoint it was also very straightforward as we didn’t have to concern ourselves with any of the MP-BGP configuration that was somewhat tedious in the VPRN testing.

The other significant difference was that the SDP between the 7750 nodes is a mesh-sdp instead of spoke-sdp. Since we only have two 7750s in our lab, the mesh VS spoke sdp isn’t really that much different, since it is both a mesh and a spoke. However, if we were to add a third 7750 into the mix, the requirement for a full mesh of sdp bindings would be needed to ensure that MAC learning does occur properly at all 3 nodes across the VPLS cloud.

We replicated the same design we had laid out for the VPRN and created three separate VPLS services which all dropped out onto the same SAP with a different dot1q tag per service. The SAP was connected into the 6855 Omniswitch configured for the same dot1q tags. Local VLANs map to the dot1q tags the SAP was handing off, allowing for local access ports to be configured.

vpls-example-1

Up next, DS0 –> 3600 MUX into 7705 C-pipes.
Cory

cory: Hello Gaurav, The 7750SR fully supports Layer 2 VPLSs and Layer 3 VPRNs. The ...
gaurav: Hi Cory i need more info on the VPRN and VPLS networking on the Alcatel 7750...
cdstruth: Hi Pavani, At this point we haven't yet tested DHCP management on the MPLS netwo...
cdstruth: Hi Rups, Thanks for your post. The questions you ask are common to the applicat...
Rups: Hello, This is rups from India. I work in Utilty telecom . I am eager to know...
Pavani: Hi, Do you have any configuration examples for subscurber management/testing...
cdstruth: Hi Thomas, Thank you for your note - it's good to see some additional interest ...

UtilityMPLS.com

Meta

UtilityMPLS Categories

Recent Posts

Calgary