switch to room list switch to menu My folders
Go to page: 1 2 3 4 5 [6]
[#] Wed Aug 03 2016 09:23:57 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well I was actually just issuing some dry humor there, but now I'm going to have to try using .0 and see if it works.

Of course, if you want to confuse the heck out of people, use .0 or .255 in a network that's bigger than /24. For example, or
That'll quickly call out the people who don't know how to think in CIDR and only understand octets. (ProTip: these are the same dweebs who still refer to a /24 network as "a Class C," particularly when they are requesting /24 of public IPv4 space for their rack of three servers. Not gonna happen in 2016.)

[#] Thu Aug 04 2016 03:50:54 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've seen it used successfully in a class before. It gave me a double-take, as it isn't very conventional.

[#] Fri Sep 02 2016 09:41:15 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Someone just asked me what route metrics to use to get hosts on a network talking over a VPN to hosts on a remote network.

The labor day weekend drinking is going to have to start early, I think.

[#] Fri Sep 02 2016 10:50:06 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Use the auto-recombobulator with transparent bidirectional DS-NAT. And then punch the dumb fuck in the face.

[#] Mon Sep 12 2016 13:32:34 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hmmmm... tricky...

[#] Mon Sep 12 2016 14:15:07 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The punching or the DS-NAT?

[#] Wed Sep 14 2016 10:26:09 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

DS-NAT. Punching is straightforward, unless you plan to use a right hook.

[#] Tue Oct 04 2016 22:09:31 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

omg, this was such a frustrating problem, but the solution was so interesting I've got to share it.

We replaced a Cisco 2811 router with a Fortigate 240D. It handles routing between a number of IP networks at a site, with one handoff to a WAN. In the not too distant future it'll replace the site's Internet firewall as well, but that hasn't been done yet.

Complaint received the next day: the network staff can't reach about a dozen Cisco ethernet switches at their admin addresses. The switches are carrying layer 2 traffic just fine, so there isn't any outage, but the switches can't be reached for maintenance. Interestingly, they are still reachable when we go to another device on the same subnet and ping or ssh over to them.

"It's all the switches in building XX," they said. Nope, I found switches in building YY that are unreachable, and switches in building XX that are reachable.

"The Fortigate can't handle multinetted interfaces properly," they said.
(Yes, that interface was multinetted; the reason is legit but irrelevant.)
Well, I was willing to believe that, but couldn't prove it, since *most* of the things on there were working.

IP address conflict? Nope. Checked that. MAC address conflict? Nope.

While trying to figure out WTF, I changed the IP addresses of one of the problem devices to an address on the router interface's primary address, thinking it was a problem with that. Didn't fix it. But then the NOC said the device started alerting in monitoring. What? How was it working in monitoring when it wasn't working anywhere else?

I got a packet trace going on the Fortigate. (Note: Fortinet's on-router sniffer BLOWS AWAY anything Cisco has.) Got a continuous ping going from my laptop to the device in question. And I see the device issuing ARP requests for hosts that are *not* on its local management network. Again ... WTF?!? Then ... since I'm so old-skool, I noticed that these requests were only being issued for hosts on the SAME CLASSFUL NETWORK (10.x.x.x).

So I stared at the configuration some more. And then it hit me:

ip route

The specified gateway was correct ... but this statement wasn't doing a damn thing. It wasn't working. And it had *never* worked. I changed it to:

ip default-gateway

And ... BOOM. Reachable from everywhere. So why was the device reachable before we changed the upstream router?

The device is a Catalyst 3750. I went down the list, and found that every unreachable device was a 3750, and they all had "ip route 10.x.x.x" statements. That's how you set the default gateway when the device is running in Layer 3 routing mode. These aren't. When IP is only used for management, you have to use the "ip default-gateway 10.x.x.x" command. So again, why was it working before?

There is ancient code in the IOS IP stack, which makes it try things like ARP and CDP to find a way off the local network when the default gateway is not specified. The old Cisco router was answering those requests and supplying us with the default gateway. Like I said, the "ip route" command was there, but it wasn't being honored. It was working for the wrong reason.

[#] Tue Oct 04 2016 22:31:52 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I started using Fortinet's a couple of years ago. They rock.

[#] Wed Oct 05 2016 20:07:07 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You're supposed to be praising my net-fu, not the Fortinets. But yeah, they're pretty cool. They take some time to get used to. But they present a more rigid configuration model that I think forces you to build better networks.

[#] Thu Oct 06 2016 07:13:43 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Damn, but that's subtle. Good work.

Go to page: 1 2 3 4 5 [6]