Differential pair routing best practices

I've been looking for differential pair routing methodologies and am wondering if there are any documents available other than what I see in the UB help, which basically just says how to set up the groups in the group editor.
Apparently the pairs must still have each side routed manually, using the rules to check for spacing conformity.
Apparently there is no capability to route both nets simulataneously like I've done in other layout tools. This could get to be a pain for the large designs I need to do.
Also the rules check seems to be flawed. It reports spacing violations in my test placements where there are none. It does not put up design rule error red bubbles for the violations, though it does appear to center the area on the screen at least.
No error is generated for trace lengths outside of the limits, even if topology is set to daisy chain. Apparently one must just watch the spreadsheet while pushing traces to get the length measurement to be correct.
The autorouter doesn't seem to respect differential pairs at all.
If I have many hundreds of diff pairs to set up are there any shortcuts, or do I need to set up each pair manually in the group editor?
Thanks,
David B
Attachments:
DiffPairTest.ewprj ‏39 KB

Similar Messages

IVR (Inter-VSAN Routing) - Best practices questions

Hi there,
We have a situation where we will have multiple customers hosted on a 9513 and sharing a single storage array.
We want to keep the logically seperated in their own VSANs, but of course the storage array will need to be zoned to all the customers hosts.
Now IVR should be the thing to use, but I'm getting resistance from the local team (screams of "Nooooo!!! They're EVILLLLL!!!") ... so I want to find out if there are some best practices around IVR use ?
Should they be used only for light duty stuff ? (though at present we use them with tape backup, which isn't exactly "light")
Do they impact performance to a measurable degree ?
Are they stable ?
What can go wrong with them ? And does it happen often ?
Thanks!

IVR does not impact application I/O performance because all the vsan rewrite and fcid rewrite actions are done in hardware asics. The IVR process on supervisor is responsible for managing the configuration and ensuring the rewrite tables are programmed in the linecards. The process is stable.
Most of the issues I have seen are in environments with multiple IVR enabled MDS switches ISL'd together or an MDS IVR enabled switch connected to a McData/Brocade in an interop mode.
Like any feature there have been bugs and it pays to check the SAN-OS release notes when planning installs. For example, a config change on one switch does not get properly pushed to another IVR switch or a forwarding table for an ISL interface does not get correctly programmed. There have also been a fair share of user misconfigurations which could have been avoided if Cisco Fabric Services (CFS) was enabled for IVR. This is done with the 'ivr distribute' command. Without this it is very difficult in large topologies of multiple IVR switches to ensure they have a consistent IVR config. In other cases there have been problems from a mix of IVR enabled switches running different releases of SAN-OS, e.g. mixing 3.0 with 3.2.
Best practice is to have dual physical fabrics, upgrade one fabric at a time ensuring all IVR switches in a fabric run same SAN-OS release.
A single IVR switch is much easier to implement. The MDS Configuration Guide has a list of best practices for IVR and one of those is to use the NAT option. Personally I would avoid NAT option where you can as NAT makes any troubleshooting harder trying to figure out the domain ID translations. You would also minimize risk of hitting some NAT related bugs, but you could also avoid most of these by checking the workarounds documented in the Release Notes. And with NAT you need to also configure persistent virtual domains and fcids to cater for AIX and HP-UX systems that cannot handle the FCID of the target changing whenever the exported virtual domain ID changes. To give NAT credit, each vsan is represented by a single virtual domain. In regular non-NAT mode, each switch in a vsan is represented by a virtual domain, meaning you eat up more virtual domain IDs. So in large topologies with many domain IDs there are scalability advantages to using NAT and the IVR updates between switches are more efficient with fewer virtual domain IDs to advertize. Of course, NAT must be used if merging physical fabrics with same domain ID and you cannot afford the downtime to change one of the switch domain IDs.
However if it is just a single IVR switch I would avoid NAT. To do this all your domain IDs should be statically defined and there must be no overlapping domain IDs between IVR'd vsans. If it is a brand new install you can easily achieve this by specifying unique allowed domain ID ranges per vsan.
For example, each customer can have their own vsan with say 10 domain IDs and the storage can be in vsan 2. You will only use one domain ID per vsan on day 1. Allowing 10 domain ids per vsan means you can add up to 9 other switches per vsan should you need to in the future. There is a maximum 239 domains per vsan so you could have up to 23 customers on your 9513 working with a range of 10 domain IDs per vsan.
fcdomain domain 2 static vsan 2
fcdomain domain 10 static vsan 10
fcdomain domain 20 static vsan 20
fcdomain domain 30 static vsan 30
..and so on..
fcdomain domain 230 static vsan 230
fcdomain allowed 01-09 vsan 2
fcdomain allowed 10-19 vsan 10
fcdomain allowed 20-29 vsan 20
fcdomain allowed 30-39 vsan 30
..and so on..
fcdomain allowed 230-239 vsan 230
With or without IVR you should still run dual fabrics (e.g. 95xx in each fabric) and host based multipathing for redundancy.
And don't forget IVR will require an Enterprise license. I have even seen a large outage because the customer forgot to install the license before the 120 day grace period expired.

Clone a Cisco router - best practices?

Hello
Recently I had a task to clone Cisco 881 router, I mean I had to transfer a config from one 881 to another.
However, I faced some issues with this task:
SSH doesn't work after the transfer, as I understand it is required to regenerate certificates, consequently it is mandatory to activate telnet before transfer, because I didn't have console access: routers are in the datacenter
AAA wil not work, I had to delete all aaa strings from the config
IOS images should be transfered first as well ass IPS signatures
username password + service password encryption will result an impossibility to login, username secret should be used
Probably, there are even more possible problems which I don't know. How do you guys clone routers? Maybe there are some best practises?
I used TFTP for transfering config and I have a question concerning it: when I do copy tftp run it overwrites running config or append it?
Thank you in advance.

When working as a field engineer and swapping out a router I would always strip out all of the AAA config and just apply a simple "username cisco priv 15 password cisco" and then get the router operational. The last thing you want to be doing is trying to work out why you can't login when you are trying to restore service. Once it is up and running and you are happy with it then you can save the config.
Next you would reapply the AAA config. Assuming nothing has changed (IP addresses, TACAC+ shared secret etc.) then it should just work. And at this point if it does lock you out you can just reboot the box because you saved the config at the point that the router was operational but before you applied the AAA config.
In order to generate the RSA key for SSH you would do "crypto key generate rsa"
Once you have SSH configured you can use TFTP / FTP / SCP to transfer any files to flash. I like to use WINSCP.
To my knowledge there is not an easy way to "clone" a router - there are always a few tasks that need doing manually.

Best Practice for ASA Route Monitoring Options?

We have one pair Cisco ASA 5505 located in different location and there are two point to point links between those two locations, one for primary link (static route w/ low metric) and the other for backup (static route w/ high metric). The tracked options is enabled for monitoring the state of the primary route. the detail parameters regarding options as below,
Frequency: 30 seconds               Data Size: 28 bytes
Threshold: 3000 milliseconds     Tos: 0
Time out: 3000 milliseconds          Number of Packets: 8
------ show run------
sla monitor 1
type echo protocol ipIcmpEcho 10.200.200.2 interface Intersite_Traffic
num-packets 8
timeout 3000
threshold 3000
frequency 30
sla monitor schedule 1 life forever start-time now
------ show run------
I'm not sure if the setting is so sensitive that the secondary static route begins to work right away, even when some small link flappings occur.
What is the best practice to set those parameters up in the production environment. How can we specify the reasonanble monitoring options to fit our needs.
Thank you for any idea.

Hello,
Of course too sensitive might cause failover to happen when some packets get lost, but remember the whole purpose of this is to provide as less downtime to your network as possible,
Now if you tune these parameters what happen is that failover will be triggered on a different time basis.
This is taken from a cisco document ( If you tune the sla process as this states, 3 packets will be sent each 10 seconds, so 3 of them need to fail to SLA to happen) This CISCO configuration example looks good but there are network engineers that would rather to use a lower time-line than that.
sla monitor 123
type echo protocol ipIcmpEcho 10.0.0.1 interface outside
num-packets 3
frequency 10
Regards,
Remember to rate all of the helpful posts ( If you need assistance knowing how to rate a post just let me know )

Is it best practice to use a dedicated link between NX7K pair for keep-alive?

I have been using dedicated physical 10G link between pair of NX7k for keep-alive. Is it a best practice? It seems a waste of 10G ports because keep-alives does not need that much bandwidth.
I'm thinking just configure a dedicated VLAN interface in the default VRF, and have it routed through other devices (fir example 6509 core switches) for keep-alive. Has anyone done that before? The goal is not to use dedicated 10G ports for keep-alive.
Thanks a lot.

gwhuang5398 wrote:I have been using dedicated physical 10G link between pair of NX7k for keep-alive. Is it a best practice? It seems a waste of 10G ports because keep-alives does not need that much bandwidth.I'm thinking just configure a dedicated VLAN interface in the default VRF, and have it routed through other devices (fir example 6509 core switches) for keep-alive. Has anyone done that before? The goal is not to use dedicated 10G ports for keep-alive.Thanks a lot.
I agree that using a Tengig port for this purpose is not efficient. The whole idea of peer-keepalive is to have a way to avoid split brain scenarios in case of peer-link failure. For this reason the peer-keepalives should never cross the peer-link as it defeats the original purpose I just cited. Following are some viable options:
You can use the N7K management ports for peer-keepalive functionality. If you have redundant supervisors then make sure you use an external switch (OOB switch for example) to patch the management ports.
You can use dedicated interfaces just like you are doing right now but that would make more sense if you had Gig ports in my opinion.
You can run peer-keepalives inband but you need to make sure this traffic is never routed over the peer-link. It is considered a good practice to use a dedicated VRF for this purpose.
Atif

Best practice for intervlan routing?

are there some best practices for intervlan routing ?
I've been reading allot and I have seen these scenarios
router on a stick
intervlan at core layer
intervlan at distribution layer.
or is intervlan needed at all if the switches will do the routing?
I've done all of the above but I just want to know what's current.

The simple answer is it depends because there is no one right solution for everyone.
So there are no specific best practices. For example in a small setup where you may only need a couple of vlans you could use a L2 switch connected to a router or firewall using subinterfaces to route between the vlans.
But that is not a scalable solution. The commonest approach in any network where there are multiple vlans is to use L3 switches to do this. This could be a pair of switches interconnected and using HSRP/GLBP/VRRP for the vlans or it could be stacked switches/VSS etc. You would then dual connect your access layer switches to them.
In terms of core/distro/access layer in general if you have separate switches performing each function you would have the inter vlan routing done on the distribution switches for all the vlans on the access layer switches. The core switches would be used to route between the disribution switches and other devices eg. WAN routers, firewalls, maybe other distribution switch pairs.
Again, generally speaking, you may well not need vlans on the core switches at all ie. you can simply use routed links between the core switches and everything else.
The above is quite a common setup but there are variations eg. -
1) a collapsed core design where the core and distribution switches are the same pair. For a single building with maybe a WAN connection plus internet this is quite a common design because having a completely separate core is usually quite hard to justify in terms of cost etc.
2) a routed access layer. Here the access layer switches are L3 and the vlans are routed at the access layer. In this instance you may not not even need vlans on the distribution switches although again to save cost often servers are deployed onto those switches so you may.
So a lot of it comes down to the size of the network and the budget involved as to which solution you go with.
All of the above is really concerned with non DC environments.
In the DC the traditional core/distro or aggregation/access layer was also used and still is widely deployed but in relatively recent times new designs and technologies are changing the environment which could have a big impact on vlans.
It's mainly to do with network virtualisation, where the vlans are defined and where they are not only routed but where the network services such as firewalling, load balancing etc. are performed.
It's quite a big subject so i didn't want to confuse the general answer by going into it but feel free to ask if you want more details.
Jon

EDI - 753Routing Request and 754 Routing Instructions transactions- what SAP ECC6 EDI output type, msg type, msg code, basis idoc is best practice to generate the idoc?

One of our Trading Partner wishes to implement the 753 Routing Request and 754 Routing Instructions. Can anyone give me best practice answer the following Questions? We are on SAP ECC6 R3
What Application? i.e. V2, V7?
What output condition to use? i..e. LALE, LAT2, SEDI????
What Message type? i.e SHPADV?
What Basic Idoc Type? i.e SHPMNT05?
What Message Code? i.e. SHPM?
What Process Code? i.e. SHPM??
What Function Module? i.e. IDOC_OUTPUT_SHPMNT??
Does the SAP Transpotation Module have to be configured for this to be implemented?
Your comments are greatly appreciated, we have until Nov 1 to be compliant?

Good Morning,
While I did not get any responses from my question, yes, I was able to determine what needed to be configured. I hope the below will help you: This is for SAP ECC6
The output application for the 753 Routing Request is "V7"
The output type is "SEDI"
Transmission medium is "6"
The Basic Idoc type is "Shipmnt05"
when setting up your Partner Profile (WE20) add:Message Partner Role "SP" with Message type "SHPADV', Message coed "753", Basic Type "SHPMNT05", Message Control add Application "V7", Message type "SEDI", Process Code "SHPM".
also http://scn.sap.com/thread/698368 pages 14 and 15 were helpful.
I have not configured the Inbound 754. For now the inbound 754 Routing Instructions will be emailed to our traffic department.
Thank you,
Have a great day,
jane

Best Practice for where to apply ACL's on a router

I have a 1760 router with a 4 port ethernet card. It has the Vlan1 int on it for f0/0 in the IOS. I need to apply an ACL to that interface/subnet with the phyical cable in f0/0 and ip range of vlan1. When appling the ACL should I apply it to the physical interface or the Vlan (mgt) interface. What is the best practice and is there any docs on this on cisco?
Thanks
Chris

Chris
The f0/0 is operating as a switch port and as such you can not apply the access list directly to the physical interface. You should apply the access list to the vlan interface.
HTH
Rick

Routing error in Application Best Practice App (TDG) ?

Hi All,
i try Application Best Practices ...
but if i select always another product ...
the category and the Vendor are always the same. But if we check the json files there
are different.
Or should it not work in mock modus?
regards
Bernard

Hi,
I'm not talking about the add. if you select a product ....
the Vendoraddress is always the same ... but in the mockdata json file is different !
cheers
Bernard

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 VPC Domain failover with One M2 per N7K switch and 2 sups

I Have been testing some failover scenarios with 4 nexus 7000 switches with an M2 and an F2 card in each. Each Nexus has two supervisor modules.
I have 3 VDC's Admin, F2 and M2
all ports in the M2 are in the M2 VDC and all ports on the F2 are in the F2 VDC.
All vPC's are connected on the M2 cards, configured in the M2 VDC
We have 2 Nexus representing each "site"
In one site we have a vPC domain "100"
The vPC Peer link is connected on ports E1/3 and E1/4 in Port channel 100
The peer-keepalive is configured to use the management ports. This is patched in both Sups into our 3750s. (this is will eventually be on a management out of band switch)
Please see the diagram.
There are 2 vPC's 1&2 connected at each site which represent the virtual port channels that connect back to a pair of 3750X's (the layer 2 switch icons in the diagram.)
There is also the third vPC that connects the 4 Nexus's together. (po172)
We are stretching vlan 900 across the "sites" and would like to keep spanning tree out of this as much as we can, and minimise outages based on link failures, module failures, switch failures, sup failures etc..
ONLY the management vlan (100,101) is allowed on the port-channel between the 3750's, so vlan 900 spanning tree shouldnt have to make this decision.
We are only concerned about layer two for this part of the testing.
As we are connecting the vPC peer link to only one module in each switch (a sinlge) M2 we have configured object tracking as follows:
n7k-1(config)#track 1 interface ethernet 1/1 line-protocol
n7k-1(config)#track 2 interface ethernet 1/2 line-protocol
n7k-1(config)#track 5 interface ethernet 1/5 line-protocol
track 101 list boolean OR
n7k-1(config-track)# object 1
n7k-1(config-track)# object 2
n7k-1(config-track)# object 5
n7k-1(config-track)# end
n7k-1(config)# vpc domain 101
n7k-1(config-vpc-domain)# track 101
The other site is the same, just 100 instead of 101.
We are not tracking port channel 101, not the member interfaces of this port channel as this is the peer link and apparently tracking upstream interfaces and the peer link is only necessary when you have ONE link and one module per switch.
As the interfaces we are tracking are member ports of a vPC, is this a chicken and egg scenario when seeing if these 3 interfaces are up? or is line-protocol purely layer 1 - so that the vPC isnt downing these member ports at layer 2 when it sees a local vPC domain failure, so that the track fails?
I see most people are monitoring upstream layer3 ports that connect back to a core? what about what we are doing monitoring upstream(the 3750's) & downstream layer2 (the other site) - that are part of the very vPC we are trying to protect?
We wanted all 3 of these to be down, for example if the local M2 card failed, the keepalive would send the message to the remote peer to take over.
What are the best practices here? Which objects should we be tracking? Should we also track the perr-link Port channel101?
We saw minimal outages using this design. when reloading the M2 modules, usually 1 -3 pings lost between the laptops in the diff sites across the stretched vlan. Obviously no outages when breaking any link in a vPC
Any wisdom would be greatly appreciated.
Nick

Nick,
I was not talking about the mgmt0 interface. The vlan that you are testing will have a link blocked between the two 3750 port-channel if the root is on the nexus vPC pair.
Logically your topology is like this:
| |
| Nexus Pair |
3750-1-----------------------3750-2
Since you have this triangle setup one of the links will be in blocking state for any vlan configured on these devices.
When you are talking about vPC and L3 are you talking about L3 routing protocols or just intervaln routing.
Intervlan routing is fine. Running L3 routing protocols over the peer-link and forming an adjaceny with an router upstream using L2 links is not recommended. Teh following link should give you an idea about what I am talking here:
http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/
HSRP is fine.
As mentioned tracking feature purpose is to avoid block hole of traffic. It completely depends on your network setup. Don't think you would be needing to track all the interfaces.
JayaKrishna

Best Practice for config upgrade

Hi
Is there a best practice guide to follow to performing a network upgrade. So I am replacing a stack of 5 3750 switches and replacing with 2 stacks of 2 3750x switches, but then also introducing a 4500x vss pair aswell as the new core. Is there an easy migration process to migrate the config or do I have to understand what the current network is configured as and build a new config for the new topology.
Im new to this process so just wondering if I can find an easier way, Thanks

Is there an easy migration process to migrate the config or do I have to understand what the current network is configured as and build a new config for the new topology.
You really need to understand how the current network is configured before you can do the upgrade otherwise if something doesn't work you will have no idea of where to begin troubleshooting.
That doesn't mean you need to build an entirely new configuration because you may well be able to apply most of the configuration on your existing switches to the new switches although it's not clear what functions the new switches will be doing ie.
currently you have a stack of 3750s doing what ? eg. access for users, routing for vlans etc.
you are replacing them with 3750x's switches and 4500x switches so are you splitting up the functions of the 3750s between them.
If you are then obviously you cannot take the existing configuration and copy it to both the 3750x and the 4500x switches.
When I did upgrades like this I would download the existing configurations to my laptop and make any necessary edits. If I couldn't use the existing configuration I just created new ones. When I came to upgrade I had all the configurations ready to load onto the switches.
Bear in mind that some configuration just won't copy across ie. if you have QOS on your current switches and you try to copy that to the 4500x it probably wont work as they use different commands for a lot of the same functions.
But the key thing is you must understand what you are trying to do ie. simply trying to copy across configurations without the understanding could create a lot of problems.
Jon

Best practice for ASA Active/Standby failover

Hi,
I have configured a pair of Cisco ASA in Active/ Standby mode (see attached). What can be done to allow traffic to go from R1 to R2 via ASA2 when ASA1 inside or outside interface is down?
Currently this happens only when ASA1 is down (shutdown). Is there any recommended best practice for such network redundancy? Thanks in advanced!

Hi Vibhor,
I test ping from R1 to R2 and ping drop when I shutdown either inside (g1) or outside (g0) interface of the Active ASA. Below is the ASA 'show' failover' and 'show run',
ASSA1# conf t
ASSA1(config)# int g1
ASSA1(config-if)# shut
ASSA1(config-if)# show failover
Failover On
Failover unit Primary
Failover LAN Interface: FAILOVER GigabitEthernet2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 3 of 60 maximum
Version: Ours 8.4(2), Mate 8.4(2)
Last Failover at: 14:20:00 SGT Nov 18 2014
This host: Primary - Active
Active time: 7862 (sec)
Interface outside (100.100.100.1): Normal (Monitored)
Interface inside (192.168.1.1): Link Down (Monitored)
Interface mgmt (10.101.50.100): Normal (Waiting)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
Interface outside (100.100.100.2): Normal (Monitored)
Interface inside (192.168.1.2): Link Down (Monitored)
Interface mgmt (0.0.0.0): Normal (Waiting)
Stateful Failover Logical Update Statistics
Link : FAILOVER GigabitEthernet2 (up)
Stateful Obj xmit xerr rcv rerr
General 1053 0 1045 0
sys cmd 1045 0 1045 0
up time 0 0 0 0
RPC services 0 0 0 0
TCP conn 0 0 0 0
UDP conn 0 0 0 0
ARP tbl 2 0 0 0
Xlate_Timeout 0 0 0 0
IPv6 ND tbl 0 0 0 0
VPN IKEv1 SA 0 0 0 0
VPN IKEv1 P2 0 0 0 0
VPN IKEv2 SA 0 0 0 0
VPN IKEv2 P2 0 0 0 0
VPN CTCP upd 0 0 0 0
VPN SDI upd 0 0 0 0
VPN DHCP upd 0 0 0 0
SIP Session 0 0 0 0
Route Session 5 0 0 0
User-Identity 1 0 0 0
Logical Update Queue Information
Cur Max Total
Recv Q: 0 9 1045
Xmit Q: 0 30 10226
ASSA1(config-if)#
ASSA1# sh run
: Saved
ASA Version 8.4(2)
hostname ASSA1
enable password 2KFQnbNIdI.2KYOU encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
interface GigabitEthernet0
nameif outside
security-level 0
ip address 100.100.100.1 255.255.255.0 standby 100.100.100.2
ospf message-digest-key 20 md5 *****
ospf authentication message-digest
interface GigabitEthernet1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
ospf message-digest-key 20 md5 *****
ospf authentication message-digest
interface GigabitEthernet2
description LAN/STATE Failover Interface
interface GigabitEthernet3
shutdown
no nameif
no security-level
no ip address
interface GigabitEthernet4
nameif mgmt
security-level 0
ip address 10.101.50.100 255.255.255.0
interface GigabitEthernet5
shutdown
no nameif
no security-level
no ip address
ftp mode passive
clock timezone SGT 8
access-list OUTSIDE_ACCESS_IN extended permit icmp any any
pager lines 24
logging timestamp
logging console debugging
logging monitor debugging
mtu outside 1500
mtu inside 1500
mtu mgmt 1500
failover
failover lan unit primary
failover lan interface FAILOVER GigabitEthernet2
failover link FAILOVER GigabitEthernet2
failover interface ip FAILOVER 192.168.99.1 255.255.255.0 standby 192.168.99.2
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-715-100.bin
no asdm history enable
arp timeout 14400
access-group OUTSIDE_ACCESS_IN in interface outside
router ospf 10
network 100.100.100.0 255.255.255.0 area 1
network 192.168.1.0 255.255.255.0 area 0
area 0 authentication message-digest
area 1 authentication message-digest
log-adj-changes
default-information originate always
route outside 0.0.0.0 0.0.0.0 100.100.100.254 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
http server enable
http 10.101.50.0 255.255.255.0 mgmt
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
telnet timeout 5
ssh 10.101.50.0 255.255.255.0 mgmt
ssh timeout 5
console timeout 0
tls-proxy maximum-session 10000
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
username cisco password 3USUcOPFUiMCO4Jk encrypted
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email [email protected]
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
crashinfo save disable
Cryptochecksum:fafd8a885033aeac12a2f682260f57e9
: end
ASSA1#

Best practices for NAT/PAT?

Greetings:
My setup is
Cisco 1811 serving as a router/firewall to several windows 2003 servers at an ISP. Ive configured NAT on the router to expose http, https, and smtp ports on each of the servers to a unique public ip address within my x.x.x.230/29 address space.
The WAN port on the 1811 is configured with x.x.x.230/29. On the ServerA I NAT ports 25, 80, and 443 on that same x.x.x.230 address, while managing the 1811 itself using SSH on that same address as well.
On server B (local ip 192.168.0.3), I NAT the x.x.x.231 for ports 25. 80, and 443. On server C (local ip 192.168.0.4), I NAT the x.x.x.232 address for the same ports.
Can anyone offer a critique of this configuration and offer some ideas of the best practices topology-wise for providing routing, vpn and firewall functionality for these servers?
My question arises because now I have a site to site VPN with Server B at the local end and I am unable to connect to the server B smtp port due to the following nat statements. I can confirm that this is the case since by removing the statement I am able to connect.
Here is the NAT section of the show run:
ip nat inside source static tcp 192.168.0.2 443 interface FastEthernet0 443
ip nat inside source static tcp 192.168.0.2 80 interface FastEthernet0 80
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0 overload
ip nat inside source static tcp 192.168.0.3 25 x.x.x.231 25 extendable
ip nat inside source static tcp 192.168.0.3 80 x.x.x.231 80 extendable
ip nat inside source static tcp 192.168.0.3 443 x.x.x.231 443 extendable
ip nat inside source static tcp 192.168.0.4 25 x.x.x.232 25 extendable
ip nat inside source static tcp 192.168.0.4 80 x.x.x.232 80 extendable
ip nat inside source static tcp 192.168.0.4 443 x.x.x.232 443 extendable
Would appreciate any and all comments on the way it is currently configured ass well as:
-How I might be able to change the config to follow a best-practice arrangement for the router/firewall and these servers.
TIA

Hi,
Static PAT is the same as static NAT, except it lets you specify the protocol (TCP or UDP) and port for the local and global addresses.
This feature lets you identify the same global address across many different static statements, so long as the port is different for each statement (you CANNOT use the same global address for multiple static NAT statements).
For example, if you want to provide a single address for global users to access FTP, HTTP, and SMTP, but these are all actually different servers on the local network, you can specify static PAT statements for each server that uses the same global IP address, but different ports
And for PAT you cannot use the same pair of local and global address in multiple static statements between the same two interfaces.
Regards
Bjornarsb

Dual 7010 - Layer 3 Peering Best Practice/Recommendation

I have 2 Nexus 7010s with 2 Nexus 5548s dual connected to each 7K. The 7010s are acting as redundant core devices. Dual Sup2E in each.
Can someone tell me what the best practice is for layer 3 peering (EIGRP) between these devices. I can't seem to find any example documents.
VPCs are used
Approx 20 Vlans. Mutliple functions, lots of virtualized servers (200+) on UCS and VMware.
A firewall HA pair will be connected - 1 to each 7K. This leads to the Internet and DMZ.
1 MPLS WAN router will be connected to the primary 7K.
Let me know if you need any additional info. Thanks!

I'm not sure that I understand your question. Is it EIGRP peering across the vPC links between the Core switches?
If so see below an example for OSPF but the concepts are the same for EIGRP
http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/
Don't forget to rate all posts that are helpful

Differential pair routing best practices

Similar Messages

Maybe you are looking for