|
With an ASA configured for stateful failover, if the secondary unit has the "failover" command on it then you add "failover" to the primary, is the primary ASA supposed to receive the config from the standby or vice versa? This happened yesterday and the secondary ASA had a blank config with a backup that was 3 months old thanks to it being pulled off of backups during disaster recovery, lovely way to end the day.
|
#
?
Jan 25, 2013 15:44
|
|
|
|
| # ? May 27, 2024 15:41 |
|
|
I have a few LAN-LAN VPN's set up on my ASA 5510, and I also have several anyconnect users. The issue I am having is that while anyone is connected using anyconnect, I am able to access most of the remote networks by enabling split tunneling for these L2L VPN's. However two of the L2L's are identically configured (or so it seems) and I have split tunneling enabled and yet I am not able to pass traffic to these networks. The tunnels work fine when connected to the main network, just not over anyconnect. Is there anything else I need to do to "push" this split tunneling rule for these tunnels to the anyconnect clients? Solved it: forgot an outside,outside nat, whoops! Voltage fucked around with this message at 21:00 on Jan 25, 2013 |
|
#
?
Jan 25, 2013 17:07
|
|
|
Appeal to Cisco thread's wisdom again. Two ASR1002s each with a SONET OC3 card in them with a DACS in between and the DACS is, from what I understand, providing the clocking. We can establish point to point T1s on it without a problem, but bonded T1s with PPP multilink will not come up. Interface looks like this: quote:controller SONET 0/2/0 We have a Cisco 3650 with a serial multilink group setup. We are wanting to move customers off of this old hardware onto the ASR. This device and circuit is currently working without a problem through the same DACS. quote:interface Multilink1 On the ASR I see: quote:"Se0/2/0.1/1:0 PPP: Missed a Link-Up transition, starting PPP" We tested this to a 2650 with a T1 card as well and saw this error: quote:Se0/0 LCP: TIMEout: State REQsent The two devices saw each other as performing a shutdown on one would kill the debug output. Kinda at a loss. We have a ticket in with Cisco who has no idea either.
|
|
#
?
Jan 25, 2013 19:58
|
|
|
I wish Cisco had a cheaper "download patches" TAC subscription available, because holy hell are their lower tier support guys dumb.
|
|
#
?
Jan 25, 2013 21:08
|
|
|
Zuhzuhzombie!! posted:Appeal to Cisco thread's wisdom again. Do you control the DACS? Can you loop the circuits back toward the ASR and see if PPP sees the loop (a debug ppp nego will show packets looping, ie you send a CONFREQ and you get a CONFREQ, interface should go up,down(looped))? Alternatively does it work without MLPPP? And the DACS likely provides clock for the SONET portion, not for the individual DS1s (unless it mentions it does DS1 retiming/clocking). The ASR will be internal clock by default, you'll want to 'clock source line' on the far end. ragzilla fucked around with this message at 22:12 on Jan 25, 2013 |
|
#
?
Jan 25, 2013 22:09
|
|
|
Is it still a common issue to have OSX devices constantly get dropped from ASA IPsec VPN tunnels? My mac users are revolting, but none of them have been willing to let me know when they actually have issues yet, and whether or not its related to their wireless, etc.
|
|
#
?
Jan 25, 2013 23:31
|
|
|
I've had my mbp connected for a week a couple months back. No issues.
|
|
#
?
Jan 25, 2013 23:53
|
|
|
vty posted:Is it still a common issue to have OSX devices constantly get dropped from ASA IPsec VPN tunnels? My mac users are revolting, but none of them have been willing to let me know when they actually have issues yet, and whether or not its related to their wireless, etc. I don't have any issues with the built in ipsec client in OSX with my ASAs.
|
|
#
?
Jan 26, 2013 01:34
|
|
|
Cross posting from the poo poo that pisses you off thread. Was trying to avoid this thread as I think I know the "cisco crowd" answer already (and also I am not a "network guy" by any means, be kind). What is the best way for me to hand out DHCP addresses on a new network segment with an existing DC? I think I have it boiled down to two ideas, but want to get some feedback. 1: Setup my new network segment on its own VLAN. Setup a trunk going into my existing production VLAN allowing all traffic. Add in a second virtual NIC into my existing DC tagged to that new VLAN. Configure to hand out DHCP on that NIC to the new segment. 2: Setup my new network segment on its own VLAN. Setup a trunk going into my existing production VLAN allowing all traffic. Setup an IP helper on all switches within that new segment pointing to my existing DC. This is just something temporary to handle about 250 devices moving into an existing location. Once the dust settles after the move, devices will be properly segregated onto their own VLAN.
|
|
#
?
Jan 26, 2013 02:23
|
|
|
Moey posted:Cross posting from the poo poo that pisses you off thread. Was trying to avoid this thread as I think I know the "cisco crowd" answer already (and also I am not a "network guy" by any means, be kind). I'd say use 2, or have a switch act as a DHCP server if you don't need the AD integration.
|
|
#
?
Jan 26, 2013 02:31
|
|
|
Moey posted:2: Setup my new network segment on its own VLAN. Setup a trunk going into my existing production VLAN allowing all traffic. Setup an IP helper on all switches within that new segment pointing to my existing DC.
|
|
#
?
Jan 26, 2013 02:40
|
|
|
less than three posted:I'd say use 2, or have a switch act as a DHCP server if you don't need the AD integration. Only DHCP service devices are going to be Windows servers. Currently those are domain controllers that handle everything since it is a smaller environment (AD/GC, DNS, DHCP, NTP). Not looking to build a second Windows DHCP server for this segment as this is just temporary until the network gets finalized (currently pretty flat network). adorai posted:You only need the helper on one device per VLAN. We have helper addresses for a few hundred subnets, all pointing back to a single DHCP server, it works quite well. Very easy to manage as well. Is that the more sane route? This will just be a temporary VLAN until the network gets properly segmented. The more I think about it the more I think ip helpers will work best. Edit: With IP helpers, my Windows DHCP server will know what network segment these broadcast requests come from and hand out a proper IP address right?
|
|
#
?
Jan 26, 2013 02:54
|
|
|
Moey posted:With IP helpers, my Windows DHCP server will know what network segment these broadcast requests come from and hand out a proper IP address right? Correct, the relay (helper) puts it's IP address in the DHCPDISCOVER which tells the DHCP server which subnet the request is for. It then sends an OFFER back to the relay agent which forwards it to the device that requested it. http://blog.ipexpert.com/2012/04/05/understanding-dhcp-relays/
|
|
#
?
Jan 26, 2013 03:36
|
|
|
CrazyLittle posted:holy hell are their lower tier support guys dumb. They smoke too much weed.
|
|
#
?
Jan 26, 2013 04:10
|
|
|
chestnut santabag posted:I had a quick look at the images available to download for the 3850s. 90MB for the OS and the rest for licensing and web gui prolly.
|
|
#
?
Jan 26, 2013 04:11
|
|
|
teh z0rg posted:90MB for the OS and the rest for licensing and web gui prolly. WLC software is ~120MB depending on version.
|
|
#
?
Jan 26, 2013 04:30
|
|
|
ragzilla posted:Correct, the relay (helper) puts it's IP address in the DHCPDISCOVER which tells the DHCP server which subnet the request is for. It then sends an OFFER back to the relay agent which forwards it to the device that requested it. Will probably take this route. The extra vNIC within the server now seems like extra work for no reason. Thanks pals!
|
|
#
?
Jan 26, 2013 04:31
|
|
|
Sepist posted:With an ASA configured for stateful failover, if the secondary unit has the "failover" command on it then you add "failover" to the primary, is the primary ASA supposed to receive the config from the standby or vice versa? When the config is first synced it's not written to flash. Generally speaking no, this shouldn't happen. But without both configs and knowing what state each ASA thought it was in, I can't tell you what happened.
|
|
#
?
Jan 27, 2013 01:07
|
|
|
This may seem like a dumb question, but on most switches the management VLAN is not routable correct? So if I was to setup a management IP for all my switches, I would need to dual home (or isolate) a workstation on that network to manage them?
|
|
#
?
Jan 27, 2013 23:45
|
|
|
I'm not aware of any Cisco switches that you can't route the management interface. On a layer2 only cisco switch you would typically assign an IP to a VLAN interface and set "ip default-gateway" instead of "ip route". In certain switches you can only have one VLAN interface up at a time, so no dual homing would be possible at all.
|
|
#
?
Jan 27, 2013 23:56
|
|
|
Thanks for the quick response. The environment in question is running on all layer 3 Dell switches (pretty similar to Cisco from my tinkering, but keep in mind I am not a "network guy"). A 8132F as the "core" backbone switch connected to stacks of 6248 and 6248P layer 3 switches for workstation/phone access. Everything is connected in star topology fashion. Everything was deployed using the default VLAN (1) with management on that VLAN as well. On these switches you cannot do routing on the management interface. We have about 250 more devices coming into this setup, and it was decided that we will start segragating the traffic now as we are running out of available IPs (starting with the new devices, then moving to the existing network later on). The plan is to have the new stacks of access switches running on a different VLAN/network segment and a trunk connecting the new VLAN/segment and existing. This wouldn't have been a problem, except for when I went to implement it, I realized that I cannot enable routing on the existing default VLAN. This is where I hit my wall in designing this as best as possible.
|
|
#
?
Jan 28, 2013 00:03
|
|
|
You don't need to route at all. Think of switches as nothing but hosts on a network. That network is called the management network. Switches don't need to have an IP on the network they are passing traffic for.
|
|
#
?
Jan 28, 2013 00:19
|
|
|
I guess I am pretty confused here. I'll try to elaborate some more. Existing network is 10.1.1.0/22 New network we are trying to setup is 10.2.1.0/22 Core Switch is all VLAN 1 at 10.1.1.1 Created VLAN 40 with an IP address of 10.2.1.2 I created a trunk on port 1 that connects to a new switch for the new network. Allowed VLAN access for VLAN 1 and 40 Access switch is all VLAN 40 at 10.2.1.1 Created VLAN 40 with an IP address of 10.1.1.2 I created a trunk on port 1 that connects to the core switch. Allowed VLAN access for VLAN 1 and 40 From the core switch I can ping my existing network, 10.2.1.1 and a workstation connected to the new network. From the new switch, I can the workstation on the new network, 10.2.1.2, but nothing further From a workstation on the old network (with gateway point at 10.1.1.1) I can ping 10.2.1.2 and 10.2.1.1 but not the workstation on the new network. If it would help for me to draw up a diagram with labels please let me know.
|
|
#
?
Jan 28, 2013 00:47
|
|
|
If you go to your core switch which has two SVIs (vlan interfaces) setup on it and you view it's routing table, you should see your two networks connected. 10.1.1.0/22 10.2.1.0/22 Now where are you trying to ping from? If it is the existing switches all you need to do is make sure their default gateway is 10.2.1.1. The reason is, if you change their IP addresses, to your new management network, they have no idea how to get out of their network except through their default gateway. Also make sure your core switch has vlan 1 with an ip address of 10.1.1.1/22 and vlan 40 with an ip address of 10.2.1.1/22 At this point your switches are passing traffic on vlan 1, but are accessible via vlan40. Make sense?
|
|
#
?
Jan 28, 2013 01:23
|
|
|
It does. I'll test when I get back home tonight. I think i am close but have not changed the gateway on any of the switches (not sure why I didn't check that). Both core and new switch are showing routes to each other though.
|
|
#
?
Jan 28, 2013 01:36
|
|
|
Moey posted:I guess I am pretty confused here. I'll try to elaborate some more. On the other switch you have subnet 10.1.1.0/24 on VLAN 40 Typically you will want your VLANs to match on each switch. I would create a new VLAN for management, say VLAN 10, and add IPs in an unused subnet to each switch on this subnet. Say 10.10.10.0/24. Remove the IPs from all the other subnets. Create VLAN 40 on each switch, for your new access VLAN.
|
|
#
?
Jan 28, 2013 06:00
|
|
|
adorai posted:Create VLAN 40 on each switch, for your new access VLAN. @Moey: Assuming your switches handle VTP, you will probably want to look into using that at some point. Otherwise, you'll shoot yourself in the foot by not creating a VLAN on one random switch, and it'll suck to figure out. disclaimer: VTP is another valid way of shooting yourself in the foot.
|
|
#
?
Jan 28, 2013 16:34
|
|
|
ragzilla posted:Do you control the DACS? Can you loop the circuits back toward the ASR and see if PPP sees the loop (a debug ppp nego will show packets looping, ie you send a CONFREQ and you get a CONFREQ, interface should go up,down(looped))? Alternatively does it work without MLPPP? Correct. T1s that are not bundled will work just fine, only when using PPP with a multilink setup do we see problems. We do control the DACS. I'll see what results we get with a loop back! Thanks! ed Checked with my friend who owns the ticket. Looping back via the DACS showed no PPP, LCAP, etc. Zuhzuhzombie!! fucked around with this message at 17:55 on Jan 28, 2013 |
|
#
?
Jan 28, 2013 17:50
|
|
|
Moey posted:It does. I'll test when I get back home tonight. Gateway (and routes) only matter when you're trying to route between different subnet networks. If you're on the same LAN (vlan) segment as the IP you're trying to reach, you don't need any routes. I've seen "management only" interfaces which won't route traffic on a few devices, but that's kind of a special case, and not typical of normal vlan switching and routing. (sorry if it's "captain obvious" but based on your other questions I figured this might help) CrazyLittle fucked around with this message at 19:47 on Jan 28, 2013 |
|
#
?
Jan 28, 2013 19:43
|
|
|
Zuhzuhzombie!! posted:Correct. T1s that are not bundled will work just fine, only when using PPP with a multilink setup do we see problems. Do you have multiclass/interleaving set on the bundle [1]? Do you get PPP/LCP if you remove all but one member of the bundle in the current config? 1: http://www.cisco.com/en/US/docs/ios-xml/ios/qos_latjit/configuration/xe-3s/asr1000/qos-mppp.pdf
|
|
#
?
Jan 28, 2013 20:11
|
|
|
Here is a general convenience question about IOS CLI. You can type ping 8.8.8.8 repeat 1000 to get 1000 pings to your host. However is there a way to type ping 8.8.8.8 repeat 1000 timestamps? or something, so that you can get the timestamps per packet? Similar to ping on other OSes. Yes i know about extended ping, but what about just a single command?
|
|
#
?
Jan 28, 2013 20:41
|
|
|
Not to my knowledge.
|
|
#
?
Jan 28, 2013 20:44
|
|
|
It also looks like you can't get per packet ttl either, even with the extended ping. Unless I'm missing sometihng.
|
|
#
?
Jan 28, 2013 21:37
|
|
|
Maybe you could use a variation of this TCL script or something using IP SLA, which can be graphed via SNMP?
|
|
#
?
Jan 28, 2013 22:30
|
|
|
To whomever was asking about the 3850 switches earlier in the thread, Cisco just posted some information: http://www.cisco.com/en/US/products/ps12686/index.html
|
|
#
?
Jan 29, 2013 18:46
|
|
|
aquaticrabbit posted:To whomever was asking about the 3850 switches earlier in the thread, Cisco just posted some information: http://www.cisco.com/en/US/products/ps12686/index.html quote:480 G stacking 
|
|
#
?
Jan 29, 2013 19:30
|
|
|
Has anyone ever come across a pretty GUI tool for configuring port-security and clearing error-disables? Our only other network guy is leaving and I am wanting to push this work out to our helpdesk. So far, I've created a custom priv level to restrict commands and deployed our ACS to a few switches. I didn't read enough ahead of time to know that the CNA tool requires a priv level of 15 to be read/write at all. With musical chairs on site, it's about 40 people moves a day (with 2 calls per move) and we're using stickies. I guess I'd rather be doing real work instead. 
|
|
#
?
Jan 29, 2013 21:18
|
|
|
Stop using sticky-mac? There is literally no purpose and all it does is causes problems. Was there some kind of security paper that came out like 10 years ago that said sticky mac is a security feature? If you do have to use sticky-mac just setup a TACACS account that will only run show commands and the specific interface commands to clear the interface. I know there are some REGEX matching scripts for just that sort of thing. Helpdesk people can be taught to do the procedure, its not exactly counter intuitive. Are they also the same people that move the users etc? ate shit on live tv fucked around with this message at 21:51 on Jan 29, 2013 |
|
#
?
Jan 29, 2013 21:47
|
|
|
Powercrazy posted:Stop using sticky-mac? There is literally no purpose and all it does is causes problems. Was there some kind of security paper that came out like 10 years ago that said sticky mac is a security feature? They'd be the helpdesk desk people, we have hourly union in the field that moves computers. Unfortunately, sticky is the method of choice here because we want to stop people from moving computers on their own. I would start using 802.1x, but that doesn't tie a specific port to a specific MAC. Also, we have the cancer that is 200 some odd 4-5 port workgroup switches attached to our closet switches across site. It makes changing VLANs on the ports a very bad day. I just anticipate that the helpdesk will complain that they have to log in to the CLI in order to execute the commands. The only way it is used as security here is that we put dummies on all of the site switch ports, so if someone hooks something into a port and it shouldn't be there it trips an alert.
|
|
#
?
Jan 29, 2013 22:07
|
|
|
|
| # ? May 27, 2024 15:41 |
|
|
I'm starting to think my ASA hates me. I have a ASA5515-x and a HP procurve 5406 L3 switch handling vlans/inter-vlan routing. It works great, except other then the main vlan, none of the other vlans are getting internet access. DNS works fine on them, no ping or traceroute outside though. The worst part? It was all working fine before- the only thing I have done in the last week is attempt to setup a site-to-site VPN (which does not work and is another story.) ASA 10.20.28.1 HP 10.20.28.254 VLAN 28- 10.20.28.254 VLAN 60- 10.20.60.254 On the ASA: route 10.20.0.0/16 10.20.28.254 On the HP : 0.0.0.0 0.0.0.0 10.20.28.1 Devices in VLAN 28 work fine, internet works fine, I can ping/RDP devices in the 10.20.60.x subnet. I can ping/RDP devices in the 10.20.28.x from the 10.20.60.x subnet. I can ping from the HP to the Cisco, I can ping from the Cisco to VLAN 28 and VLAN60, I can ping from the HP to 8.8.8.8 just fine. The vlans use their IP as the default gateway (hence why routing is working.) But its like the ASA does not know how to find the 10.20.60.x subnet. I tried setting more defined static routes, but that did not help. What am I missing?
|
|
#
?
Jan 29, 2013 22:09
|
|