Ronnie Wong has worked from a service truck; he's delivered chinese food; he's been a minister and worked doing some computer repair and network administrator for a couple of small companies. Most recently, before ITProTV, he's been a certified technical instructor helping people learn applications, operating systems and even networking equipment. He's led Cisco, Microsoft Windows, CompTIA and IT security training for the US Army 7th SFG, the US Air Force Special Operations Group before their deployment around world and DoD at Ft. Lee.
He takes a special interest in Networking Technology and tries his best to work a good generalist in the IT field. By far, he considers himself to be the least qualified of the ITProTV team because he sees the talented people he works with daily.
**if the post above has answered the question, please mark the topic as solved.
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.
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.
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 inwhen applied to the vlan interface is (from within the VLAN 120 outbound to another) . And
ip access-group 120_in outwhen 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.
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?
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.
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?
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
1is 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
1on different interfaces is not necessarily the same as a
1on another interface.
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-chainas being the container or "set" of keys.
Think of the
key-stringas the individual "key" can can be used.
Routing authentication relies on a
key on keychainto 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-stringsto 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-chainfor a period of time, while the first key expired.
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.
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....
I think there's a lab that is setup for you to configure this one as a frame relay
dtebecause 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.