@Michael-McKenney,

It was the frame-relay switch configuration?

@Daniel-Del-Borrello,

My apologies for not seeing your post here. I'm thinking that we may need a little more information to help out.

If DNS is the issue on the server side, select the other test machine and see if you can use the network utility for a DNS test to the server. If it resolves via hostname the issue is probably more of a client side issue.

If you get a return try to clear the dns cache of the problematic machine and see if that allows you to now connect.

@Michael-McKenney,

Ok. So that leaves you with ONE solution currently with ITProTV which is for you to use practice-labs. I recommend that you take a cisco lab, use NYWAN1, you can configure FR on it. You can turn NYEDGE1 into the DTE for your FR switch.

As I've stated, you're not going to encounter this for CCNA or CCNP R/S. If you see it anywhere it would be for something like the CCNP SP exam. I'm not sure it would even be there now.

@Adam-Tyler,

remember on traffic between vlans. The inbound and outbound terminology are weird. We have to think of directionality for the processing. ip access-group 120_in in when applied to the vlan interface is (from within the VLAN 120 outbound to another) . And ip access-group 120_in out when applied to the vlan interface means (from outside the vlan 120 heading in to the vlan).

so it's a bit twisted in our syntax to the meaning of the ACL.

@Adam-Tyler said in nxos and inter-vlan ACLs:

I also am getting no statistic counters or log entries indicating the rule is being actively applied to packets.

You need at least one permit statement.

SW1# show access-list 120_in

IP access list 120_in
        statistics per-entry
        10 deny ip any any log [match=0]
        20 deny icmp any any log [match=0]
        30 permit ip any any [match=0]

I'm still working the answer for the other part... let me get some more information
are you doing this between vlans on the same switch? or between vlans on different switches?

@Michael-McKenney ,

right, so you've got then two options still

You can work with practice-labs.com . It's CCNP labs already have a FR lab setup. The only time you'll configure a FR switch is on the CCNP Service Provider Exam. So the lab is setup for you to create a frame relay router. But having said that, you can configure the NYWAN1 as a frame-relay switch, it has serial interfaces, you'll have one client NYEDGE1.

If you have a router that is not currently in use that has serial interfaces, you can setup a FR switch on those as well.

@Adam-Tyler said in keychain vs key string?:

You mention that a key-string should not be used in production. Is the key-chain feature specific to the Cisco platform?

I'm not sure if the concept is only specific to Cisco or not. I can only tell you that cisco requires a key-string to be attached to the a key-chain. I'm no so familiar with the sonic firewall.

I am able to get OSPF going with "Message Digest", but the command on the Cisco side I am using on the interface is "ip ospf message-digest-key 1 md5 0 MYKEYSTRINGHERE". This is not recommended? Even though the traffic is technically still traversing an encrypted tunnel?

The use of single key that is unchanging is not recommended in production, even when you're using a VPN tunnel.

Is all of this logic around key-string and key-chain the same for HSRP authentication or do the rules change?

As far as I know, it shouldn't change

So, in a key-chain, the string is processed again within the timeframe you specify to produce a unique authentication string which rotates. Assuming you used the same rotation time and original key-string, each side should get the same result. That sounds all well and good to me, am I on the right track?

Yes

If so, what is the significance of setting a year in your rotation time-frame?
You're just trying to set a temporary key that can only be used for that time period. If you set multiple keys within the key-chain without time, they are all active all the time. I'm not sure how you would make them rotate without the time

Wouldn't you want the key to rotate indefinitely? What happens if the year you use is in the past? Or does the firewall automatically update it as the string is processed?

Yes and no. You do want it to change regularly. No, not indefinitely. You could have a router that loses connection or dies. What happens if the key has changed on one side while the router is down, you're not sure what key it's using at the current time.
Setting a time in the past doesn't affect it, it just goes active from that past date until you set an end date. I'm not sure about what the sonic firewall would do.

In my question 1 above I give an example of a key-string I used to get OSPF authentication working between a Cisco device and a SonicWALL. Can you tell me what the significance of the "1" is in the Cisco command?

It is the key number on the key-chain to be used. So a 1 is the first key on the key-chain.

For example, if I were to run a similar command to get OSPF going on a different interface would it be okay to still use "1", or is that globally applicable beyond the interface somehow? For example, would I need to use "2" if I wanted to use a different key-string on a different interface?

So these authentication commands are on a per interface basis, so a 1 on different interfaces is not necessarily the same as a 1 on another interface.

@Adam-Tyler said in keychain vs key string?:

What is all of this? What is the difference between a keychain and a key-string? If I specify a message-digest-key "1" for an interface to negotiate OSPF, should I not use "1" again? Is there a show that deep dives into this I can watch?

I believe we go over this in the CCNA show (maybe), CCNA Security show and CCNP ROUTE...

But here's a summary
Think of the key-chain as being the container or "set" of keys.
Think of the key-string as the individual "key" can can be used.

Routing authentication relies on a key on keychain to function. Before authentication can be used, a keychain with one one key (minimally) must be created. It's a hierarchy, that allows the association of multiple key-strings to a single key-chain. You set a time send and receive time for each key-string. This is useful if the connection is over a public network so that security keys are changed on a regular basis. Though you can set a single key, this is only good in a testing environment, in a production environment you want the keys to change. This has to be manually done if you only setup one key.

Setting up multiple keys allows routers to to use a single key for a period of time. Then the routers use two keys for a limited period of overlapping time, then use the next key only in key-chain for a period of time, while the first key expired.

e.g.
create what needs to be used for authentication. I created a key-chain and 2 key-

R1#configure terminal
R1(config)#key chain MYCHAIN
R1(config-keychain)#key 1
R1(config-keychain-key)#?
Key-chain key configuration commands:
  accept-lifetime          Set accept lifetime of key
  cryptographic-algorithm  Set cryptographic authentication algorithm
  default                  Set a command to its defaults
  exit                     Exit from key-chain key configuration mode
  key-string               Set key string
  no                       Negate a command or set its defaults
  send-lifetime            Set send lifetime of key
R1(config-keychain-key)#key-string securetraffic1
R1(config-keychain-key)#accept-lifetime 00:00:00 1 April 2019 00:00:00 15 May 2019
R1(config-keychain-key)#send-lifetime 00:00:00 1 April 2019 00:00:00 15 May 2019
R1(config-keychain)#key 2
R1(config-keychain-key)#key-string securetraffic2
R1(config-keychain-key)#accept-lifetime 00:00:00 1 May 2019 00:00:00 15 June 2019
R1(config-keychain-key)#send-lifetime 00:00:00 1 May 2019 00:00:00 15 June 2019
R1#

Apply the Key-Chain to interface to use for authentication

R1#configure terminal
R1(config)#interface g0/0
R1(config-subif)#ip authentication mode eigrp 10 md5
R1(config-subif)#ip authentication key-chain eigrp 10 MYCHAIN
R1(config-subif)#end
R1#

This allows for both keys to be used, the time-limits set on each key-string will tell the router when to use them.

You do the same thing for R2 and the interface that connects to R1. If these do not match key-strings, it will not work.

@Michael-McKenney,

So, if you don't have a cisco contract, you've got the option I mentioned with practice-labs.

If you have a colleague from another company who has cisco contract, you might see if they do and can get an image for you to use educationally.

@Michael-McKenney,

You can only customize the base configuration so much and cannot do a reboot to clear the config. But it's possible.

You just choose the NYWAN1 router as your Frame switch...
choose your interface....
e.g. config...
I think there's a lab that is setup for you to configure this one as a frame relay dte because the frame-switch is already setup...but you can create it using the NYWAN1 serial and using NYEDGE1 serial port

If you want to do a full blown lab you can always use a 7200 vxr IOS15.x image and import that into GNS3 to create your frame switch with serial ports too, which was more realistic.