Save
Saving
  • A
    Adam Tyler

    Hmm... Still no dice.. Starting to wonder if I have buggy firmware or something. These are 9000v VMware virtual machines running in the lab. It was a real trick figuring out how to get a VM on the same VMware host to connect to a switchport on the "virtual" nexus switch. I ended up making a separate VMware vSwitch for each host that needed to connect.

    IP access list 120_in<------------Still not counters..
            statistics per-entry
            8 deny icmp any any log
            9 deny ip any any log
            10 permit ip any any log
            20 permit icmp any any log
    WILNXLAB-01(config)# show run int vlan 120
    
    !Command: show running-config interface Vlan120
    !Running configuration last done at: Fri Apr 12 14:51:50 2019
    !Time: Fri Apr 12 14:52:07 2019
    
    version 7.0(3)I7(6) Bios:version
    
    interface Vlan120
      no shutdown
      ip access-group 120_in in
      ip access-group 120_out out
    

    Outbound seems to work exactly as expected.... WEIRD!

    WILNXLAB-01(config)# show ip access-lists 120_out
    IP access list 120_out
            statistics per-entry
            10 remark ------Allow file sharing return traffic to VLAN 120
            20 permit udp 192.168.119.0/24 eq netbios-ss 192.168.120.0/24 [match=0]
            30 permit udp 192.168.119.0/24 eq netbios-ns 192.168.120.0/24 [match=0]
            40 permit tcp 192.168.119.0/24 eq 137 192.168.120.0/24 [match=0]
            50 permit tcp 192.168.119.0/24 eq 135 192.168.120.0/24 [match=0]
            60 permit tcp 192.168.119.0/24 eq 139 192.168.120.0/24 [match=0]
            70 permit tcp 192.168.119.0/24 eq 445 192.168.120.0/24 [match=9326]
            80 remark ------Allow echo to VLAN 120
            90 permit icmp 192.168.119.0/24 any echo [match=0]
            100 remark ------Allow echo reply traffic to VLAN 120
            110 permit icmp any any echo-reply [match=83322]
            120 remark ------Allow ospf
            130 permit ospf any any [match=0]
            140 remark ------Deny everthing else
            150 deny ip any any [match=18]
    

    posted in Cisco read more
  • A
    Adam Tyler

    Thank you Ronnie, I am actually going through CCNP route now. I have about a year before my CCNA cert expires. I don't recall seeing this information in the CCNA course, but it has been a while for me. I had a couple of follow up questions regarding the info you provided.

    1. You mention that a key-string should not be used in production. Is the key-chain feature specific to the Cisco platform? I am trying to deploy OSPF in our environment with SonicWALL firewalls using tunnel interfaces (VPN). They don't offer much in the way of authentication for OSPF.. Take a look at their options..
      alt text

    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?

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

    2. 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? 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?

    3. 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? 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?

    "ip ospf message-digest-key 1 md5 0 MYKEYSTRINGHERE"

    posted in Cisco read more
  • A
    Adam Tyler

    Thanks Ronnie, I am following the logic. Based on the article and your comments, it sounds like perhaps it's suggested that the ACL is simply built incorrectly to successfully apply inbound? Just to 100% confirm, I went ahead and created a new ACL that shows as follows:

    ip access-list 120_in
      statistics per-entry
      10 deny ip any any log
      20 deny icmp any any log
    

    After applying this to interface vlan 120 "in", ICMP still happily flows between hosts on VLAN 120 and VLAN 1. Did I miss something, because this is still not making any sense to me... This rule should block inbound echo from VLAN 120...? It should not apply to echo-reply coming from 119.

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

    Regards,
    Adam Tyler

    posted in Cisco read more
  • A
    Adam Tyler

    Hello ITPro.. Wondering if someone can explain to me the difference between a keychain vs a key-string in the Cisco world? I am a bit confused. I am working with the NX OS platform and it looks like you have quite a few options for authenticating OSPF or HSRP for example...

    Here are some OSPF options for authentication from the CLI:

    WILNXLAB-02(config-if)# ip ospf ?
      authentication       Authentication on the interface
      authentication-key   Configure the authentication key for the interface
      message-digest-key   Message digest authentication password (key)
    
    WILNXLAB-02(config-if)# ip ospf authentication?
      authentication      Authentication on the interface
      authentication-key  Configure the authentication key for the interface
    
    WILNXLAB-02(config-if)# ip ospf authentication-key ?
      0     Specifies an UNENCRYPTED authentication key will follow
      3     Specifies an 3DES ENCRYPTED authentication key will follow
      7     Specifies a Cisco type 7  ENCRYPTED authentication key will follow
      LINE  The UNENCRYPTED (cleartext) authentication key
    
    WILNXLAB-02(config-if)# ip ospf message-digest-key ?
      <0-255>  Key ID
    

    For HSRP you have a bunch of options too:

    WILNXLAB-02(config-if-hsrp)# ?
      authentication  Authentication
     
    WILNXLAB-02(config-if-hsrp)# authentication ?
      WORD  Plain text authentication string (Max Size 8)
      md5   Use MD5 authentication
      text  Plain text authentication
    
    WILNXLAB-02(config-if-hsrp)# authentication md5 ?
      key-chain   Set key chain
      key-string  Set key string
    
    WILNXLAB-02(config-if-hsrp)# authentication md5 key-chain
      WORD  Name of key-chain (Max Size 250)
    
    

    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?

    Regards,
    Adam Tyler

    posted in Cisco read more
  • A
    Adam Tyler

    Thanks Ronnie. I did actually try the permit statements on the VACL approach too. I've tried a bunch of combinations now and the only thing I can seem to get working reliably is as follows..

    This allows anything on the 192.168.119.0/24 network to ping anything on the 192.168.120.0/24 network as well as the reverse. It ONLY allows hosts on the 192.168.120.0/24 network to access SMB shares hosted on the 192.168.119.0/24 network (VLAN1). Additionally all other traffic is blocked. I am able to enable "statistics per-entry" and see the hit counter of the "deny ip any any" entry increment. Again, it only ever seems to block traffic "egressing/out" to its final destination.

    ip access-list 120_out
      statistics per-entry
      10 remark ------Allow file sharing return traffic to VLAN 120
      20 permit udp 192.168.119.0/24 eq netbios-ss 192.168.120.0/24
      30 permit udp 192.168.119.0/24 eq netbios-ns 192.168.120.0/24
      40 permit tcp 192.168.119.0/24 eq 137 192.168.120.0/24
      50 permit tcp 192.168.119.0/24 eq 135 192.168.120.0/24
      60 permit tcp 192.168.119.0/24 eq 139 192.168.120.0/24
      70 permit tcp 192.168.119.0/24 eq 445 192.168.120.0/24
      80 remark ------Allow echo to VLAN 120
      90 permit icmp 192.168.119.0/24 any echo
      100 remark ------Allow echo reply traffic to VLAN 120
      110 permit icmp any any echo-reply
      120 remark ------Allow ospf
      130 permit ospf any any
      140 remark ------Deny everthing else
      150 deny ip any any
    ip access-list 1_out
      statistics per-entry
      10 remark ------Allow file sharing to VLAN 1
      20 permit udp 192.168.120.0/24 192.168.119.0/24 eq netbios-ss
      30 permit udp 192.168.120.0/24 192.168.119.0/24 eq netbios-ns
      40 permit tcp 192.168.120.0/24 192.168.119.0/24 eq 445
      50 permit tcp 192.168.120.0/24 192.168.119.0/24 eq 139
      60 permit tcp 192.168.120.0/24 192.168.119.0/24 eq 135
      70 permit tcp 192.168.120.0/24 192.168.119.0/24 eq 137
      80 remark ------Allow echo to VLAN 1
      90 permit icmp 192.168.120.0/24 any echo
      100 remark ------Allow echo reply traffic to VLAN1
      110 permit icmp any any echo-reply
      120 remark ------Allow ospf
      130 permit ospf any any
      140 remark ------Deny everything else
      150 deny ip any any
    
    interface Vlan1
      ip access-group 1_out out
    
    interface Vlan120
      ip access-group 120_out out
    

    So it's a mystery as to why ACLs only seem to work when applied to each interface "out" instead of "in". Any ideas on that one?

    Additionally I did a ton of testing with the "established" ACL option trying to get the switch to respect return flow at least for TCP traffic. For example: 40 permit tcp 192.168.120.0/24 192.168.119.0/24 eq 445 established. This unfortunately never worked. I am surprised the Nexus doesn't seem to support session aware ACLs?

    Why didn't the VACL work? I was reading an article recently about VACLs and there was some confusion around the VACL applying to traffic within the same VLAN only vs routed/inter-vlan traffic..

    Thanks for your help and thoughts.

    Regards,
    Adam Tyler

    posted in Cisco read more
  • A
    Adam Tyler

    Thanks Ronnie, you are tracking right with me. I thought of using VACL's too, but I can't get it work for some reason. Here is the output from "show run aclmgr" after entering your commands. Both workstations can still connect via ping and SMB with this configuratoin, just tested.. The heck?

    WILNXLAB-01(config)# show run aclmgr
    
    !Command: show running-config aclmgr
    !Running configuration last done at: Tue Apr  9 13:49:37 2019
    !Time: Tue Apr  9 13:49:40 2019
    
    version 7.0(3)I7(6) Bios:version
    ip access-list DENY_ACL_MAP
      10 deny ip 192.168.120.0/24 any
      20 deny icmp 192.168.120.0/24 any
      30 permit ip any any
    vlan access-map DENY_TEST 10
      match ip address DENY_ACL_MAP
      action drop
    vlan filter DENY_TEST vlan-list 120
    
    WILNXLAB-02(config)# show run aclmgr
    
    !Command: show running-config aclmgr
    !Running configuration last done at: Tue Apr  9 13:49:33 2019
    !Time: Tue Apr  9 13:49:52 2019
    
    version 7.0(3)I7(6) Bios:version
    ip access-list DENY_ACL_MAP
      10 deny ip 192.168.120.0/24 any
      20 deny icmp 192.168.120.0/24 any
      30 permit ip any any
    vlan access-map DENY_TEST 10
      match ip address DENY_ACL_MAP
      action drop
    vlan filter DENY_TEST vlan-list 120
    

    alt text

    posted in Cisco read more
  • A
    Adam Tyler

    Hello ITPro. I am pulling my hair out trying to figure out how ACLs work on the nxos platform with inter-vlan routing. Hoping someone with experience can explain to me why with the following configuration, packets from source 192.168.120.0/24 are not blocked when destined for the 192.168.119.0/24 network.

    Note, this is an HSRP setup, so two switches sharing virtual IP for gateway on both vlans.

    WILNXLAB-01:
    interface Vlan1
      no shutdown
      ip address 192.168.119.3/24
      hsrp version 2
      hsrp 119
        preempt
        priority 90
        ip 192.168.119.2
        track 119
        track 120
        track 121
        track 122
    
    
    interface Vlan120
      no shutdown
      ip access-group test in <-----------enable ACL
      ip address 192.168.120.3/24
      hsrp version 2
      hsrp 120
        preempt
        priority 90
        ip 192.168.120.2
        track 119
        track 120
        track 121
        track 122	WILNXLAB-02:
    
    WILNXLAB-02:
    interface Vlan1
      no shutdown
      ip address 192.168.119.4/24
      hsrp version 2
      hsrp 119
        preempt
        priority 80
        ip 192.168.119.2
        track 119
        track 120
        track 121
        track 122
    
    
    interface Vlan120
      no shutdown
      ip access-group test in <-----------enable ACL
      ip address 192.168.120.4/24
      hsrp version 2
      hsrp 120
        preempt
        priority 80
        ip 192.168.120.2
        track 119
        track 120
        track 121
        track 122
    
    ---------------------Access List on each switch
    IP access list test
            10 deny ip 192.168.120.0 0.0.0.255 any
            20 deny icmp 192.168.120.0 0.0.0.255
    

    posted in Cisco read more
  • A
    Adam Tyler

    So I just discovered that a superscope can be used to group multiple DHCP scopes to assign IP addresses on the same network segment. WHAT? This has always been a no no in my experience. Can someone explain to me how the heck a client on the same physical broadcast domain (network segment) knows what scope to receive an IP address from in this scenario?

    Found this description online
    "Superscopes are also used to support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) on which multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are called multinets"

    Regards,
    Adam Tyler

    posted in Microsoft read more
  • A
    Adam Tyler

    Thanks Ronnie. Just read through that article. It covers three points... The first to configure a VLAN tag on the external virtual switch. My understanding of this setting is that it only exists to allow the "host" operating system to drop into a particular VLAN for management purposes only. In my lab, the VLAN setting on the virtual switch is titled "Enable virtual LAN identification for management operating system".

    The second point discusses setting a VLAN tag on the VMs vNIC. This would allow the VM to send tagged packets using the VLAN specified. Which would only work between physical hosts if the physical switchport was configured as a trunk. Correct?

    The third point discusses a couple of options if the VM needs to use more than one VLAN. option 1 is to add more than one vNIC with a different VLAN specified. Again, this would only work between physical hosts if the physical switchport was configured as a trunk.. Correct?

    Option 2 is configure the VMs vNIC as a trunk using the special super secret hidden command: Set-VMNetworkAdapterVlan... However this would also require that the physical switchport be configured as a trunk for VMs between hosts to communicate. It would also require that the guest VM OS tag the traffic prior to entering the vSwitch.

    Am I close?

    Regards,
    Adam Tyler

    posted in Microsoft read more