|
CrazyLittle posted:Unplug it with a curtsy Goddamn
|
#
?
Nov 4, 2016 21:42
|
|
|
|
| # ? Jun 10, 2024 04:04 |
|
|
CrazyLittle posted:Unplug it with a curtsy  Post of the week.
|
|
#
?
Nov 4, 2016 21:55
|
|
|
Methanar posted:How can I gracefully cease all traffic on one of my wan links? neighbor 1.1.1.1 shutdown That will shut down the BGP session with your neighbor, causing all the routes over that link to withdraw and start using other links. I usually see all traffic cease in a couple of minutes, but I imagine it would depend on the size of your network/other peering.
|
|
#
?
Nov 4, 2016 22:14
|
|
|
Methanar posted:How can I gracefully cease all traffic on one of my wan links? Local preference is used just to redirect traffic outbound from your side and if you use it, the deprioritized route will remain in the BGP table as a backup but will be replaced in the RIB by any path to the same prefix with superior local preference. This should be a hitless change, since the route remains valid up to the point that it is overwritten. For inbound traffic, prepending on that side will help you if your peer isn't ignoring AS path in the best path calculation. If your peer is ignoring AS path, unless you can mess with config on their side then your only real option is to shut down the neighbor on that side. As long as they have a route through your preferred path recovery should be nearly instantaneous but if they're currently preferring the path you wish to cut off or including it in load balancing you might get a tiny bit of traffic loss. Eletriarnation fucked around with this message at 04:29 on Nov 5, 2016 |
|
#
?
Nov 5, 2016 04:27
|
|
|
In the past I've used an ICMP SLA responder with reliable static routing and then set up a time-based ACL that blocked outbound ICMP requests. Worked pretty well. But if you're using BGP then the other methods mentioned are a bit better.
|
|
#
?
Nov 5, 2016 05:07
|
|
|
I need to migrate some ipsec VPNs from vlans with HSRP to hardware that doesn't have switchports. I'm migrating from 3845s to 3945s and the switch modules are different. Previously I would just configure the crypto map like so:code:Does anyone have any suggestions for how to make this work with the new hardware without having to change anything on the other end of the VPN tunnel? I know I can install the ESW switch module in the 3945 with an adapter but I want to upgrade to a network module with GE ports, and also as far as I can tell the ESW switch module is EoL too (and it's not listed as supported cisco's 3945 module page).
|
|
#
?
Nov 5, 2016 05:29
|
|
|
You can't just use subinterfaces?
|
|
#
?
Nov 5, 2016 10:54
|
|
|
abigserve posted:You can't just use subinterfaces? I'm going to try that out, but I'm not sure how HSRP will work since there is no l2 connectivity between routers. I suppose I need to trunk between each router's switch module and create the subinterface on the interface that connects to the switch module?
|
|
#
?
Nov 6, 2016 00:20
|
|
|
ElCondemn posted:I'm going to try that out, but I'm not sure how HSRP will work since there is no l2 connectivity between routers. I suppose I need to trunk between each router's switch module and create the subinterface on the interface that connects to the switch module? Sorry for the one word reply.
|
|
#
?
Nov 6, 2016 00:39
|
|
|
Another dumb question: Why would my eBGP routes be showing an administrative distance of 200? I see that my iBGP learned routes and eBGP learned routes both have the same AD when eBGP is supposed to be 20 B E 1.0.4.0/24 [200/0] via 1.1.1.1 Ethernet1 e; Isn't it actually better that they share the same AD, otherwise the iBGP route would never be considered when there are eBGP routes available? e; okay apparently AD is ignored unless you are comparing one routing process's routes to BGP. So if traffic enters the left router and wants to get to an ASN off the right router, it will always take the ibgp path to the right router because that would have an AS-PATH of 1 assuming there isn't any local preference in the way. 
Methanar fucked around with this message at 00:28 on Nov 8, 2016 |
|
#
?
Nov 8, 2016 00:00
|
|
|
Are you receiving the same prefix via the two different eBGP peers in this scenario? Also: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
|
|
#
?
Nov 8, 2016 02:12
|
|
|
Yes, I'm getting a full BGP table from two sources right now and will be getting four soon. I've read over that page and it was very helpful to me. That's how I worked out my edits there and was mostly looking for someone to confirm my interpretations. I guess another question I have is it better to do next-hop-self for iBGP neighbors or route the upstream point to point /30s. At least in a simpler case like mine it doesn't matter at all. It might become relevant if you start adding in route reflectors Without either internal routing or modifying the next-hop the BGP routes don't enter the table since core 1 one doesn't know about core 2's point to point links. Methanar fucked around with this message at 02:40 on Nov 8, 2016 |
|
#
?
Nov 8, 2016 02:32
|
|
|
Methanar posted:So if traffic enters the left router and wants to get to an ASN off the right router, it will always take the ibgp path to the right router because that would have an AS-PATH of 1 assuming there isn't any local preference in the way. R2 (right) would see the same ASPATH as learned on R1. Path selection algorithm would be employed on R2 to figure out best path for that router, then on the RIB to FIB export the appropriate AD (20 vs 200) would take effect. eBGP AD of 20 only applies if the prefix was learned over eBGP on that router. code:-edit- Methanar posted:I guess another question I have is it better to do next-hop-self for iBGP neighbors or route the upstream point to point /30s. At least in a simpler case like mine it doesn't matter at all. It might become relevant if you start adding in route reflectors Unless you want to start carrying peer linknets in your IGP or redist'ing into iBGP (my preference, to have them available for monitoring with all the benefits of PIC), next-hop-self toward the RRs. Less state in IGP = better assuming you're talking xSP design. -bonus edit- Obligatory BGP Techniques for Service Providers. ragzilla fucked around with this message at 02:43 on Nov 8, 2016 |
|
#
?
Nov 8, 2016 02:39
|
|
|
quote:eBGP AD of 20 only applies if the prefix was learned over eBGP on that router This is the case of what's happening though isn't it? R2 is getting the table from ISP 4 over eBGP.
|
|
#
?
Nov 8, 2016 02:52
|
|
|
Methanar posted:This is the case of what's happening though isn't it? R2 is getting the table from ISP 4 over eBGP. The prefix is still compared in the BGP process first, before AD is considered. AD is only a consideration once the prefix exports from the BGP RIB to the router RIB (to compare against other protocols).
|
|
#
?
Nov 8, 2016 02:56
|
|
|
I have two Cisco ASA's in a failover pair. Are there certain settings that don't automatically sync between the members? Yesterday we failed over to the standby device, and our remote access VPN went down. RANCID diffs showed that it lost a few settings under the webvpn section.code:
|
|
#
?
Nov 8, 2016 15:26
|
|
|
Docjowles posted:I have two Cisco ASA's in a failover pair. Are there certain settings that don't automatically sync between the members? Yesterday we failed over to the standby device, and our remote access VPN went down. RANCID diffs showed that it lost a few settings under the webvpn section. The configs are synced, but the files aren't. You need to make sure your anyconnect packages are on both ASAs.
|
|
#
?
Nov 8, 2016 15:27
|
|
|
Ok. But why did "enable vlan21" also disappear, then? edit: Also, the files are present. It's just the config lines telling the VPN to use them that went missing. So I don't think that actually explains what happened at all. Docjowles fucked around with this message at 16:42 on Nov 8, 2016 |
|
#
?
Nov 8, 2016 15:39
|
|
|
Docjowles posted:Ok. But why did "enable vlan21" also disappear, then? Not sure why you lost vlan21, that shouldn't happen. Do you a secondary IP for that interface in the failover config? What code version? Looking at our recent one this weekend (files missing from secondary) we just lost the package lines: code:
|
|
#
?
Nov 8, 2016 17:41
|
|
|
If you ever make a change on the standby ASA, it'll break config sync. You'd have to manually resync them to get it working again.
|
|
#
?
Nov 9, 2016 14:59
|
|
|
You're not running multiple context mode on those ASA's are you? I've seen some weird new stuff in the later version of code regarding shared storage url's and stuff that I needed to do to get any anyconnect package working
|
|
#
?
Nov 9, 2016 15:10
|
|
|
CrazyLittle posted:Unplug it with a curtsy Best networking post ever.
|
|
#
?
Nov 9, 2016 18:17
|
|
|
Is there a way to do BFD across Loopback interfaces? Router A is a route reflector client of Router C, Loopback0 is 10.0.0.1/32. Router A is directly connected to Router B. Router C Loopback0 is 10.0.0.3/32. Router C is directly connected to Router B. BGP Session is between 10.0.0.1 and 10.0.0.3. Routers A and C have routes to each other's Loopback Address via OSPF. I would like to run the BFD across the BGP session for faster failure detection, but all I'm finding are examples on two directly connected interfaces.
|
|
#
?
Nov 10, 2016 00:16
|
|
|
Filthy Lucre posted:Is there a way to do BFD across Loopback interfaces? Typically for this case you'd rely on the underlying (BFD enabled) IGP removing the /32 route to signal BGP to tear down the session. If it doesn't because you have another covering route you may want to look at fall-over using a route-map to ensure the neighbor goes down when the fall-over prefix disappears. http://networkop.co.uk/blog/2015/06/11/ibgp-fallover-trick/
|
|
#
?
Nov 10, 2016 01:28
|
|
|
ragzilla posted:Typically for this case you'd rely on the underlying (BFD enabled) IGP removing the /32 route to signal BGP to tear down the session. If it doesn't because you have another covering route you may want to look at fall-over using a route-map to ensure the neighbor goes down when the fall-over prefix disappears. This is how we do it. BFD is enabled for OSPF and BGP goes down as soon as the route to the endpoint is removed.
|
|
#
?
Nov 10, 2016 02:00
|
|
|
BFD traffic is just UDP, and multihop is supported (in the RFC anyway).
|
|
#
?
Nov 10, 2016 03:58
|
|
|
Multihop BFD seems like some serious dangerous living. Is it?
|
|
#
?
Nov 10, 2016 04:26
|
|
|
I've used it in some inter-AS scenarios where it was the only option for reasonably fast signalling.
|
|
#
?
Nov 10, 2016 15:36
|
|
|
tortilla_chip posted:I've used it in some inter-AS scenarios where it was the only option for reasonably fast signalling. The only application I can really think of would be for non-port channel parallel links doing BGP between loopbacks with static routes to provide load balancing. And in that case wouldn't it be safer to just do BFD on the underlying static routes? -edit- Or I guess it could be useful when you have the old Cogent/current Comcast design where you're doing eBGP with a router 3 hops away because they don't put large RIBs at the edge.
|
|
#
?
Nov 10, 2016 20:51
|
|
|
For some reason I'm having a ton of trouble finding information on this optic. It has a blue release on it which makes me think single mode but I can't find any info on it online. Can anyone tell me if the finisar ftl1323p1btr is multitude or single mode?
|
|
#
?
Nov 22, 2016 21:27
|
|
|
http://www.epsglobal.com/downloads/Finisar/finisar-product-guide-2016.pdf Search for FTLF1323P1xTR
|
|
#
?
Nov 22, 2016 21:35
|
|
|
Trying to hire a good CCNA or a CCNP and our recruiter screens candidates with a small technical test. Its not really a pass or fail thing but its helpful to see if the from the outset if their CV is completely bullshit or if they have extra knowledge in other useful areas like Microsoft and Citrix. Am I a terrible person for throwing this question in? Both computers are part of the same subnet but are in different VLANs. On the basis of the information presented in the diagram, which statement is true about an attempt to ping from host to host?  A – Layer 3 device is needed for the ping command to be successful. B – A trunk port will need to be configured on the link between SA and SB for the ping command to be successful. C – The two different hosts will need to be in the same VLAN in order for the ping command to be successful. D – The ping command will be successful without any further configuration changes. D. Also if any good networking guys are looking for a job for an MSP in the Cambridgeshire/Hertfordshire area, hit me up. If you can do networking & other poo poo (VMware, Microsoft server, Citrix), you are the answer to all of our prayers. Ahdinko fucked around with this message at 16:47 on Nov 30, 2016 |
|
#
?
Nov 30, 2016 16:37
|
|
|
That's a good question and I sort of suspected what you'd done before I saw the diagram.
|
|
#
?
Nov 30, 2016 16:49
|
|
|
CDP and VTP will bitch about an inconsistent VLAN, though. I think that's a perfectly fair question if you're shooting for someone experienced enough for a CCNP. A freshly minted CCNA may not realize it would work, though. They'll see the different VLANs on the switches an automatically jump to the different VLAN answer without stopping to think it's actually passing untagged traffic. I filled an open position a few months ago, my technical questions were what I would expect a CCNA to be able to answer. (Except the BGP question, but that was more to see how they would handle an unfamiliar issue rather than testing any knowledge.)
|
|
#
?
Nov 30, 2016 16:50
|
|
|
Thanks Ants posted:That's a good question and I sort of suspected what you'd done before I saw the diagram. I can't take credit it for it. I'm writing a 20 question exam and I ran out of creativeness about 15 questions in, so I stole the rest of them from the internet and this was one. I just didn't know if it was too much of a "GOTCHA!!!" question. Ants you live in the home counties and do networking don't you? Get out of London and come work with me :P Filthy Lucre posted:CDP and VTP will bitch about an inconsistent VLAN, though. I've got about 5 "general poo poo you should know without even sitting a Cisco exam" questions, 5 CCNA level, 5 CCNP level and 1-2 CCIE level questions, then just a couple of questions aimed at getting a feel for how they handle stuff like your BGP one. I don't expect a single candidate to get them all right, but it can be really handy for getting a feel for what people know before you even commit to interviewing them. Before this I had an ISP network engineer with 5 years experience who listed one of his key strengths as "Routing Protocols", but when I asked him a couple of things like "Tell me a couple of differences between RIP and OSPF" or "how would you enable EIGRP on a cisco router" and he couldn't manage more than a "uhhh...". Alot of CV's out there are just full of poo poo. Ahdinko fucked around with this message at 16:59 on Nov 30, 2016 |
|
#
?
Nov 30, 2016 16:53
|
|
|
I doubled-down and moved further in, also trying to run far away from the MSP world
|
|
#
?
Nov 30, 2016 16:56
|
|
|
My gotcha question for phone interviews was always "What's the subnet mask for a /34?". If people claim to have a CCNA and can't spot the problem there, they're crap.
|
|
#
?
Nov 30, 2016 17:31
|
|
|
When I do interviews I prefer open ended questions for candidates. Generally I whiteboard a diagram with 2 pcs, connected to layer 2 switches, connected to routers with MPLS. I then ask them to tell me all the ways they can configure the links to allow the PCs communicate. It lets you gauge how much they know overall instead of individual concepts.
|
|
#
?
Nov 30, 2016 18:43
|
|
|
I'm not a fan of trick questions in interviews. People are nervous and may miss obvious stuff. It's not bad to ask questions you have specific answers to but personally I always try to follow up answers with questions about how they arrived at their conclusion. Sometimes just asking questions about their process will make the obvious mistake click for them.
|
|
#
?
Nov 30, 2016 18:59
|
|
|
|
| # ? Jun 10, 2024 04:04 |
|
|
n0tqu1tesane posted:My gotcha question for phone interviews was always "What's the subnet mask for a /34?". If people claim to have a CCNA and can't spot the problem there, they're crap. FFFF:FFFF:C0::/34, duh
|
|
#
?
Nov 30, 2016 19:32
|
|
