Template(best practice) for Switch ports

Hi,
Looking for best practice advice on switchport config for client facing ports.
We recently had an incident where an access port turned into a trunk(trunk mode desirable), which we obviously do not want to happen again!
For Access Ports(First two should stop DTP I'm hoping?):
switchport mode access
switchport nonegotiate
storm-control broadcast level 20.00
storm-control action trap
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree guard root
switchport port-security maximum 10
switchport port-security
switchport port-security aging time 10
And for trunk ports to clients:
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxx,xxx
switchport nonegotiate
storm-control broadcast level 20.00
storm-control action trap
no cdp enable
spanning-tree bpdufilter enable
spanning-tree guard root
Thanks in advance.

Look here: http://www.cisco.com/en/US/docs/solutions/Enterprise/Branch/E_B_SDC1.html#wp68930
That's Cisco's branch design doc from Design Zone.
For those that want a fast answer:
For VoIP phones and PC:
interface GigabitEthernet1/0/6 - interface GigabitEthernet1/0/23
description phone with PC connected to phone
switchport access vlan 102
switchport mode access
switchport voice vlan 101
switchport port-security maximum 2
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection limit rate 100
load-interval 30
srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth shape 3 0 0 0
priority-queue out
mls qos trust device cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source
ip dhcp snooping limit rate 100
For data only:
interface GigabitEthernet1/0/24- interface GigabitEthernet1/0/28
description DATA only ports
switchport access vlan 102
switchport mode access
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection limit rate 100
load-interval 30
srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth shape 3 0 0 0
priority-queue out
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source
ip dhcp snooping limit rate 100
That's Cisco's recommendation.
And just my opinion is that I'd much rather shut a port down that receives a BPDU than just filter it. Reason being that you can't trust users not to do something stupid, like hook two switch ports to the same switch they're using at their desk in an effort to "make the network faster". For two, if someone malicious plugs in a switch into your environment, shut the port down. . .that makes it hard for them to do anything malicious.

Similar Messages

Best practice for switching from Windows vCenter to vCenter Appliance?

CrimsonKidA wrote:Mike Bailey wrote:
what are the limitations?
Also I was considering this for 6.0 migration, anything in 6 to be concerned about? or sticking with windows version still the best path..Our license is for 5.5 so moving to 6.0 vCenter Appliance isn't an option for us. :/ Do you not have a support contract? Something I would recommend for a production environment.

Does anyone have documentation on this? I cannot seem to find anything online, or it's depricated. I'm switching from vCenter hosted on a Windows Server 2012 R2 to the vCenter virtual appliance (both are version 5.5). I have already deployed the OVA but have yet to configure anything beyond basic networking. Can I export the config from our Windows vCenter, then import it into the vCenter appliance. Help appreciated....
This topic first appeared in the Spiceworks Community

What is best practice for remotely managing bank of switches over POTS

I need to be able to have a back door into several catalyst switches and ASA.
What is the best practice for accessing them remotely. ?

Just place a modem into any console port. Ideally you use a terminal server, but is not always really needed.

Best Practice for SRST deployment at a remote site

What is the best practice for a SRST deployment at a remote site? Should a separate router such as a 3800 series be deployed for telephony in addition to another router to be deployed for Data? Is there a need for 2 different devices?

Hi Brian,
This is typically done all on one ISR Router at the remote site :)There are two flavors of SRST. Here is the feature comparison;
SRST Fallback
This feature enables routers to provide call-handling support for Cisco Unified IP phones if they lose connection to remote primary, secondary, or tertiary Cisco Unified Communications Manager installations or if the WAN connection is down. When Cisco Unified SRST functionality is provided by Cisco Unified CME, provisioning of phones is automatic and most Cisco Unified CME features are available to the phones during periods of fallback, including hunt-groups, call park and access to Cisco Unity voice messaging services using SCCP protocol. The benefit is that Cisco Unified Communications Manager users will gain access to more features during fallback ****without any additional licensing costs.
Comparison of Cisco Unified SRST and
Cisco Unified CME in SRST Fallback Mode
Cisco Unified CME in SRST Fallback Mode
â¢ First supported with Cisco Unified CME 4.0: Cisco IOS Software 12.4(9)T
â¢ IP phones re-home to Cisco Unified CME if Cisco Unified Communications Manager fails. CME in SRST allows IP phones to access some advanced Cisco Unified CME telephony features not supported in traditional SRST
â¢ Support for up to 240 phones
â¢ No support for Cisco VG248 48-Port Analog Phone Gateway registration during fallback
â¢ Lack of support for alias command
â¢ Support for Cisco UnityÂ® unified messaging at remote sites (Distributed Exchange or Domino)
â¢ Support for features such as Pickup Groups, Hunt Groups, Basic Automatic Call Distributor (BACD), Call Park, softkey templates, and paging
â¢ Support for Cisco IP Communicator 2.0 with Cisco Unified Video Advantage 2.0 on same computer
â¢ No support for secure voice in SRST mode
â¢ More complex configuration required
â¢ Support for digital signal processor (DSP)-based hardware conferencing
â¢ E-911 support with per-phone emergency response location (ERL) assignment for IP phones (Cisco Unified CME 4.1 only)
Cisco Unified SRST
â¢ Supported since Cisco Unified SRST 2.0 with Cisco IOS Software 12.2(8)T5
â¢ IP phones re-home to SRST router if Cisco Unified Communications Manager fails. SRST allows IP phones to have basic telephony features
â¢ Support for up to 720 phones
â¢ Support for Cisco VG248 registration during fallback
â¢ Support for alias command
â¢ Lack of support for features such as Pickup Groups, Hunt Groups, Call Park, and BACD
â¢ No support for Cisco IP Communicator 2.0 with Cisco Unified Video Advantage 2.0
â¢ Support for secure voice during SRST fallback
â¢ Simple, one-time configuration for SRST fallback service
â¢ No per-phone emergency response location (ERL) assignment for SCCP Phones (E911 is a new feature supported in SRST 4.1)
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/prod_qas0900aecd8028d113.html
These SRST hardware based restrictions are very similar to the number of supported phones with CME. Here is the actual breakdown;
Cisco 880 SRST Series Integrated Services Router
Up to 4 phones
Cisco 1861 Integrated Services Router
Up to 8 phones
Cisco 2801 Integrated Services Router
Up to 25 phones
Cisco 2811 Integrated Services Router
Up to 35 phones
Cisco 2821 Integrated Services Router
Up to 50 phones
Cisco 2851 Integrated Services Router
Up to 100 phones
Cisco 3825 Integrated Services Router
Up to 350 phones
Cisco CatalystÂ® 6500 Series Communications Media Module (CMM)
Up to 480 phones
Cisco 3845 Integrated Services Router
Up to 730 phones
*The number of phones supported by SRST have been changed to multiples of 5 starting with Cisco IOS Software Release 12.4(15)T3.
From this excellent doc;
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/data_sheet_c78-485221.html
Hope this helps!
Rob

Query: Best practice SAN switch (network) access control rules?

Dear SAN experts,
Are there generic SAN (MDS) switch access control rules that should always be applied within the SAN environment?
I have a specific interest in network-based access control rules/CLI-commands with respect to traffic flowing through the switch rather than switch management traffic (controls for traffic flowing to the switch).
Presumably one would want to provide SAN switch demarcation between initiators and targets using VSAN, Zoning (and LUN Zoning for fine grained access control and defense in depth with storage device LUN masking), IP ACL, Read-Only Zone (or LUN).
In a LAN environment controlled by a (gateway) firewall, there are (best practice) generic firewall access control rules that should be instantiated regardless of enterprise network IP range, TCP services, topology etc.
For example, the blocking of malformed TCP flags or the blocking of inbound and outbound IP ranges outlined in RFC 3330 (and RFC 1918).
These firewall access control rules can be deployed regardless of the IP range or TCP service traffic used within the enterprise. Of course there are firewall access control rules that should also be implemented as best practice that require specific IP addresses and ports that suit the network in which they are deployed. For example, rate limiting as a DoS preventative, may require knowledge of server IP and port number of the hosted service that is being DoS protected.
So my question is, are there generic best practice SAN switch (network) access control rules that should also be instantiated?
regards,
Will.

Hi William,
That's a pretty wide net you're casting there, but i'll do my best to give you some insight in the matter.
Speaking pure fibre channel, your only real way of controlling which nodes can access which other nodes is Zones.
for zones there are a few best practices:
* Default Zone: Don't use it. unless you're running Ficon.
* Single Initiator zones: One host, many storage targets. Don't put 2 initiators in one zone or they'll try logging into each other which at best will give you a performance hit, at worst will bring down your systems.
* Don't mix zoning types: You can zone on wwn, on port, and Cisco NX-OS will give you a plethora of other options, like on device alias or LUN Zoning. Don't use different types of these in one zone.
* Device alias zoning is definately recommended with Enhanced Zoning and Enhanced DA enabled, since it will make replacing hba's a heck of a lot less painful in your fabric.
* LUN zoning is being deprecated, so avoid. You can achieve the same effect on any modern array by doing lun masking.
* Read-Only exists, but again any modern array should be able to make a lun read-only.
* QoS on Zoning: Isn't really an ACL method, more of a congestion control.
VSANs are a way to separate your physical fabric into several logical fabrics. There's one huge distinction here with VLANs, that is that as a rule of thumb, you should put things that you want to talk to each other in the same VSANs. There's no such concept as a broadcast domain the way it exists in Ethernet in FC, so VSANs don't serve as isolation for that. Routing on Fibre Channel (IVR or Inter-VSAN Routing) is possible, but quickly becomes a pain if you use it a lot/structurally. Keep IVR for exceptions, use VSANs for logical units of hosts and storage that belong to each other. A good example would be to put each of 2 remote datacenters in their own VSAN, create a third VSAN for the ports on the array that provide replication between DC and use IVR to make management hosts have inband access to all arrays.
When using IVR, maintain a manual and minimal topology. IVR tends to become very complex very fast and auto topology isn't helping this.
Traditional IP acls (permit this proto to that dest on such a port and deny other combinations) are very rare on management interfaces, since they're usually connected to already separated segments. Same goes for Fibre Channel over IP links (that connect to ethernet interfaces in your storage switch).
They are quite logical to use and work just the same on an MDS as on a traditional Ethernetswitch when you want to use IP over FC (not to be confused with FC over IP). But then you'll logically use your switch as an L2/L3 device.
I'm personally not an IP guy, but here's a quite good guide to setting up IP services in a FC fabric:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/cli_4_1/ipsvc.html
To protect your san from devices that are 'slow-draining' and can cause congestion, I highly recommend enabling slow-drain policy monitors, as described in this document:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/5_0/configuration/guides/int/nxos/intf.html#wp1743661
That's a very brief summary of the most important access-control-related Best Practices that come to mind. If any of this isn't clear to you or you require more detail, let me know. HTH!

IOS Template - Best Practices

Hello,
Does anyone have a standard template that they apply to all ios switches/routers/waps? I'm looking for some best practices for ios configs. For example, which services do you disable on all devices, what snmp settings, etc..
Thanks!

Hi,
See the below link :
http://www.cymru.com/Documents/secure-ios-template.html
Regards,
Mehrdad

Best Practices for MDS Monitoring

We are deploying Solarwinds and would like some tips on what would be useful to monitor on MDS switches. Of course, the normal port utilization, cpu, interface counters are already set up, but thought I would check to see if anyone has any suggestions on any other OID's I should look into.
Thanks!

Hi Mike,
Did you try the following link ?
If not, it may be useful to some extent:
http://service.sap.com/bestpractices
---> Cross-Industry Packages ---> Best Practices for Solution Management
You have quite a few documents there - those on BPM may also cover Solution Monitoring aspects.
Best regards,
Srini
Edited by: Srinivasan Radhakrishnan on Jul 7, 2008 7:02 PM

Best Practice for utility in Sol Man 4.0

We have software component ST-ICO of release 150_700 with Patch level 5
We want a Template Selection for Utility industry. I checked in
the service market place and found that 'Baseline Package United
Kingdom V1.50, Template: BP_BLKU150' is available in the above software
component.
But we are not getting any templates other than 'BP_UTUS147 - Best Practices for Water Utility' in the 'SOLAR_PROJECT_ADMIN'
transaction.
Kindly suggest any patch needs to be applied or some configuration need to be done.
Regards
Mani

Hi Mani,
Colud u plz give me the link of "where u find the template BP_BLKU150"?
It will be helpful for me.
Thanks
Senthil

Best practice for integrating a 3 point metro-e in to our network.

Hello,
We have just started to integrate a new 3 point metro-e wan connection to our main school office. We are moving from point to point T-1?s to 10 MB metro-e. At the main office we have a 50 MB going out to 3 other sites at 10 MB each. For two of the remote sites we have purchase new routers ? which should be straight up configurations. We are having an issue connecting the main office with the 3rd site.
At the main office we have a Catalyst 4006 and at the 3rd site we are trying to connect to a catalyst 4503.
I have attached configurations from both the main office and 3rd remote site as well as a basic diagram of how everything physically connects. These configurations are not working ? we feel that it is a gateway type problem ? but have reached no great solutions. We have tried posting to a different forum ? but so far unable to find the a solution that helps.
The problem I am having is on the remote side. I can reach the remote catalyst from the main site, but I cannot reach the devices on the other side of the remote catalyst however the remote catalyst can see devices on it's side as well as devices at the main site.
We have also tried trunking the ports on both sides and using encapsulation dot10q ? but when we do this the 3rd site is able to pick up a DHCP address from the main office ? and we do not feel that is correct. But it works ? is this not causing a large broad cast domain?
If you have any questions or need further configuration data please let me know.
The previous connection was a T1 connection through a 2620 but this is not compatible with metro-e so we are trying to connect directly through the catalysts.
The other two connection points will be connecting through cisco routers that are compatible with metro-e so i don't think I'll have problems with those sites.
Any and all help is greatly welcome ? as this is our 1st metro e project and want to make sure we are following best practices for this type of integration.
Thank you in advance for your help.
Jeff

Jeff, form your config it seems you main site and remote site are not adjacent in eigrp.
Try adding a network statement for the 171.0 link and form a neighbourship between main and remote site for the L3 routing to work.
Upon this you should be able to reach the remote site hosts.
HTH-Cheers,
Swaroop

BEST PRACTICES FOR CREATING DISCOVERER DATABASE CONNECTION -PUBLIC VS. PRIV

I have enabled SSO for Discoverer. So when you browse to http://host:port/discoverer/viewer you get prompted for your SSO
username/password. I have enabled users to create their own private
connections. I log in as portal and created a private connection. I then from
Oracle Portal create a portlet and add a discoverer worksheet using the private
connection that I created as the portal user. This works fine...users access
the portal they can see the worksheet. When they click the analyze link, the
users are prompted to enter a password for the private connection. The
following message is displayed:
The item you are requesting requires you to enter a password. This could occur because this is a private connection or
because the public connection password was invalid. Please enter the correct
password now to continue.
I originally created a public connection...and then follow the same steps from Oracle portal to create the portlet and display the
worksheet. Worksheet is displayed properly from Portal, when users click the
analyze link they are taken to Discoverer Viewer without having to enter a
password. The problem with this is that when a user browses to
http://host:port/discoverer/viewer they enter their SSO information and then
any user with an SSO account can see the public connection...very insecure!
When private connections are used, no connection information is displayed to
SSO users when logging into Discoverer Viewer.
For the very first step, when editing the Worksheet portlet from Portal, I enter the following for Database
Connections:
Publisher: I choose either the private or public connection that I created
Users Logged In: Display same data to all users using connection (Publisher's Connection)
Users Not Logged In: Do no display data
My question is what are the best practices for creating Discoverer Database
Connections.
Is there a way to create a public connection, but not display it in at http://host:port/discoverer/viewer?
Can I restrict access to http://host:port/discoverer/viewer to specific SSO users?
So overall, I want roughly 40 users to have access to my Portal Page Group. I then want to
display portlets with Discoverer worksheets. Certain worksheets I want to have
the ability to display the analyze link. When the SSO user clicks on this they
will be taken to Discoverer Viewer and prompted for no logon information. All
SSO users will see the same data...there is no need to restrict access based on
SSO username...1 database user will be set up in either the public or private
connection.

You can make it happen by creating a private connection for 40 users by capi script and when creating portlet select 2nd option in Users Logged in section. In this the portlet uses there own private connection every time user logs in.
So that it won't ask for password.
Another thing is there is an option of entering password or not in ASC in discoverer section, if your version 10.1.2.2. Let me know if you need more information
thnaks
kiran

Networking "best practice" for setting up a farm

Hi all.
We would like to set an OracleVM farm, and I have a question about "best practice" for
configuring the network. Some background:
- The hardware I have is comprised of machines with 4 gig-eth NICs each.
- The storage will be coming primarily from a backend NAS appliance (Netapp, FWIW).
- We have already allocated a separate VLAN for management.
- We would like to have HA capable VMs using OCFS2 (on top of NFS.)
I'm trying to decide between 2 possible configurations. The first would keep physical separation
between the mgt/storage networks and the DomU networks. The second would just trunk
everything together across all 4 NICs, something like:
Config 1:
- eth0 - management/cluster-interconnect
- eth1 - storage
- eth2/eth3 => bond0 - 8021q trunked, bonded interfaces for DomUs
Config 2:
- eth0/1/2/3 => bond0
Do people have experience or recommendation about the best configuration?
I'm attracted to the first option (perhaps naively) because CI/storage would benefit
from dedicated bandwidth and this configuration might also be more secure.
Regards,
Robert.

user1070509 wrote:
Option #4 (802.3ad) looks promising, but I don't know if this can be made to work across
separate switches.It can, if your switches support cross-switch trunking. Essentially, 802.3ad (also known as LACP or EtherChannel on Cisco devices) requires your switch to be properly configured to allow trunking across the interfaces used for the bond. I know that the high-end Cisco and Juniper switches do support LACP across multiple switches. In the Cisco world, this is called MEC (Multichassis EtherChannel).
If you're using low-end commodity-grade gear, you'll probably need to use active/passive bonds if you want to span switches. Alternatively, you could use one of the balance algorithms for some bandwitch increase. You'd have to run your own testing to determine which algorithm is best suited for your workload.
The Linux Foundation's Net:Bonding article has some great information on bonding in general, particularly on the various bonding methods for high availability:
http://www.linuxfoundation.org/en/Net:Bonding

What are the best practices for using the enhancement framework?

Hello enhancement framework experts,
Recently, my company upgraded to SAP NW 7.1 EhP6. This presents us with the capability to use the enhancement framework.
A couple of senior programmers were asked to deliver a guideline for use of the framework. They published the following statement:
"SAP does not guarantee the validity of the enhancement points in future releases/versions. As a result, any implemented enhancement points may require significant work during upgrades. So, enhancement points should essentially be used as an alternative to core modifications, which is a rare scenario.".
I am looking for confirmation or contradiction to the statement "SAP does not guarantee the validity of enhancement points in future releases/versions..." . Is this a true statement for both implicit and explicit enhancement points?
Is the impact of activated explicit and implicit enhancements much greater to an SAP upgrade than BAdi's and user exits?
Is there any SAP published guidelines/best practices for use of the enhancement framework?
Thank you,
Kimberly
Edited by: Kimberly Carmack on Aug 11, 2011 5:31 PM

Found an article that answers this question quite well:
[How to Get the Most From the Enhancement and Switch Framework as a Customer or Partner - Tips from the Experts|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/c0f0373e-a915-2e10-6e88-d4de0c725ab3]
Thank you Thomas Weiss!

Best practice for managing a Windows 7 deployment with both 32-bit and 64-bit?

What is the best practice for creating and organizing deployment shares in MDT for a Windows 7 deployment that has mostly 32-bit computers, but a few 64-bit computers as well? Is it better to create a single deployment share for Windows 7 and include both
versions, or is it better to create two separate deployment shares? And what about 32-bit and 64-bit versions of applications?
I'm currently leaning towards creating two separate deployment shares, just so that I don't have to keep typing (x86) and (x64) for every application I import, as well as making it easier when choosing applications in the Lite Touch installation. But I know
each deployment share has the option to create both an x86 and x64 boot image, so that's why I am confused.

Supporting two task sequences is way easier than supporting two shares. Two shares means two boot media, or maintaining a method of directing the user to one or the other. Everything needs to be imported or configured twice. Not to mention doubling storage
space. MDT is designed to have multiple task sequences, why wouldn't you use them?
Supporting multiple task sequences can be a pain, but not bad once you get a system. Supporting app installs intelligently is a large part of that. We have one folder per app install, with a wrapper vbscript that handles OS detection. If there are separate
binaries, they are placed in x86 and x64 subfolders. Everything runs from one folder via the same command, "cscript install.vbs". So, import once, assign once, and forget it. Its the same install package we use for Altiris, and we'll be using a Powershell
version of it when we fully migrate to SCCM.
Others handle x86 and x64 apps separately, and use the MDT app details to select what platform the app is meant for. I've done that, but we have a template for the vbscript wrapper and its a standard process, I believe its easier. YMMV.
Once you get your apps into MDT, create bundles. Core build bundle, core deploy bundle, Laptop deploy bundle, etcetera. Now you don't have to assign twenty apps to both task sequences, just one bundle. When you replace one app in the bundle, all TS'es are
updated automatically. Its kind of the same mentality as active directory. Users, groups and resources = apps, bundles and task sequences.
If you have separate build and deploy shares in your lab, great. If not, separate your apps into build and deploy folders in your lab MDT share. Use a selection profile to upload only your deploy side to production. In fact I separate everything (except
drivers) into Build and deploy folders on my lab server. Don't mix build and deploy, and don't mix Lab/QA and production. I also keep a "Retired" folder. When I replace an app, TS, OS, etcetera, I move it to the retired folder and append "RETIRED - " to the
front of it so I can instantly spot it if it happens to show up somewhere it shouldn't.
To me, the biggest "weakness" of MDT is its flexibility. There's literally a dozen different ways to do everything, and there's no fences to keep you on the path. If you don't create some sort of organization for yourself, its very easy to get lost as things
get complicated. Tossing everything into one giant bucket will have you pulling your hair out.

Best Practice for FlexConnect Wireless roaming in MediaNet environment?

Hello!
Current Cisco best practice recommendations for enterprise MediaNet design, specify that VLANs be local to a switch / switch stack (i.e., to limit the scope of spanning-tree).
In the wireless world, this causes problems if you want users while roaming to keep real-time applications up and running. Every time they connect to a new AP on a different VLAN, then they will need to get a new IP address, which interrupts real-time apps.
So...best practice for LAN users causes real problems for wireless users.
I thought I'd post here in case there's a best practice for implementing wireless roaming in a routed environment that we might have missed so far!
We have a failover pair of FlexConnect 7510s, btw, configured for local switching for Internal users, and central switching with an anchor controller on the DMZ for Guest users.
Thanks,
Deb

Thanks for your replies, Stephen and JSnyder.
The situation here is that the original design engineer is no longer here, and the original design was not MediaNet-friendly, in that it had a very few /20 subnets bridged over entire large sites.
These several large sites (with a few hundred wireless users per site), are connected to an HQ location (where the 7510s in failover mode are installed) via 1G ethernet hand-offs (MPLS at the WAN provider). The 7510s are new, and are replacing older contollers at the HQ location.
The internal employee wireless users use resources both local to their site, as well as centralized resources. There are at least as many Guest wireless users per site as there are internal employee users, and the service to them consists of Internet traffic only. (When moved to the 7510s, their traffic will continue to be centrally switched and carried to an anchor controller in the DMZ.)
(1) So, going local mode seems impractical due to the sheer number of users whose traffic bound for their local site would be traversing the WAN twice. Too much bandwidth would be used. So, that implies the need to use Flex / HREAP mode instead.
(2) However, re-designing each site's IP environment for MediaNet would suggest to go routed to the closet. However, this breaks seamless roaming for users....
So, this conundrum is why I thought I'd post here, and see if there was some other cool / nifty solution I wasn't yet aware of.
The only other (possibly friendly to both needs) solution I'd thought of was to GRE tunnel a subnet from each closet to the collapsed Core / Disti switch at each site. Unfortunately, GRE tunnels are not supported in the rev of IOS on the present equipment, and so it isn't possible to try this idea.
Another "blue sky" idea I had (not for this customer, but possibly elsewhere in the future), is to use LAN switches such as 3850s that have WLC functionality built-in. I haven't yet worked with the WLC s/w available on those, but I was thinking it looks like they could be put into a mobility group, and L3 user roaming between them might then work. Do you happen to know if this might be a workable solution to the overall big-picture problem?
Thanks again for taking the time and trouble to reply!
Deb

Best practice for migrating IDOCs?

Subject: Best practice for migrating IDOC's?
Hi,
I need to migrate some IDOC's to another system for 'historical reference'.
However, I don't want to move them using the regular setup as I don't want the inbound processing to be triggered.
The data that was created in the original system by the processed IDOC's will be migrated to the new system using migration workbench. I only need to migrate the IDOC's as-is due to legal requirements.
What is the best way to do this? I can see three solutions:
A) Download IDOC table contents to a local file and upload them in the new system. Quick and dirty approach, but it might also be a bit risky.
B) Use LSMW. However, I'm not sure whether this is feasible for IDOC's.
C) Using ALE and setting up a custom partner profile where inbound processing only writes the IDOC's to the database. Send the IDOC's from legacy to the new system. Using standard functionality in this way seems to me to be the best solution, but I need to make sure that the IDOC's once migration will get the same status as they had in the old system.
Any help/input will be appreciated
Regards
Karl Johan
PS. For anyone interested in the business case: Within EU the utility market was deregulated a few years ago, so that any customer can buy electricity from any supplier. When a customer switches supplier this is handled via EDI, in SAP using ALE and IDOC's. I'm working on a merger between two utility companies and for legal reasons we need to move the IDOC's. Any other data is migrated using migration workbench for IS-U.

Hi Daniele
I am not entirely sure, what you are asking, Please could you provide additional information.
Are you looking for best practice recommendations for Governance, for example: Change transports between DEV, QA and PRD in BPC 7.0?
What is the best method? Server Manager backup and restore, etc ?
And
Best Practice recommendations on how to upgrade to a different version of BPC, for example: Upgrading from BPC 7.0 to 7.5 or 10.0 ?
Kind Regards
Daniel

Template(best practice) for Switch ports

Similar Messages

Maybe you are looking for