|
less than three posted:It doesn't really matter anyways, because the subinterface number is just an arbitrary choice and doesn't have to actually match the VLAN specified in encapsulation dot1q But generally matching them up seems like a best practice so you don't kill yourself 
|
#
?
Jul 8, 2015 13:40
|
|
|
|
| # ? Apr 26, 2024 19:07 |
|
|
less than three posted:It doesn't really matter anyways, because the subinterface number is just an arbitrary choice and doesn't have to actually match the VLAN specified in encapsulation dot1q Why would anyone do that though? Just to make glancing at the config confusing?
|
|
#
?
Jul 8, 2015 14:52
|
|
|
Dr. Arbitrary posted:Are there other uses for subinterfaces or some other reason to have such a huge range available? Subinterfaces are used in a lot of VRF configurations. As mentioned, the subinterface number is arbitrary, so they're generally numbered to make understanding the configuration easier.
|
|
#
?
Jul 8, 2015 15:25
|
|
|
Barracuda Bang! posted:for just under $800, h If you're willing to drop 800 anyway, consider the e-learning course from Cisco themselves: https://learningnetworkstore.cisco....ars-v2-0-015705 It has interactive lessons, and they did a little bit of gamification that's helpful for motivation. Try the demo, see if the format is something you like.
|
|
#
?
Jul 8, 2015 15:33
|
|
|
So how many of y'all had ASAs reboot today?
|
|
#
?
Jul 9, 2015 02:21
|
|
|
FatCow posted:So how many of y'all had ASAs reboot today? None that I'm aware of, and $JOB[-1] didn't either afaik. Hit a bug?
|
|
#
?
Jul 9, 2015 02:42
|
|
|
Was that why UAL and NYSE went down?
|
|
#
?
Jul 9, 2015 02:44
|
|
|
There is a rumor that WSJ/UAL/NYSE were hit by the same, but honestly if they have mission critical non-HA ASAs running old code they don't deserve to be in business. http://mailman.nanog.org/pipermail/nanog/2015-July/077169.html
|
|
#
?
Jul 9, 2015 03:56
|
|
|
FatCow posted:There is a rumor that WSJ/UAL/NYSE were hit by the same, but honestly if they have mission critical non-HA ASAs running old code they don't deserve to be in business. Hah dude, I routinely see mission critical firewalls running pre-8.4 code. Usually because the owners brought me in to update them to 9.X and migrate their configs in TYOOL 2015.
|
|
#
?
Jul 9, 2015 04:09
|
|
|
psydude posted:Hah dude, I routinely see mission critical firewalls running pre-8.4 code. Usually because the owners brought me in to update them to 9.X and migrate their configs in TYOOL 2015. I recently helped a large financial organization everyone is familiar with the name of to migrate off their PIX firewalls at HQ.
|
|
#
?
Jul 9, 2015 04:18
|
|
|
What is the most efficient way to roll out firmware updates in bulk, for example multiple 2960s at once? Would it be to upload the firmware to one switch and have the rest of them point there for tftp?
|
|
#
?
Jul 9, 2015 08:47
|
|
|
Anyone have any 5506/8-X's running in production yet? If so, how's the performance?
|
|
#
?
Jul 9, 2015 16:07
|
|
|
I'll know in a week, just sold our first one and waiting for it to come in so I can get it on a customer site. I've got a 5506x thats been on my desk for 2 weeks and I've put myself behind it and natted myself into our LAN to test it out, the firepower stuff seems decent but the management gui for firepower is slow as hell on the 5506
|
|
#
?
Jul 9, 2015 19:20
|
|
|
I'm currently redesigning our data center network into a L3 Clos fabric but I wanted to get something clarified. I'm migrating from a traditional tree network with two MLAG cores handling all of the L2/L3 endpoints. This will be accomplished with mostly Arista L3 switches. In the new config, the L3 leaves are at each ToR and will be the L3 endpoint for the VLAN in that rack. Those will route to the 4 spines with ECMP. This is a fairly easy conversion because we are already segregating each rack into its own VLAN in the current architecture. The part I'm stuck on is where to put the external L2 VLAN that houses our public address space, since the spines are not going to be connected to each other. In the previous architecture we would just tag that VLAN down to the TOR switches that needed it, but this won't be possible in the new architecture. Do I need to aggregate up to an edge layer or create another leaf and treat that VLAN as any other?
|
|
#
?
Jul 10, 2015 22:21
|
|
|
I have a 60+ branch network. I am considering installing two internet services at each branch and cancelling my mpls and metro ethernet services. We use voip. 1) am i crazy? 2) if yes, how crazy? Most of my branches have about 4-8 users and are all in one state. Every remote user accesses their applications via VDI, and have no local apps.
|
|
#
?
Jul 11, 2015 00:55
|
|
|
adorai posted:I have a 60+ branch network. I am considering installing two internet services at each branch and cancelling my mpls and metro ethernet services. We use voip. This is the cool thing to do nowadays. I think it's okay as long as VoIP is dedicated to one of the circuits and data to the other, the branches are okay with a "best effort" approach to VoIP quality troubleshooting, and you are okay with the nightmare of working with multiple ISPs for the various outages you experience. If you can't tell, the last point was the pain point when I was part of managing a similar environment.
|
|
#
?
Jul 11, 2015 02:15
|
|
|
pctD posted:I'm currently redesigning our data center network into a L3 Clos fabric but I wanted to get something clarified. I'm migrating from a traditional tree network with two MLAG cores handling all of the L2/L3 endpoints. This will be accomplished with mostly Arista L3 switches. You might dedicate a set of leaf nodes to act as your network edge where your outside IP range lives. If your public facing networks are in multiple racks, consider looking at VXLAN to get the traffic to your edge rack. I believe Arista supports taking VLANs and bridging them into VXLAN for the purposes of making a broadcast domain live "anywhere" regardless of the l3 topology. Basically in the top of rack switch it would be vlan 99; but when the switch needs to forward it it'll wrap it in VXLAN (basically ethernet in UDP) then treat it like any other l3 traffic. I may not have been clear so feel free to ask clarifying questions.
|
|
#
?
Jul 11, 2015 03:11
|
|
|
funk_mata posted:This is the cool thing to do nowadays. I think it's okay as long as VoIP is dedicated to one of the circuits and data to the other, the branches are okay with a "best effort" approach to VoIP quality troubleshooting, and you are okay with the nightmare of working with multiple ISPs for the various outages you experience. If you can't tell, the last point was the pain point when I was part of managing a similar environment. Been doing hosted VoIP via SMB-class internet connections for 10 years now and you pretty much hit the pain points right on the nose. Most of my customers don't even have two connections and it usually works out, but I think they're nuts for doing that if they consider their phones important.
|
|
#
?
Jul 11, 2015 03:39
|
|
|
If call quality is exceedingly important to you, for calls from one office to another, then I would stick with your MPLS VPN for take the sake of getting to maintain your DSCP/CoS tags. However, I'll also say that, even in an MPLS VPN, where troubleshooting call quality can theoretically be done end to end, it can quickly become a total nightmare to try to pull this off, especially if you have centralized border controllers in an offsite data center. If the cost differential between commercial broadband and MPLS is pretty large, then I'd say go for it, especially if you can dump the trouble of maintaining and troubleshooting all those different telco circuits onto a chump-rear end MSP like the one funk_mata is describing. Cell phones, and their attendant call quality, are so ubiquitous now that, as long as your VoIP calls don't sound any worse than a cell phone, users aren't really going to complain.
|
|
#
?
Jul 11, 2015 18:33
|
|
|
adorai posted:I have a 60+ branch network. I am considering installing two internet services at each branch and cancelling my mpls and metro ethernet services. We use voip. Done this a few months ago for a 20 branch customer. Each site had MPLS and it was getting silly expensive, and pretty much most places in the UK now at least have FTTC. Had to get an EFM circuit for one site and the rest all have FTTC now. They have a couple of core sites in all one road that are all fibered up, so I bought a three 4451-X's and some nice lines for the sites there and am running virtual templates on them with PKI for the VPN's with the branches. We've had one or two issues with the lines but otherwise its going really well and the customer is happy because its saving them 6 figures a year on MPLS lines. For another customer we are doing what funk_mata described. Two lines, voice goes on one, anything else on the other
|
|
#
?
Jul 13, 2015 13:48
|
|
|
Do you find the performance of the VPNs over "the Internet" and contended links is acceptable in terms of latency/jitter etc? Or are your FTTC lines generally from the same providers as the other circuits so you don't have to deal with peering congestion?
|
|
#
?
Jul 13, 2015 20:56
|
|
|
I have a seemingly simple DMVPN config that just won't work. I've tried making the hub the spoke and the spoke the hub, and it has the same problem - NHRP registration never completes, and sometimes the hub doesn't even see the request. This persists across a 1941, 2 892s, and an 870; as well as five different circuits from several vendors. I've managed to stump TAC so far. Any ideas? 1.2.3.4 is the IP of gi8 on the hub.code:
|
|
#
?
Jul 14, 2015 01:29
|
|
|
Richard Noggin posted:I have a seemingly simple DMVPN config that just won't work. I've tried making the hub the spoke and the spoke the hub, and it has the same problem - NHRP registration never completes, and sometimes the hub doesn't even see the request. This persists across a 1941, 2 892s, and an 870; as well as five different circuits from several vendors. I've managed to stump TAC so far. Any ideas? 1.2.3.4 is the IP of gi8 on the hub. For your Spoke's NHRP configuration, the NHS should be the protocol (tunnel) address, not the NBMA address. From the Hub debugs it looks like it's decap'ing the GRE packet and throwing the NHRP frame packet on the vlan. Other than that it looks like everything should come right up.
|
|
#
?
Jul 14, 2015 01:32
|
|
|
Whoops, sorry - that was my typo while sanitizing the config. The actual config has the correct values. Here's what I see on the spoke:code:code:
|
|
#
?
Jul 14, 2015 01:44
|
|
|
Thanks Ants posted:Do you find the performance of the VPNs over "the Internet" and contended links is acceptable in terms of latency/jitter etc? Or are your FTTC lines generally from the same providers as the other circuits so you don't have to deal with peering congestion? They are all from the same provider except from the EFM, because apparently they bought that office in the rear end end of nowhere. latency and jitter are very good, usually sub 15-20ms latency between any site and HQ. Keep in mind this is the UK though, and the longest road distance between sites is 340 miles. I guess YMMV for big ol american stuff going all over the place.
|
|
#
?
Jul 14, 2015 16:59
|
|
|
Strangeness. I was able to get the DMVPN going today by nuking the tunnel interface config from all routers, then reapplying it first to the hub, and then the spokes. If I didn't remove it from all, the tunnel never comes up.
|
|
#
?
Jul 14, 2015 17:32
|
|
|
So I've got a new ASA 5506-X to replace an ASA 5505. I wanted to just copy/paste the running config from old to new, but it turns out that the 5506 doesn't have switching capabilities. How do I do vlans?
|
|
#
?
Jul 14, 2015 22:11
|
|
|
Methanar posted:So I've got a new ASA 5506-X to replace an ASA 5505. Are you trying to do router on a stick down to a layer 2 switch? In that case, it's as simple as creating a subinterface and then issuing the vlan configuration command to set the appropriate vlan tag. Make sure you assign an IP address as well and that the port on the L2 switch is configured as a trunk.
|
|
#
?
Jul 14, 2015 23:33
|
|
|
psydude posted:Are you trying to do router on a stick down to a layer 2 switch? In that case, it's as simple as creating a subinterface and then issuing the vlan configuration command to set the appropriate vlan tag. Make sure you assign an IP address as well and that the port on the L2 switch is configured as a trunk. The firewall is doing NAT and traffic filtering. In the configs the interfaces have OSPF costs associated with them, but the firewall doesn't seem to have any real routing going on. We have a 2911 router doing something but nobody knows the password for it and I'm not allowed to recover the password.  I don't know anything about firewalls, routers and switches I'm pretty good at though. I'm ridiculously unqualified for this but I'm trying to be a hero. The current 5505 has three interfaces and each interface is assigned a vlan. I can't check but I very strongly doubt any of the other devices actually use vlans. Inside= f0/1 and f0/3 = vlan 1 outside = f0/0 and f0/4 = vlan 2 dmz = f0/2 = vlan 12 I've got something resembling this on the 5505 right now, so whats equivalent of this without switchport functionality? quote:interface Ethernet0/0 I was thinking I could, for example, assign Inside to g1/8 and resuse the current IP address that the 5505 has set for Inside on the 5506 for Inside. I move everything currently plugged into a 5505 vlan 1 port into a switch that's plugged into the 5506's single Inside. To me the picture below makes sense, except the barracuda device is part of the Outside vlan, but it doesn't have an real public IP. I don't remember it having any special ACL rules either. Honestly it might not even be doing anything. 
|
|
#
?
Jul 15, 2015 01:53
|
|
|
Pretending 10.1.1.1/30 is your outside IP, and 172.16.1.1/24 is your inside... int gi0/0 nameif outside security-level 0 ip address 10.1.1.1 255.255.255.252 int gi0/1 nameif inside security-level 100 ip address 172.16.1.1 255.255.255.0 You don't need the ospf statements, IIRC they're put there when someone configures the interface with ASDM.
|
|
#
?
Jul 15, 2015 02:40
|
|
|
Okay I think I've figured that out. It turns out the way NAT works has changed though. Right now all my live NAT rules are being called exemptions in the ASDM, but in the new one I don't even see the choice to create something called an exemption. Lots of my ACLs have incorrect syntax too. I don't suppose there's an easy way of fixing this, is there? quote:global (inside) 13 interface quote:mlpasafirewall(config)# global (inside) 13 interface
|
|
#
?
Jul 15, 2015 18:06
|
|
|
Read this: http://www.cisco.com/c/en/us/td/docs/security/asa/asa83/upgrading/migrating.html You were running super old code on that 5505 I gather.
|
|
#
?
Jul 15, 2015 18:16
|
|
|
 Ultimately all I want to do is replace the 5505 (left) with 5506 and have it still work. I don't have the option to create rule exemptions for the 5506. I've already gone through that cisco link, but it's pretty far over my head right now.
|
|
#
?
Jul 15, 2015 19:43
|
|
|
Your old NAT configuration is indicative of a really old IOS version so it doesn't surprise me at a glance that just pasting the old config into the new ASA wouldn't work. For example this is relevant to your migration. If this sort of thing is over your head then I'd suggest getting a local IT support company to come in and help you migrate. Edit: alternatively you could see if the old IOS image is compatible with the new ASA but that's some kinda wacky territory to be getting into. Sheep fucked around with this message at 02:24 on Jul 16, 2015 |
|
#
?
Jul 16, 2015 02:17
|
|
|
Methanar posted:
Some interesting NATs you have going on the old firewall. Based on what tidbits of info you gave: code:
Prescription Combs fucked around with this message at 02:58 on Jul 16, 2015 |
|
#
?
Jul 16, 2015 02:47
|
|
|
Sheep posted:Edit: alternatively you could see if the old IOS image is compatible with the new ASA but that's some kinda wacky territory to be getting into. Wouldn't be an option--at best, his 5505 is on 8.2 which isn't supported by the -X series. Since the ASA 5505 supports up to 9.2, you could work your way up the upgrades to convert to 9.2 to transplant the config, but that'd leave an awful mess. Better to recreate all the NAT rules. There's only like 20 something of them, most of which are NoNAT rules.
|
|
#
?
Jul 16, 2015 02:55
|
|
|
Prescription Combs posted:Based on what tidbits of info you gave: Okay this is very helpful. quote:object-group network DMZ-NAT0-LOCAL-NETS I don't quite understand these though. Are the capitals and the X placeholders, if so for what? nat (dmz,outside) source static DMZ-NAT0-LOCAL-NETS DMZ-NAT0-LOCAL-NETS destination static DMZ-NAT0-REMOTE-NETS DMZ-NAT0-REMOTE-NETS ! nat (inside,outside) source static MeadowNetwork MeadowNetwork destination static Serpong_HQ Serpong_HQ ! Kind of the same thing here, what are the capitals. Why is MeadowNetwork written twice in a row and what exactly is being sent to/from Serpong. Sheep posted:a local IT support company lol
|
|
#
?
Jul 16, 2015 03:27
|
|
|
Methanar posted:Okay this is very helpful. 'MeadowNetwork' looks to already be defined in an object-group. 'Serpong_HQ' is an unknown from the config snippet you gave since it's a named IP. Methanar posted:nat (dmz,outside) source static DMZ-NAT0-LOCAL-NETS DMZ-NAT0-LOCAL-NETS destination static DMZ-NAT0-REMOTE-NETS DMZ-NAT0-REMOTE-NETS This is how the syntax is to keep the network 'identity' from changing. You can do some serious network masking with it. nat (real interface,mapped interface) source static <real network or IP> <mapped network or IP> destination static <real remote network or IP> <mapped remote network or IP> So, you can map your 'real' IP(s) as something else before it is sent to the destination network. Either for VPN or separate interface segment. In your case, you need to keep the network identity of 'dmz local' network when being sent across the VPN? to whatever destination subnet is defined on the NAT0 access-lists. Methanar posted:Kind of the same thing here, what are the capitals. Why is MeadowNetwork written twice in a row and what exactly is being sent to/from Serpong. Prescription Combs fucked around with this message at 07:40 on Jul 16, 2015 |
|
#
?
Jul 16, 2015 07:35
|
|
|
I've got a uc500 that seems to have been affected by a lightning storm. Users are reporting static on their end of the phone. Would that be a damaged Fxo port and if so is it fixable?
|
|
#
?
Jul 16, 2015 21:02
|
|
|
|
| # ? Apr 26, 2024 19:07 |
|
|
Plug the line into another phone of some sort and be sure if it is the source of the trouble or not. Lightning storms tend to mean rain, and rain means static.
|
|
#
?
Jul 16, 2015 21:16
|
|
