NTP - ACL

NTP - Network Time Protocol

Packet types:

- Control messages : don't bother with this.
- NTP request/update messages: used for time synchrnonization

You can define ACL to protect your infrastructure:

Cisco defines 4 Access Control :

- Peer: 

    The router responds to NTP Request, Accepts NTP Updates and NTP Control Queries.

    This is where you filter from where you want to sync ! 

- Serve: 

    The router reponds to NTP Request, Accepts NTP Control Queries.

- Serve-only:

    The router responds to NTP Requests Only. 

    Won't synchronize local system time.

- Query-only: 

    The router only accepts NTP control queries. 

    No response to NTP requests are sent, no local system time synchronization with remote system is permitted.

So basically, 

- If you want your router to only synchronize to NTP Servers :

    - Peer ACL is configured with the IP Address of the NTP Servers.

    - Server, Serve-only and Query-only ACLs are denying everything.

That is:

!

access-list 1 remark utility ACL to block everything

access-list 1 deny any

!

access-list 10 remark NTP peers/servers we sync to/with

access-list 10 permit 185.156.175.251

access-list 10 permit 80.67.184.4

access-list 10 permit 134.59.1.5

access-list 10 deny any

!

ntp access-group query-only 1   ! deny all NTP control queries

ntp access-group serve 1        ! deny all NTP time and control queries by default

ntp access-group peer 10        ! permit time sync to configured peer(s)/server(s) only

ntp access-group serve-only 1 ! deny NTP time sync requests from potential clients

!

- If you want to router to synchronize to NTP Servers and be an NTP Server:

    - Peer ACL is configured with the IP Address of the NTP Servers.

    - Serve-only ACL is configured with the IP Address of your clients.

    - Server and Query-only ACLs are denying everything.

That is:

!

access-list 1 remark utility ACL to block everything

access-list 1 deny any

!

access-list 10 remark NTP peers/servers we sync to/with

access-list 10 permit 185.156.175.251

access-list 10 permit 80.67.184.4

access-list 10 permit 134.59.1.5

access-list 10 deny any

!

access-list 20 remark Hosts/Networks we allow to get time from us

access-list 20 permit 192.168.0.0 0.0.0.255

!

ntp access-group query-only 1   ! deny all NTP control queries

ntp access-group serve 1        ! deny all NTP time and control queries by default

ntp access-group peer 10        ! permit time sync to configured peer(s)/server(s) only

ntp access-group serve-only 20  ! permit NTP time sync requests from a select set of clients

!

ntp server ip ntp.deuza.net minpoll 10

ntp server ip ntp.midway.ovh minpoll 10

ntp server ip ntp.unice.fr minpoll 10 prefer source Vlan1

IOS router may associate an access-list with any of the above access-types, classifying NTP message sources by their types. Two rules are observed by IOS when an incoming NTP packet is matched against configured types of access:

1) All access-groups associated with access types are scanned in the ordrer presented above (from 1 to 4) – that is, following from most permissive to most restrictive. The first match is used to determine the message source access type.
2) If any of the access types has been defined with an ACL, all other access types are implicitly denied. Just by restricting some sources, you may effectively block all others as well

Now here is a catch. If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:

ENCOR - PART 1 – NETWORK INFRASTRUCTURE

Switched Campus

Switch Administration

Managing MAC address Table

MAC Address Table and VLANs

All MAC Addresses are associated with a VLAN and an address can exist in more than one VLAN.

Each VLAN maintains its own logical address table.

When private VLANs are configured, address learning depends on the type of MAC address:

-        Dynamic MAC addresses learned in one VLAN of a private VLAN are replicated in the associated VLANs.

-        Static MAC addresses configured in a primary or secondary VLAN are not replicated in the associated VLANs. When you configure a static MAC address in a private VLAN primary or secondary VLAN, you should also configure the same static MAC address in all associated VLANs.

Feature:	Default Settings:
Aging Time	300 seconds or 5 minutes
Dynamic Address	Automatically Learned
Static Address	None configured

Commands:

mac address-table aging-time [ 0 | 10-1000000 ] [ vlan vlan-id ]

show mac address-table aging-time

Remove Dynamic MAC Address Entries

 

Remove Dynamic MAC Address Entries

 

clear mac address-table dynamic

clear mac address-table dynamic address mac-address

clear mac address-table dynamic interface interface-id

clear mac address-table dynamic vlan vlan-id

 

MAC Address Change Notification Traps

 

MAC address change notification tracks users on a network by storing the MAC address change activity.

When the switch learns or removes a MAC address, an SNMP notification trap can be sent. 

 

Commands:

 

snmp-server enable traps mac-notification change

mac address-table notification change

mac address-table notification change [ interval value ] [ history-size value ]

 

Then, you configure per interface: 

interface GigabitEthernet0/1

 snmp trap mac-notification change { added | removed }

 

Below shows how to specify 172.20.10.10 as the NMS, enable the switch to send MAC address notification traps to the NMS, enable the MAC address-change notification feature, set the interval time to 123 seconds, set the history-size to 100 entries, and enable traps whenever a MAC address is added on the specified port.

Switch(config)# snmp-server host 172.20.10.10 traps private mac-notification 

Switch(config)# snmp-server enable traps mac-notification change 

Switch(config)# mac address-table notification change 

Switch(config)# mac address-table notification change interval 123 

Switch(config)# mac address-table notification change history-size 100 

Switch(config)# interface gigabitethernet1/0/2 

Switch(config-if)# snmp trap mac-notification change added 

 

Client/Server Python (works with VIRL)

Small Python Client/Server Application

Client

#!/usr/bin/env python

import socket

TCP_IP = '10.0.0.10'

TCP_PORT = 21

BUFFER_SIZE = 1024

MESSAGE = "Hello, World!"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect((TCP_IP, TCP_PORT))

s.send(MESSAGE)

data = s.recv(BUFFER_SIZE)

s.close()

print "received data:", data

Server

#!/usr/bin/env python

import socket

TCP_IP = '10.0.0.14'

TCP_PORT = 21

BUFFER_SIZE = 20  # Normally 1024, but we want fast response

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.bind((TCP_IP, TCP_PORT))

s.listen(1)

conn, addr = s.accept()

print 'Connection address:', addr

while 1:

    data = conn.recv(BUFFER_SIZE)

    if not data: break

    print "received data:", data

    conn.send(data)  # echo

conn.close()

Start Server

cisco@server-2:~$ sudo python server.py

Start Client Side

cisco@server-1:~$ sudo python client.py 

received data: Hello, World!

cisco@server-1:~$ 

Result on Server Side

cisco@server-2:~$ sudo python server.py 

Connection address: ('10.0.0.6', 38522)

received data: Hello, World!

cisco@server-2:~$

BGP & Tunneling

R1 is in AS1, R5 in AS5.

R2, R3 and R4 are in AS234.

R1 has an eBGP session with R2.

R5 has an eBGP session with R4.

EIGRP is configured inside AS234.

To allow R1 Loopback0 to reach R5 Loopback0, we must establish an iBGP session between R2 ans R4.

We will use a GRE Tunnel between R2 and R4:

R1:
!
hostname r1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Serial1/0
 ip address 10.150.12.1 255.255.255.0
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.150.12.2 remote-as 234
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.150.12.2
!

On R5:

!
hostname r5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Serial1/0
 ip address 10.150.45.5 255.255.255.0
!
router bgp 5
 no synchronization
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 network 5.5.5.5 mask 255.255.255.255
 neighbor 10.150.45.4 remote-as 234
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.150.45.4
!


On R3:

!
hostname r3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Serial1/0
 ip address 10.150.23.3 255.255.255.0
!
interface Serial1/1
 ip address 10.150.34.3 255.255.255.0
!
router eigrp 1
 network 3.3.3.3 0.0.0.0
 network 10.150.23.3 0.0.0.0
 network 10.150.34.3 0.0.0.0
 no auto-summary
 eigrp router-id 3.3.3.3
!

On R2:

!
hostname r2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
 ip address 10.150.24.2 255.255.255.0
 tunnel source 2.2.2.2
 tunnel destination 4.4.4.4
!
interface Serial1/0
 ip address 10.150.12.2 255.255.255.0
!
interface Serial1/1
 ip address 10.150.23.2 255.255.255.0
!
router eigrp 1
 network 2.2.2.2 0.0.0.0
 network 10.150.23.2 0.0.0.0
 no auto-summary
 eigrp router-id 2.2.2.2
!
router bgp 234
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 10.150.12.1 remote-as 1
 neighbor 10.150.24.4 remote-as 234
 neighbor 10.150.24.4 update-source Tunnel0
 neighbor 10.150.24.4 next-hop-self
 no auto-summary
!

On R4:

!
hostname r4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Tunnel0
 ip address 10.150.24.4 255.255.255.0
 tunnel source 4.4.4.4
 tunnel destination 2.2.2.2
!
interface Serial1/0
 ip address 10.150.34.4 255.255.255.0
!
interface Serial1/1
 ip address 10.150.45.4 255.255.255.0
!
router eigrp 1
 network 4.4.4.4 0.0.0.0
 network 10.150.34.4 0.0.0.0
 no auto-summary
 eigrp router-id 4.4.4.4
!
router bgp 234
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 shutdown
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 10.150.24.2 remote-as 234
 neighbor 10.150.24.2 update-source Tunnel0
 neighbor 10.150.24.2 next-hop-self
 neighbor 10.150.45.5 remote-as 5
 no auto-summary
!


We have the same result by establishing a session between R2 and R4 Loopback0...

BGP - Synchronization

Synchronization Before the discussion of synchronization, look at this scenario. RTC in AS300 sends updates about 170.10.0.0. RTA and RTB run iBGP, so RTB gets the update and is able to reach 170.10.0.0 via next hop 2.2.2.1. Remember that the next hop is carried via iBGP. In order to reach the next hop, RTB must send the traffic to RTE. Assume that RTA has not redistributed network 170.10.0.0 into IGP. At this point, RTE has no idea that 170.10.0.0 even exists. If RTB starts to advertise to AS400 that RTB can reach 170.10.0.0, traffic that comes from RTD to RTB with destination 170.10.0.0 flows in and drops at RTE. Synchronization states that, if your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all the routers in your AS have learned about the route via IGP. BGP waits until IGP has propagated the route within the AS. Then, BGP advertises the route to external peers. In the example in this section, RTB waits to hear about 170.10.0.0 via IGP. Then, RTB starts to send the update to RTD. You can make RTB think that IGP has propagated the information if you add a static route in RTB that points to 170.10.0.0. Make sure that other routers can reach 170.10.0.0. Disable Synchronization In some cases, you do not need synchronization. If you do not pass traffic from a different AS through your AS, you can disable synchronization. You can also disable synchronization if all routers in your AS run BGP. The disablement of this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly. The disablement of synchronization is not automatic. If all your routers in the AS run BGP and you do not run IGP at all, the router has no way to know. Your router waits indefinitely for an IGP update about a certain route before the router sends the route to external peers. You have to disable synchronization manually in this case so that routing can work correctly: router bgp 100 no synchronization Note: Make sure that you issue the clear ip bgp address command to reset the session. RTB# router bgp 100 network 150.10.0.0 neighbor 1.1.1.2 remote-as 400 neighbor 3.3.3.3 remote-as 100 no synchronization !--- RTB puts 170.10.0.0 in its IP routing table and advertises the network !--- to RTD, even if RTB does not have an IGP path to 170.10.0.0. RTD# router bgp 400 neighbor 1.1.1.1 remote-as 100 network 175.10.0.0 RTA# router bgp 100 network 150.10.0.0 neighbor 3.3.3.4 remote-as 100

IPv6 - Frame-Relay #1

There is no Frame-Relay inarp mechanism for IPv6 in IOS.
We must use static l3 to l2 mapping:


!
hostname r1
!

interface Serial1/0
 no ip address
 encapsulation frame-relay
 ipv6 address 2001:CC1E::/64 eui-64
 ipv6 enable
 serial restart-delay 0
!


Gives us the IPv6 address:



r1#sh ipv6 interface brief s1/0
Serial1/0                  [up/up]
    FE80::C800:32FF:FE45:0
    2001:CC1E::C800:32FF:FE45:0
!


On r2:

!

hostname r2

!

interface Serial1/0

 no ip address

 encapsulation frame-relay

 ipv6 address 2001:CC1E::/64 eui-64

 ipv6 enable

 serial restart-delay 0

!

Gives us the IPv6 address:

r2#sh ipv6 interface brief s1/0

Serial1/0                  [up/up]

    FE80::C801:32FF:FE45:0

    2001:CC1E::C801:32FF:FE45:0

!

Now, we can configure the mapping:


On r1:

!

interface Serial1/0

 frame-relay map ipv6 2001:CC1E::C801:32FF:FE45:0 102

!

r1#show frame-relay map

Serial1/0 (up): ipv6 2001:CC1E::C801:32FF:FE45:0 dlci 102(0x66,0x1860), static,

              CISCO, status defined, active

And, on r2:

!

interface Serial1/0

 frame-relay map ipv6 2001:CC1E::C800:32FF:FE45:0 102

!

r2#show frame-relay map 

Serial1/0 (up): ipv6 2001:CC1E::C800:32FF:FE45:0 dlci 201(0xC9,0x3090), static,

              CISCO, status defined, active

It works:

r1#ping ipv6 2001:CC1E::C801:32FF:FE45:0 source 2001:CC1E::C800:32FF:FE45:0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:CC1E::C801:32FF:FE45:0, timeout is 2 seconds:

Packet sent with a source address of 2001:CC1E::C800:32FF:FE45:0

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/24 ms

r1#

And:

r2#ping ipv6 2001:CC1E::C800:32FF:FE45:0 source 2001:CC1E::C801:32FF:FE45:0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:CC1E::C800:32FF:FE45:0, timeout is 2 seconds:

Packet sent with a source address of 2001:CC1E::C801:32FF:FE45:0

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/24 ms

r2#

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


IPv6 with point to point subifs works the same way.
Just specify the dlci (frame-relay interface-dlci 201 on r2, 102 on r1).

Policy Routing w/ Tracking objects

Reliable Policy Routing

R5 has two loopbacks, 5.5.5.5/32 and 55.55.55.55/32

Configure policy routing on r2 so that:

 - to reach 5.5.5.5/32 packets from r1 must go to r3.

 - to reach 55.55.55.55/32 packets from r1 must go to r4.

 - do not use static routing on r2 (excepted to reach r1).

Use reliable routing to do this:

 - if r3 is not reachable, packets to 5.5.5.5/32 must go through r4.

 - if r4 is not reachable, packets to 55.55.55.55/32 must go through r3.

Verify using traceroute.

r1 configuration:

!

hostname r1

!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface Serial1/0

 ip address 192.168.12.1 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 192.168.12.2

!

r2 configuration:

!

hostname r2

!

track 5 ip sla 10

!

track 55 ip sla 15

!

interface Serial1/0

 ip address 192.168.12.2 255.255.255.0

 ip policy route-map PBR

!

interface Serial1/1

 ip address 192.168.23.2 255.255.255.0

 serial restart-delay 0

!

interface Serial1/2

 ip address 192.168.24.2 255.255.255.0

!

ip route 1.1.1.1 255.255.255.255 192.168.12.1

!

ip sla 10

 icmp-echo 192.168.23.3 source-interface Serial1/1

 timeout 1000

 threshold 1000

 frequency 2

ip sla schedule 10 life forever start-time now

ip sla 15

 icmp-echo 192.168.24.4 source-interface Serial1/2

 timeout 1000

 threshold 1000

 frequency 2

ip sla schedule 15 life forever start-time now

access-list 105 permit ip any host 5.5.5.5

access-list 155 permit ip any host 55.55.55.55

!

route-map PBR permit 10

 match ip address 105

 set ip next-hop verify-availability 192.168.23.3 1 track 5

 set ip default next-hop 192.168.24.4

!

route-map PBR permit 20

 match ip address 155

 set ip next-hop verify-availability 192.168.24.4 1 track 55

 set ip default next-hop 192.168.23.3

!

r3 configuration:

!

hostname r3

!

interface Serial1/0

 ip address 192.168.23.3 255.255.255.0

!

interface Serial1/1

 ip address 192.168.35.3 255.255.255.0

!

ip route 1.1.1.1 255.255.255.255 192.168.23.2

ip route 5.5.5.5 255.255.255.255 192.168.35.5

ip route 55.55.55.55 255.255.255.255 192.168.35.5

!

r4 configration:

!

hostname r4

!

interface Serial1/0

 ip address 192.168.24.4 255.255.255.0

!

interface Serial1/1

 ip address 192.168.45.4 255.255.255.0

!

ip route 1.1.1.1 255.255.255.255 192.168.24.2

ip route 5.5.5.5 255.255.255.255 192.168.45.5

ip route 55.55.55.55 255.255.255.255 192.168.45.5

!

r5 configuration:

!

hostname r5

!

interface Loopback0

 ip address 5.5.5.5 255.255.255.255

!

interface Loopback1

 ip address 55.55.55.55 255.255.255.255

!

interface Serial1/0

 ip address 192.168.35.5 255.255.255.0

!

interface Serial1/1

 ip address 192.168.45.5 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 192.168.45.4

!

Verifications:

r1#traceroute 5.5.5.5 source 1.1.1.1    

Type escape sequence to abort.

Tracing the route to 5.5.5.5

  1 192.168.12.2 8 msec 24 msec 20 msec

  2 192.168.23.3 20 msec 44 msec 44 msec

  3 192.168.35.5 76 msec *  64 msec

r1#traceroute 55.55.55.55 source 1.1.1.1

Type escape sequence to abort.

Tracing the route to 55.55.55.55

  1 192.168.12.2 24 msec 20 msec 20 msec

  2 192.168.24.4 20 msec 44 msec 40 msec

  3 192.168.45.5 80 msec *  76 msec

Now, on r3, remove IP address 192.168.23.3:

On r2, you see :

Feb 23 01:06:28.127: %TRACKING-5-STATE: 5 ip sla 10 state Up->Down

r1#traceroute 5.5.5.5 source 1.1.1.1

Type escape sequence to abort.

Tracing the route to 5.5.5.5

  1 192.168.12.2 16 msec 24 msec 20 msec

  2 192.168.24.4 24 msec 36 msec 44 msec

  3 192.168.45.5 76 msec *  72 msec

r1#traceroute 55.55.55.55 source 1.1.1.1

Type escape sequence to abort.

Tracing the route to 55.55.55.55

  1 192.168.12.2 24 msec 20 msec 24 msec

  2 192.168.24.4 36 msec 24 msec 44 msec

  3 192.168.45.5 76 msec *  76 msec

Note:

If you remove IP 192.168.24.4 on r4, configure the default route in r5 via r3...

On r3, add IP address 192.168.23.3:

On r2, you see:

Feb 23 01:10:18.127: %TRACKING-5-STATE: 5 ip sla 10 state Down->Up

r1#traceroute 5.5.5.5 source 1.1.1.1    

Type escape sequence to abort.

Tracing the route to 5.5.5.5

  1 192.168.12.2 28 msec 16 msec 24 msec

  2 192.168.23.3 24 msec 40 msec 40 msec

  3 192.168.35.5 80 msec *  64 msec

r1#traceroute 55.55.55.55 source 1.1.1.1

Type escape sequence to abort.

Tracing the route to 55.55.55.55

  1 192.168.12.2 20 msec 20 msec 24 msec

  2 192.168.24.4 16 msec 44 msec 44 msec

  3 192.168.45.5 56 msec *  40 msec