Sinkhole routing rfc1918 on the core/distribution switch (6500)

Hi guys,
I am planning on getting rid of packets going to unrouted nonexistent rfc1918 networks in our DC environment going into internet facing firewall from our core/distribution switch via default route. I am thinking on setting a bunch of rfc1918 static routes to Null0 on the core/distro switches so they will kill all the packets destined to unused rfc1918 networks into Null0. Wondering if that would be a good solution to this.
Thanks!

I am not sure quite what you have in mind when you talk about a bunch of rfc1918 static routes. I could see doing a route for 10.0.0.0 range, for 172.16.0.0 range, and for 192.168.0.0 range. Is 3 a bunch? If you had more in mind what would they be?
If you do static routes to Null0 for the summarized spaces then it would allow routing to any private addresses used inside your network to work since they should have more specific entries in your routing table and it would discard traffic with destination addresses in private address space. Be aware that if you have any site to site VPN tunnels from the firewall or any address translations on the firewall that use private addresses that your plan may very well have negative consequences for them.
HTH
Rick

Similar Messages

Ask the Expert: Hierarchical Network Design, Includes Core, Distribution, and Access

Welcome to the Cisco® Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about hierarchical network design.
Recommending a network topology is required for meeting a customer's corporate network design needs in their business and technical goals and often consists of many interrelated components. The hierarchical design made this easier like "divide and conquer" the job and develop the design in layers.
Network design experts have developed the hierarchical network design model to help to develop a topology in discrete layers. Each layer can be focused on specific functions, to select the right systems and features for the layer.
A typical hierarchical topology is
A core layer of high-end routers and switches that are optimized for availability and performance.
A distribution layer of routers and switches that implement policies.
An access layer that connects users via lower-end switches and wireless access points.
Ahmad Manzoor is a Senior Pre-Sales Engineer at AGCN, Pakistan. He has more than 10 years of experience in first-rate management, commercial and technical skills in the field of data communication and services lifecycle—from solution design through sales pitch, designing RFPs, architecture, and solution—all with the goal toward winning projects (creating win/win situations) of obsolete solutions. Ahmad also has vast experience in designing end-to-end data centers, from building infrastructure design to data communication and network Infrastructure design. He has worked for several large companies in Pakistan and United Arab Emirates markets; for example, National Engineer, WATEEN Telecom, Emircom, Infotech, Global Solutions, NETS International, Al-Aberah, and AGCN, also known as Getronics, Pakistan.
Remember to use the rating system to let Ahmad know if he has given you an adequate response.
Because of the volume expected during this event, Ahmad might not be able to answer every question. Remember that you can continue the conversation in the Solutions and Architectures under the sub-community Data Center & Virtualization, shortly after the event. This event lasts through August 15, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

Dear Leo,
We are discussing the following without any product line, discussing the concept of hierarchical design, which will help you to take decision which model is better for you Two Layer or Three Layer hierarchical model.
Two-Layer Hierarchy
In many networks, you need only two layers to fulfill all of the layer functions—core and aggregation
Only one zone exists within the core, and many zones are in the aggregation layer. Examine each of the layer functions to see where it occurs in a two-layer design:
Traffic forwarding—Ideally, all interzone traffic forwarding occurs in the core. Traffic flows from each zone within the aggregation layer up the hierarchy into the network core and then back down the hierarchy into other aggregation zones.
Aggregation—Aggregation occurs along the core/aggregation layer border, allowing only interzone traffic to pass between the aggregation and core layers. This also provides an edge for traffic engineering services to be deployed along.
Routing policy—Routing policy is deployed along the edge of the core and the aggregation layers, generally as routes are advertised from the aggregation layer into the core.
User attachment—User devices and servers are attached to zones within the aggregation layer. This separation of end devices into the aggregation permits the separation of traffic between traffic through a link and traffic to a link, or device. Typically, it is best not to mix transit and destination traffic in the same area of the network.
Controlling traffic admittance—Traffic admittance control always occurs where user and server devices are attached to the network, which is in the aggregation layer. You can also place traffic admittance controls at the aggregation points exiting from the aggregation layer into the core of the network, but this is not common.
You can see, then, how dividing the network into layers enables you to make each layer specialized and to hide information between the layers. For instance, the traffic admittance policy implemented along the edge of the aggregation layer is entirely hidden from the network core.
You also use the core/aggregation layer edge to hide information about the topology of routing zones from each other, through summarization. Each zone within the aggregation layer should have minimal routing information, possibly just how to make it to the network core through a default route, and no information about the topology of the network core. At the same time, the zones within the aggregation layer should summarize their reachability information into as few routing advertisements as possible at their edge with the core and hide their topology information from the network core.
Three-Layer Hierarchy
A three-layer hierarchy divides these same responsibilities through zones in three vertical network layers,
Traffic Forwarding—As with a two-layer hierarchy, all interzone traffic within a three- layer hierarchy should flow up the hierarchy, through the layers, and back down the hierarchy.
Aggregation—A three-layer hierarchy has two aggregation points:
At the edge of the access layer going into the distribution layer
At the edge of the distribution layer going into the core
At the edge of the access layer, you aggregate traffic in two places: within each access zone and flowing into the distribution layer. In the same way, you aggregate interzone traffic at the distribution layer and traffic leaving the distribution layer toward the network core. The distribution layer and core are ideal places to deploy traffic engineering within a network.
Routing policy—The routing policy is deployed within the distribution layer in a three- layer design and along the distribution/core edge. You can also deploy routing policies along the access/distribution edge, particularly route and topology summarization, to hide information from other zones that are attached to the same distribution layer zone.
User attachment—User devices and servers are attached to zones within the access layer. This separation of end devices into the access layer permits the separation of traffic between traffic through a link and traffic to a link, or device. Typically, you do not want to mix transit and destination traffic in the same area of the network.
Controlling traffic admittance—Traffic admittance control always occurs where user and server devices are attached to the network, which is in the access layer. You can also place traffic admittance controls at the aggregation points along the aggregation/core edge.
As you can see, the concepts that are applied to two- and three-layer designs are similar, but you have more application points in a three-layer design.
Now the confusion takes place in our minds where do we use Two Layer and where the Three layer hierarchical model.
Now we are discussing that How Many Layers to Use in Network Design?
Which network design is better: two layers or three layers? As with almost all things in network design, it all depends. Examine some of the following factors involved in deciding whether to build a two- or three-layer network:
Network geography—Networks that cover a smaller geographic space, such as a single campus or a small number of interconnected campuses, tend to work well as two-layer designs. Networks spanning large geographic areas, such as a country, continent, or even the entire globe, often work better as three layer designs.
Network topology depth—Networks with a compressed, or flattened, topology tend to work better as two-layer hierarchies. For instance, service provider networks cover large geographic areas, but reducing number of hops through the network is critical in providing the services they sell; therefore, they are often built on a two-layer design. Networks with substantial depth in their topologies, however, tend to work better as three-layer designs.
Network topology design—Highly meshed networks, with many requirements for interzone traffic flows, tend to work better as two-layer designs. Simplifying the hierarchy to two levels tends to focus the design elements into meshier zones. Networks that focus traffic flows on well-placed distributed resources, or centralized resources, such as a network with a large number of remote sites connecting to a number of centralized Data Centers, tend to work better as three-layer designs.
Policy implementation—If policies of a network tend to focus on traffic engineering, two-layer designs tend to work better. Networks that attempt to limit access to resources attached to the network and other types of policies tend to work better as three-layer designs.
Again, however, these are simple rules of thumb. No definitive way exists to decide whether a network should have two or three layers. Likewise, you cannot point to a single factor and say, “Because of this, the network we are working on should have three layers instead of two.”
I hope that this helps you to understand the purposes of Two Layer & Three layer Hierarchical Model.
Best regards,
Ahmad Manzoor

Role of Distribution Switch

Hello all,
Can any one explain me what is the role of distribution switch in netwok environment? How the network should be designed proper having it.
My confusion is, having distribution switch in network, should we configure layer3 interfaces on distribution or on core ? how the connected users at access layer switch should communicate with other vlans ? does intervlan routing should be enabled on distribution switch or at core ? what should be the gateway configured for access layer switches or for end users ?
Regards,

As the others have said the core is generally used to simply interconnect your distribution switches, usually using L3 routed links ie. no need for vlans between distro and core.
That said you seem to be talking about a building rather than a campus setup. In a campus set you can have multiple buildings with access switches per floor connecting to a distro pair that do inter vlan routing for the buildings vlans and then each distro pair is connected to core set of switches that route between buildings. This is a standard Cisco 3 tier design but within a single building it might not be the best approach.
In a single building design, as Reza mentioned, a more common design is a collapsed distribution/core where the same pair of switches do both. Each floor really doesn't need a distribution switch unless there is an abnormally high amount of traffic between vlans on the same floor which is generally not the case.
So your access switches on each floor connect back to core/disto pair of switches which handle all the inter vlan routing. As devils advocate mentioned. you can extend L3 back to the access layer but there are limitations with this and with the advent of VSS/MEC on the 6500s and MEC on the 3750s a lot of the advtantage of running L3 to the access layer has gone, and you still get the flexibility that L2 can give you ie. the ability to have a vlan on multiple access switches.
Ideally you do not want servers connecting directly into the core/distro pair (and certainly not the core if you had a dedicated core pair of switches). You would want a separate pair of switches for the servers that then connect back to the core/distro pair. But this often comes down to cost and you often see servers connected to the core/distro pair.
If it is one building i would use the 6500s as a core/distro pair and run MEC from the switches on each floor back to the 6500s. Inter vlan routing would be done on the 6500s, again with the proviso that most of the traffic is between clients on the floors and servers and not between clients and other clients on the same floor.
There is no need to have distribution switches per floor. If you do then be aware that is in effect a L3 routed access layer and the major restriction is that if you have vlan/IP subnet on one switch you cannot then have the same vlan/IP siubnet on another switch on a different floor.
Jon

Route or switch on the core Layer

I am working on a new network design for my company with four buildings, I have used building distribution method for all buildings, my design seems to be functioning properly, I have configured vlans and eigrp routing on the distribution switches as you can see on the diagram, but used the four core layer switches just for switching not routing and I did not configure any routing on them, I would like to know if this is good design or do I need to configure routing on the Core Layer as well

There is no right or wrong answer to this. Originally the recommendation was to switch in the core ie. use only L2 because L2 switching as fast and L3 routing was slow. But then L3 switches appreared and the recommendation was to use L3 to connect to the core.
But both are just recommendations. You don't have to follow the guidelines slavishly.
Having said that, looking at your design there are a lot of redundant paths between switches. This means lots of loops and using L2 will mean blocked paths in the core and potentially blocked paths to and from the core. If you used L3 connections from the distrbution to the core and between the cores you would be able to utilise all the links and hence get more bandwidth.
In addition if a link failed you would not be reliant on STP to bring up a redundant path as all paths would be in use (although you should still run STP).
Couple of other points -
1) you have 4 switches in the core - what is the reasoning behind this ? is it distance limitations between buildings ?
2) your addressing. Ideally you would want to be able to summarise from one building to the other so it would make more sense to have all the 192.168.x.x networks in one building and all the 10.x.x.x networks in the other. Actually it would make more sense to decide on an IP range ie. 10.x.x.x or 192.168.x.x (not both) and then use summarised ranges for each building.
Jon

In a huge campus network design, should be the Core layer operate on L3 if the Distribution is operating on L3?

Or the routing overhead is less if the Core is operating on L2?
For example:
Wan routers and Dist L3 switches connect to Core switches (L2)
Access layer L2 switches connects to Dist.
So Access layer SW's do Diffserv marking, Dist layer switches do queuing, the inter vlan routing as well as routing and the core only forwards traffic based on L2.
Is it a valid design? Should the core also have QoS?
Thanks!

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Yes, you can have a L2 core, but as Rick has noted, modern designs lean toward L3 cores.
There are, even today, pros and cons to each, but the biggest factor would be a modern L3 core would normally use L3 switches, rather than traditional routers. Generally you want the core to move packets as quickly as possible, and L2 switches were generally better at that than "traditional" routers. L3 switches, though, have nearly L2 switch performance, so the performance difference isn't much of issue any longer (especially with CEF L3 switches and/or MPLS).
BTW, not something you'll see in many current design documents, but modern L3 switches are so powerful and support so many ports, that you might have distribution and access just L2.
If you're doing QoS, yes I would recommend it also be enabled in the core too, L2 or L3.

Core layer switches IP address for routing

For routing process I add a IP address of each Vlans subnet that active on each Access and Distribution switches (Have a port with that Vlan on the switch) to the corresponding Vlan Interface of them.
Which IP address should I add to the Core switch for routing?
Should I add a IP of each vlan that in the LAN to each vlan interface of Core layer switch?
I want run OSPF routing protocol on the LAN.

Hello Reza,
>> Which IP address should I add to the Core switch for routing?
if you want to implement a L3 routed core every link betweeen core device and a distribution device is a L3 link with its own IP subnet.
For example if you have 16 distribution pairs and two core switches:
10.10.10.0/30 dis11 to core1
10.10.10.4/30 di12 to core2
10.10.10.8/30 dis21 to core1
10.10.10.12/30 di22 to core2
10.10.10.128/30 disF1 to core1
10.10.10.132/30 disF2 to core2
this under the idea to have not a full mesh between core routers and distribution devices
then you need also a L3 link between the two cores (at least one)
Each L3 device should also have a loopback interface to be used as OSPF router-id and for management purposes (telnet and so on)
you can use /32 loopbacks taken from same block for example
10.255.254.1/32 core1
10.255.254.2/32 core2
10.255.254.3/32 dis11
10.255.254.4/32 dis12
to make the routing function the core switches have to talk OSPF on all links to distribution nodes
router ospf 10
router-id 10.255.254.1
network 10.10.10.0 0.0.0.255 area 0
network 10.255.254.1 0.0.0.0 area 0
network area commands work like ACL statements and first statement starts OSPF on each interface whose ip address belongs to 10.10.10/24 space
Second command is used to advertise its own loopback.
router-id command allows to define the OSPF router-id.
Distribution nodes have to advertise client Vlans and to take part in OSPF communication on point to point link.
if you use a L2 access layer design client vlans are served by distribution nodes.
if you use a L3 access layer design the access layer switches take part in OSPF and have to advertise their own client vlans.
Hope to help
Giuseppe

Confused the CORE Switch's

HI!
PS Throw Light to the following SCenario:
I Have 5 distribution switchs(6509-sup20) connected to Core switch 6509-sup20.the routing protocole its EIGRP.I SENT THE Following Network as a summary to the CORE:
DS1)10.11.0.0:
DS2)10.12.0.0:
DS3:10.13.0.0:
DS4:10.14.0.0:
DS5:10.15.0.0:
Now maybe these confused the core switch.what is the OPTIMUM Way to uncofused the core?& let the core always function properly as well as very good performance
i waiting ur reply!

Under the EIGRP process, the network statement should only include subnets that you want to advertised FROM the router. Subnets that are learned from other devices need NOT to be listed.
If you issue
'sh ip interface brief'
on the core, you can select what networks you want to advertise FROM the core to all devices sharing the same EIGRP AS.
For instance, if the 'sh ip int bri' includes the following networks:
172.16.1.1
192.168.1.1
10.1.1.1
Then your EIGRP process should be like
router eigrp 10
network 172.16.1.0
network 192.168.1.0
network 10.1.1.0
You can also use another method if you have multiple subnets that are within the major network, for instance:
10.11.0.0
10.12.0.0
10.13.0.0
10.14.0.0
could be represented with a single command
router eigrp 10
network 10.0.0.0
no auto-summary.
It will advertise the subnets listed above and not the 10.0.0.0 network because 'no auto-summary' is also part of the EIGRP process.
now if you have the following connected networks:
10.11.0.0 thru 10.14.0.0 AND 10.50.0.0 thru 10.60.0.0 but only want to advertise the 10.11.0.0 thru 10.14.0.0 network then the EIGRP process would be like
router eigrp 10
network 10.8.0.0 0.0.7.255
no auto-summary
Please rate helpful posts.
Thanks

Is it recommended to use HSRP or multiple default between Core Layer Switch and Customer Edge Router?

My client is asking me for following
Client is using Router as edge device. 2 WAN links from different service provider ( each 20 Mbps) are getting terminated on the router. There are internal servers present in the network. Client want to make setup such that even if one wan link fails internet users should be able to access web server. Moreover if the edge router fails there should be secondary edge device so that there is device redundancy ?
As per my understanding, in this scenario we need to do static one - to - one natting(belonging to WAN interface subnet). If we use two routers as Customer edge ans if we connect core layer switch to these two router, is it recommended to use HSRP/VRRP/GLBP or two default route on core switch pointing to two routers with equal ad value. we will also track the wan link with help of ip sla.
which is recommended solution Router redundancy protocol or Default routes.?

Just had another read of this post and some other points have come up.
1) I assumed your secondary link was for redundancy but you talk about terminating both SP links on the same router in your first paragraph.
Did you mean this or are you going to be terminating a link per router ?
2) are you using the second router purely for backup ?
3) something you didn't ask about but is relevant is the IP addressing. Are you using provider independent addressing or does each SP provide you with an address block.
If it is the second then you are going to have an issue with the web server. The problem is which provider's IP do you use for the web server ie.
if you use the primary provider IP then that will be the DNS record on the internet. If the primary router fails then the IP address will change on the secondary router but DNS will still be handing out the primary IP.
If you enter both IPs (primary and secondary) into DNS then you would get load balancing but this means both links will be used and the secondary would not just be backup.
In addition if one of the links fails then DNS does not know this so it will still be handing out the failed address as well as the address that is still up which means some connections will work and some won't.
Jon

N7k as redundant core with vpc to 4510/3750 as distribution switch

Hi - basic question here
Got 2 qty N7k as redundant core with vpc to 4510 and 3750 as redundand distribution switch running MST. I got stuck with some bad cabling design from our IDF to Datacenter so have 2 access switch whereby each one will have a etherchannel to both distribution 4510 and 3750. My question is this is a doable design as I am not sure about the vpc upstream on how it effects etherchannel with MST for my distribution and access.
Thanks

vPC will be considered as one logical link by both upstream and downstream connected devices
the question here are you going to run L3 between the distribution and Core devices ? ( this is recommended design ) if yes, then you do not need to worry about MST and VPC if you going to have it L3 from distribution devices up to the Core
one thing to consider is the distribution switch in your design has big difference in terms of backplane throughput i mean between the 4500 and 3750 !
if you can have both as 4500 will be better and more consistent design
Good luck
if helpful Rate

Recommendation for the Core router

Hi all,
we are hosting provider and we are looking to buy additional router. Right now we have Cisco 6500 with SUP720-3BXL supervisor as a core router which sometimes has a problems because of very weak CPU.
Because of that we are searching for the real router, not switch.
Basically our needs are:
- at least 4 x 10Gbps ports
- at least 80Mpps throughput
- capable to deal with 2 Full BGP tables and at least 30 BGP peers
Any recommendation from your side would be appreciated. It could be also Juniper or Brocade.
Thank you very much in advance!
Ismir

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Perhaps an ASR 9001.

Configuring Frame-Relay and the Frame-Relay Switch To Participate in WAN Routing

Hey,
My WAN in my voice lab is currently functional between all of my routers HQ, BR1, and BR1 with full-mesh connectivity. I am using my PSTN router for the frame-relay switching as is shown in the attached configs. I have used the connect commands for the PVC routing logic.
connect HQ-BR1 Serial0/3/0 101 Serial0/2/0 201
connect HQ-BR2 Serial0/3/0 102 Serial0/2/1 301
connect BR1-BR2 Serial0/2/0 202 Serial0/2/1 302
My question concerns the possibility of getting the PSTN router to participate in the WAN and the OSPF routing process? The connect command tells how the PVCs are to be connected and pass through the PSTN router. Is there anyway to do it so that a PVC connects to the PSTN router itself?
I would specifically like to create a connection between the HQ and PSTN router over the WAN. If anyone has any insight on this I would really appreciate it.
Thank you.

Hello Adam,
you don't need to do FR switching.
You just need to configure a back to back PVC associated to a p2p subinterface under PSTN router interface se0/3/0 and HQ:se0/1/0. the new PVC can be 103 on both sides
PSTN
interface ser0/3/0.103 point-to-point
ip address 10.1.13.1 255.255.255.0
frame-relay interface-dlci 103
HQ
interface ser0/1/0.103 point-to-point
ip address 10.1.13.1 255.255.255.0
frame-relay interface-dlci 103
note: I was able to do this using the older syntax frame-relay route under interface configuration on frame relay switch. I would expect to work for you too with newer syntax connect.
Hope to help
Giuseppe

Precautions prior to reload the core switch of my fabrics

Hello,
I recently bought Gen 4 8-Gbps FC advanced modules for my 9509. I've updated the 9509 to NX-OS 5.2(2). It is indicated in the release notes that after the update, the 9509 need to be reloaded in order to support the Gen 4 modules.
I have a 2 fabrics SAN with core/edge topology. Of course my 9509 are the core switches of my fabrics. They are running the lower priority (1) for every VSANs.
Here the fcdomain info of a VSAN (they have all the same configurations)
VSAN 2
The local switch is the Principal Switch.
Local switch run time information:
       State: Stable
       Local switch WWN:   20:02:00:0d:ec:35:73:81
       Running fabric name: 20:02:00:0d:ec:35:73:81
       Running priority: 1
       Current domain ID: 0xe9(233)
Local switch configuration information:
       State: Enabled
       FCID persistence: Enabled
        Auto-reconfiguration: Disabled
       Contiguous-allocation: Disabled
       Configured fabric name: 20:01:00:05:30:00:28:df
       Optimize Mode: Disabled
       Configured priority: 1
       Configured domain ID: 0xe9(233) (preferred)
Principal switch run time information:
       Running priority: 1
Interface               Role         RCF-reject
port-channel 1     Downstream       Disabled
port-channel 2     Downstream       Disabled
Now, I'm not sure if they are other important points that need to be checked prior to the reload. I do guess that the FCID will not change after the reload and the switch will come back as principal also.
If other configurations need to be verified, feel free to tell me which one.
Thank you in advance.
Eric

I 150% agree with dwb and woodmeister50 about WD hard drives. They are NOWHERE near the quality they should be. When you can get a Seagate for just a few dollars more, and they last years longer, NO ONE should buy a WD. I lost $25,000 worth of music and audiobooks on a six-week-old WD in 2007 and that was the last I'd ever buy from them. They REFUSED to warranty it with the ORIGINAL sales receipt from Bestbuy.
I have 16Gb of Crucial RAM in my Mini and here's what I've discovered.
You WON'T see "lightning fast" performance increases, becasue the Mini is pretty darned fast to begin with. What you WILL see is that when you're running RAM intensive apps like Photoshop or Parallels, other apps won't "bog down".
Quite frequently I find myself with less than half a gig of free RAM out of that 16. When it was only 8 I was at 100% nearly ALL THE TIME. When I only had the 4 it came with, it was always maxed out.

Activating zoneset only from the core switch

Folks,
How can i restrict so that only the core switch is allowed to make changes to the active zoneset?
Also if I am merging two switches and they have active zonesets but with different names, would that merge the two fabrics?
Thanks,
Tarun

your probably thinking about NPV, NPV is disruptive but NPIV isn't. It is just a feature that you would enable on the core.
The acronyms are confusing and easily mixed up.
NPIV allows multiple initiators to login over a single FC/port-channel. NPV changes the operation of the switch so that to the core it looks like a host with a lot of initiators/HBAs. In NPV mode the edge switch doesn't consume any FC domain IDs.
Here is a link that should be helpful - http://www.cisco.com/en/US/prod/collateral/ps4159/ps6409/ps5989/ps9898/white_paper_c11-459263.html

Regarding the tab Distribution Routes is hided and scheduling button too

Hi Techies,
Iam trying to configure the Change Request in Solution Manger 4.0 system while doing so i want to configure in Central Configuration of change management for this what is the tcode available in Solman4.0 and anybody know how to configure the Change request management
the tab Distribution Routes is hided and scheduling button is also hided in Change Request Management
solutions rewarded!!
regards,
S.Rajeshkumar

Hi
I want to access GL item tab account number from MIRO transaction to BADIINVOICE_BADI Method CHANGE_AT_SAVE. I entered the account number in GL account tnumber tab. but parameter TI_RBCO_NEW-BUKRS & TI_RBCO_OLD-BUKRS values are empty inside BADI method.
Can you suggest me how to find this.
Regards
Chandra
Edited by: princeck on Oct 3, 2011 2:32 PM

How to span vlans across core layer in core/distribution/access campus design?

Hi,
I studied Cisco Borderless Campus Design Guide 1.0 (http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide.html) last week because we plan to redesign our campus backbone to a three tier Core/Distribution/Access Design.
Today we use a collapsed backbone where a lot of vlans are spanned across the backbone because they are needed in different buildings.
Could anybody give me a hint how Cisco recommends to deal with that kind of vlans in the multi-tier design?
In my eyes between core and distribution layer there is only routing functionality and no l2 transport of vlans.
So using the same vlan in different buildings seems not to be supported?
Best Regards,
Thorsten

Thorsten
Just to add to Joseph's post.
It is quite common for a vlan to be spanned when it doesn't actually need to be ie. the network has evolved that way.
Most things do not need L2 adjacency, they can happily use L3. Servers sometimes do but in the campus design your servers are usually located in one site so you don't need to extend vlans to other sites in your campus.
Not suggesting this is the case for you but it may be worth checking whether you really do. (apologies if you already have)
As Joseph mentioned you really want to avoid it if at all possible ie. ideally all connections to the core switches are L3 ie. no need for vlans at all in the core.
If you need to extend a few vlans then you can do this but still route for all other vlans ie. you would configure your distribution to core connections as trunks and then allow the vlans you need to extend plus one other vlan, unique per distribution pair, to route all other vlans. So per site your distribution switches route all vlans except the extended vlans and of they need to route to a vlan in another site they use that unique vlan.
But this is not ideal because you then need to extend certain vlans across the core and because you are using L2 connections STP could come into it although that does depend on your core switch selection eg. 4500/6500 VSS etc. would alleviate this.
There are ways to extend vlans across a L3 network but the solutions available are very much dependant on the kit you use and their capabilities so if you do need multiple vlans in multiple sites but still want to keep a L3 core you may want to investigate some of those before purchasing kit (unless of course you have already purchased it).
What you do really depends on just how many vlans you actually need to extend between sites.
Jon

Sinkhole routing rfc1918 on the core/distribution switch (6500)

Similar Messages

Maybe you are looking for