Messages

Like Dieselboy said, if I was talking to you I am more interested in the why you selected the solution you did, and not the solution itself.

-Otanx

Yup, me too. I'll admit I found that difficult to articulate, mainly as I don't have a great deal of experience with ISE and zero with Stealthwatch. Apparently just picking their buzzwords and explaining how the tech met that requirement was the right thing to do.

5 stages?

Better ask who your manager will be. If they can't answer that, something fishy is going on.

My prospective manager is the person who persuaded me to apply in the first place, which has the happy side effect of meaning I can skip 2 of the stages (meet the team & hiring manager interview). Step 3 is HR interview and the one I just had would normally be step 4. Last step is meet the head of division (in this case, the director in charge of the presales team), so  it's now down to my personality, which probably means I'm screwed.

Sometimes you have to consider interviewing the company to see if they're a good fit for you 

I've been here just shy of a year so far and it's a pretty good place to work. Bit of a lower salary then I was on before, but they make up for it in other ways that are worth more to me than the difference.

Sounds like there are two other (external) applicants and me left in the running now, so hopefully they have worse personalities than me.

Cheers

J

Thanks for the replies, some more stuff to look into.

@Dieselboy, agreed, the questions were all part of a scenario that they gradually built on. The first part was to do with complete kit refresh, what would I choose and why in terms of HW, topology, protocols etc given needs now and anticipated future changes.

They then asked how I would meet the future needs and why I would make the decisions I did. It was just shy of a 2 hour interview and was not a comfortable experience. I did ask if all the customer meetings would be this intense, and if so could I withdraw my application, which got a giggle from one of the interview panel.

Anyway, looks like I didn't do as badly as I thought afterwards as I've been asked back for the next phase of the 5 stage(!) recruitment process.

Thanks again.

Cheers

J

Hello,

A couple of weeks ago I got press ganged into applying for an internal promotion (ops team lead => presales engineer).

I had the technical interview part of our ridiculous recruitment process yesterday and got asked a question that I thought I gave a reasonable answer to, but now I'm not so sure.

Asking around my team and the existing presales teams hasn't provided much in the way of an answer, so I thought I'd ask here to see how daft I made myself look.

In a nutshell, the question was "What products would you recommend (preferably Cisco) to automate & simplify adding or changing users access to services, and to automate reporting & remediation of breaches?"

I went with ISE linked to whatever the central directory service is for the first part then adding pxGrid & Stealthwatch for the second part.

I'm now thinking I should have thought a bit about SDA/DNA (which I think still uses ISE under the hood?) before answering, wouldn;t have helped as I know very little about them, but may have got a different response from the interviewer.

Thanks in advance for any suggestions.

Cheers

J

Thanks,

All sorted now. The client had gone and 'updated' the config after the contractor had finished, adding a load of  collection of NO-NAT rules from various DMZs to the internal segment, but had left proxy ARP enabled on all of them (among other odd things).

Getting them to tick the box to disable on destination appears to have solved the issue for now.

Cheers

J

Thanks,

The upgrade was from Checkpoint (which I kind of know my way around) to Firepower (never seen one before). I know in the old IPSO firewalls they used to use Proxy ARP as part of the NAT process, but I thought they had discontinued that. I'm wondering if whoever did the upgrade saw a proxy ARP box ticked somewhere in the old environment and migrated it without checking if it was needed.

Dropped is probably the wrong word. Not routing correctly is probably better. One of the IPs the firewall has commandeered is the HSRP address of a network segment, so stuff is going a little wonky in & out of there. It's only showing up on one of the switches, so some traffic is getting through, just not all.

Time to do some reading.

Cheers

J

Hi gents,

Wondering if anyone can point me in the right direction on this one.

One of my customers has just had a firewall upgrade to some nice shiny new FP2110 firewalls. Since the upgrade there has been some minor weirdness with traffic being dropped.

Looking at the ARP tables on the FW edge, it looks as though the FP boxes are sending ARP packets for IP addresses that don't belong to them.

Code Select Expand


10.10.5.200      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.201      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.202      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.203      00:10:58  707d.b912.fa4d  Vlan5         
10.10.5.204      00:05:07  707d.b912.fa4d  Vlan5         
10.10.5.205      00:13:51  707d.b912.fa4d  Vlan5         


I've cleared the ARP cache, but they repopulate. I've had a look inside the FP management interface and I can see that within the NAT configuration there is an option to disable proxy ARP on the destination interface.

Would that sound a reasonable place to start looking at this?

Thanks in advance for any help.

Cheers

J

Yep, the previous guy had to get the provider to permit STP as they've had STP issues since day 1.

They are on 7.3.1. Routing between the local site subjects seems OK, but there is some odd HSRP behaviour.

At the moment the only link between the vPC peers are the peer-link & keepalive. I'm sure I've seen a suggestion that there should be another for L3 & HSRP type traffic but I can't find it now.

I can see how EC would be beneficial if it was just the two DCs, but how would that affect the client sites also connected to the WAN? In my head EC is for a direct link between 2 nodes. Admittedly it's been a while since I was hands on with kit & the NX stuff is all pretty new to me as well.

Cheers

J








Sent from my iPhone using Tapatalk Pro

You misunderstand what I was trying to say.

Probably, misunderstanding people is my superpower 

1) If you have 2 layer 2 links you are going to have 1 active-forwarding, and the other blocking. You currently have 2 layer 2 WAN links, and if you decide to keep them layer 2 you should etherchannel them so that you can use both in an active-active solution, and STP will not have to block one of the links.

Yep, unfortunately, the WAN provider(s) don't support MC-LAG, or anything useful like that, so I'm stuck with what they have.

2) You can also run layer 3 over your layer 2 links by removing switchport on the WAN interfaces and IP them and use ECMP with an IGP. I would do this, but make sure you also have a DCI solution if you are going to stretch L2 over L3.

That would have been what I would have suggested, but they don't have the licences (or expertise to be honest) to run OTV or anything like that, hence the L2 stretch.

There are a whole host of things in this environment that don't sit quite right (native VLAN being used as a transit, reliance on remote customer sites not "misconfiguring" their equipment and breaching the security boundary etc) but it's what I have to work with. A suggestion of a complete redesign now isn't going to even reach the end customer.

Current plan is to get the region names to match and, depending on the outcome of that, possibly move the native VLAN to instance 0.

Thanks for the help & suggestions.

Cheers

J

Jericho,

I would consider making your two L2 WAN links into a port-channel, or make them L3. STP will end up blocking one of the links if you configure them independently. If you are going to do stretched vlans across a layer 3 boundary, you are going to need some sort of DCI solution (vxlan most likely)

I'd love to. Unfortunately the WAN providers don't support that.

It's not stretching across a L3 boundary, the WAN is L2. The L3 interface is a VLAN carried to a firewall.


It's not how I would have designed it if I'd had the choice, but today is my first involvement in this.

Cheers

J

Thanks,

That's probably why STP isn't working between the 2 sites, it's all supposed to be one region.

Each site has it's own VPC pair, with a (now) different domain ID. That was step 1 this morning and sorted out a lot of weirdness. The WAN links are standard trunk links with the stretched VLAN's permitted across them. There is a transit VLAN setup for inter site routing (VLAN 198) between the DC's.

The native VLAN is 115. That's where the routed access link for the remote customer sites is. I've suggested this isn't the best idea ever, but I'm stuck with it at the moment as the remote sites aren't under my, or my customers, configuration control. Whenever I've used MST in the past (rarely), I've left the native VLAN in instance 0. Here they have moved it into the same instance as the other stretched VLAN's.

Everything else was working when I left for the day. I've put it a request to change the region names so they match, I'm just unsure about which instance the native should be in.

Scrappy diagram attached if that helps.

Cheers

J

Hi,

I've just been dropped into a DC environment where odd stuff is happening on the network. It looks like most of the issues are down to a VPC misconfig, but there is also some STP weirdness. They are running MSTP, which I've not got a great deal of experience with and my google skills appear to be failing me today...

The physical setup is 2 DCs with a VPC pair at each site. Each VPC peer has a link to the interconnecting WAN, which is L2. Each site has a number of local VLANs, with a handful that are stretched between the 2 sites. They currently only have 1 link at the secondary site active, as everytime  they bring it online, they get what looks like a broadcast storm on the WAN.

I think I can see the issue(s), but if anyone has any other pointers I'd be grateful.

Firstly, they have named the MST regions differently (they are named after the DC's city). I was under the impression that all switches participating in the same MSTP needed to have the same region name.

Secondly, should the native VLAN be left in instance 0?  I'm struggling to find a definitive answer on this other than a couple of old support forum posts which aren't overly clear (to me at least).

In this case it (VLAN 115) has been moved to instance 3, the instance for the stretched VLANs.

Site A config

Code Select Expand


spanning-tree mst 0-1, 3 priority 4096
spanning-tree mst configuration
  name DC1
  revision 1
  instance 1 vlan 101, 103, 105, 113, 117, 121, 131, 141, 145, 161, 191, 195
  instance 3 vlan 115-116, 191, 192, 193, 196, 197, 198, 199


Site B config

Code Select Expand


spanning-tree mst 0, 3 priority 12288
spanning-tree mst 2 priority 4096
spanning-tree mst configuration
  name DC-2
  revision 1
  instance 2 vlan 102, 104, 106, 114, 122, 132, 142, 146, 162, 192
  instance 3 vlan 115-116, 191, 192, 193, 196, 197, 198, 199


Thanks in advance

J.

Underfloor heating, specifically the one I've just found in the area this months employer have earmarked as their new comms room.

I used to play rugby, old age & a wrist reconstruction finished that off. Nowadays I scuba dive instead.

Kudos - but don't get yourself in trouble, homie.

No worries on that front, it's not the first time we've ignored stupid designs. As long as stuff works we tend to get left alone.

The server guys (who are effectively the customer) are happy with what has been deployed is the main thing.

The fact I have 6 days left on this site might be influencing my lack of concern...

Cheers

J

Routing protocol resilience? Just in case one of them goes down haha

I suppose it's a possibility (process could hang unless there were recovery mechanisms built in to monitor that) - but would mean you would need 2 routing protocols to be implemented, network-wide

Hence me ignoring huge swathes of his design and sticking with OSPF, oddly enough we've never had any issues that I can see would have been solved by multiple routing protocols...

with GNS3 and VIRL and IOU - heck, perfectly serviceable second hand 1800s and 3750s for less than 100 USD - there is ZERO excuse for using work to lab R&S. none.

Agreed. It's a running joke in the ops team, but never acknowledged by anyone with authority to do something about it. My opinion is that it's an ego trip, he designs something complicated, we make it simple, he goes on about how we need to upskill so our ability to support matches his ability to design. To give him fair due, he is technically very good, he just seems to struggle to apply his undoubted knowledge appropriately.

Anyway, Nexus configs done, switches installed, lots of VPCs, couple of OSPF areas, no VDCs and either no one has noticed I've left those out, or no one cares. Seems to be working fine which is the main thing as far as I'm concerned.

Cheers

J