Zoek in project Uni1c0rn

Project Un1c0rn is a search engine exposing open, vulnerable and weak services since May 2014 ... Leaking mysqlmongo and heartbleed services worldwide ... Disclosure is the solution ... Un1c0rn won't die ... We don't ask, we host ... Back online, uptime should now be good, DB migration coming later. Leakhorn

Traffic Generators

opensource solutions, scapy will probably be able

to do the job.
> IMIX and other standard load tests.I’m using IPERF now, but this is
> simply a load gen.  No IMIX etc Suggestions ?A little script with bwping (TOS, MTU) is not enough to try to make a ~~pseudo~~ RFC2544 test ?
Sorry if it is not what you are searching for.

So I have started playing with this, I think it should do we you want (I have the same requirement);http://traffic.comics.unina.it/software/ITG/

> When it comes to minimum size packets, I’m not aware of open source
> software that can congest 1GE port. Operating systems are not really
> tuned to do 1Gbps UDP streams on small packets. You can achieve that,
> even more, but you need to go quite low level, UDP socket you must
> forget immediately event with sendmmsg/recvmmsg. Raw sockets and
> modern CPU and you’ll probably be able to reach 1Gbps per core, but I
> don’t know software available that would be productized even to iperf level here, would love to hear about one.

Some open source software I am writing can do 1Gbps (and likely beyond, I don’t have any 10G NICs to test on, yet!), although it’s for testing at the Ethernet layer so not really applicable here;

https://github.com/jwbensley/Etherate

One of the main features I am working on now (as I’m still writing the initial version) is loading the frame payload from file so that payload data *could* be UDP but it’s not really ment for testing higher than Ethernet and/or MPLS level.

Cheers,
James.

>
> When it comes to minimum size packets, I’m not aware of open source
> software that can congest 1GE port. Operating systems are not really
> tuned to do 1Gbps UDP streams on small packets. You can achieve that,
> even more, but you need to go quite low level, UDP socket you must
> forget immediately event with sendmmsg/recvmmsg. Raw sockets and
> modern CPU and you’ll probably be able to reach 1Gbps per core, but I
> don’t know software available that would be productized even to iperf level here, would love to hear about one.
 

Scapy [1] should be able to do that easily, so should mausezahn [2]. Of course you don’t open use regular TCP/UDP socket API for this, but some raw form of it and generate the whole packet in userspace.[1] http://www.secdev.org/projects/scapy/
[2] http://www.perihel.at/sec/mz/

VPLS hub & spoke

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-3s/mp-l2-vpns-xe-3s-book/vpls-auto-bgp-xe.html

Hi everyone.  I’m trying to understand vpls with a hub & spoke topology

a little better but I’m having a hard time grasping which site(s) need
to have the no split-horizon configuration added to them.  Not sure if
this is even possible with the autodiscovery option vs using manual.
So right now I’ve got four sites setup in a full mesh with the following
configuration on each PE router (ME3600X):

l2 vfi TEST1 autodiscovery
vpn id 3000
!
interface GigabitEthernet0/4
service instance 3000 ethernet
encapsulation dot1q 3000
rewrite ingress tag pop 1 symmetric
bridge-domain 3000
!
!
interface Vlan3000
no ip address
xconnect vfi TEST1
!

So if I want sites 2, 3 and 4 to not be able to talk to each other
except by going via site 1 what configuration change would I need to
do?  I thought that adding “split horizon” to the bridge-domain under
the service instance was the way to go but I’m not so sure.

Ideally, I’d like a scenario where I can have one site as the hub and be
able to take advantage of the autodiscovery for instances when a new
spoke is added to the domain.  Granted only the hub is benefiting from
this auto discovery but does that mean that the spokes should be
configured as “manual”?

Thanks for any suggestions.

Jose

Jose,

On the hub device you would have a VFI instance.
The spokes would be configured just as if they were running a point to point xconnect (i.e. xconnect statement on the service-instace)
On the hub, under the VFI, you need to configure your pseudowires as “neighbors” – this is where you would put the no-split-horizon statements for the spokes:

l2 vfi aaa manual
vpn id 1
neighbor 1.1.1.1 encapsulation mpls no-split-horizon
neighbor 2.2.2.2 encapsulation mpls no-split-horizon

HTH
Arie

Ahh I see, thanks for the examples Arie.  Makes sense now.
Jose

Jose,If you are using BGP auto-discovery then you could look into disabling ”
*auto-route-target*” and play with route-targets import/export to have Hub and Spoke topology like you do for L3VPN’s.

HTH

Uitschakelen Windows tunnel interfaces

https://www.asmus-consulting.com/en/blog-category-active-directory-and-windows-server/item/41-disable-ipv6-tunnel-adapter

Use these 3 lines to disable the Adapters by netsh:

1 netsh int ipv6 isatap set state disabled
2 netsh int ipv6 6to4 set state disabled
3 netsh interface teredo set state disable



You can also disable Tunnel Adapters by GPO
– open Group Policy Management Editor
– select an existing or create a new GPO
– Computer Configuration -> Administrative Templates -> Network -> TCPIP Settings -> IPv6 Transition Technologies






Configure all of the Settings below – enable the Setting but select “disable” within.
– “Set 6to4 State”
– “Set ISATAP State”
– “Set Teredo State”









thats it

Cisco CoPP

Cisco CoPP Best practices

Cisco CoPP Cat6k

http://events.cisco.hu/2014/techtorial/doc/lavarga_v1.0.pdf

Hi All,

Thanks for all the valuable input!

I wrote up a CoPPs policy, and deployed it in a non-limiting fasion

and monitored for a while. Once happy we enabled the policers and its

working fine, however the software counters are going up, and it’s not

clear to me why that is.

Further down is the config, immediately below is partial the output

from an example 7600 (as the CoPPs policy is quite long):

abr1#show policy-map control-plane input

Control Plane

  Service-policy input: Control-Plane-Filter-In

  Hardware Counters:

    class-map: CoPP-Limit-and-Permit-Critical (match-any)

      Match: access-group name CoPP-Limit-and-Permit-BGP

      Match: access-group name CoPP-Limit-and-Permit-BGPv6

      Match: access-group name CoPP-Limit-and-Permit-RSVP

      Match: access-group name CoPP-Limit-and-Permit-LDP

      Match: access-group name CoPP-Limit-and-Permit-OSPF

      Match: access-group name CoPP-Limit-and-Permit-OSPFv3

      Match: access-group name CoPP-Limit-and-Permit-HSRP

      Match: access-group name CoPP-Limit-and-Permit-BFD

      police :

        10000000 bps 312000 limit 312000 extended limit

      Earl in slot 6 :

        631028621 bytes

        5 minute offered rate 86968 bps

        aggregate-forwarded 631028621 bytes action: transmit

        exceeded 0 bytes action: transmit

        aggregate-forward 79648 bps exceed 0 bps

  Software Counters:

    Class-map: CoPP-Limit-and-Permit-Critical (match-any)

      4646556 packets, 411683229 bytes

      5 minute offered rate 54000 bps, drop rate 0000 bps

      Match: access-group name CoPP-Limit-and-Permit-BGP

        4035626 packets, 367873184 bytes

        5 minute rate 48000 bps

      Match: access-group name CoPP-Limit-and-Permit-BGPv6

        2101 packets, 174550 bytes

        5 minute rate 0 bps

      Match: access-group name CoPP-Limit-and-Permit-RSVP

        0 packets, 0 bytes

        5 minute rate 0 bps

      Match: access-group name CoPP-Limit-and-Permit-LDP

        173745 packets, 13108073 bytes

        5 minute rate 1000 bps

      Match: access-group name CoPP-Limit-and-Permit-OSPF

        77045 packets, 8382206 bytes

        5 minute rate 1000 bps

      Match: access-group name CoPP-Limit-and-Permit-OSPFv3

        0 packets, 0 bytes

        5 minute rate 0 bps

      Match: access-group name CoPP-Limit-and-Permit-HSRP

        358039 packets, 22145216 bytes

        5 minute rate 2000 bps

      Match: access-group name CoPP-Limit-and-Permit-BFD

        0 packets, 0 bytes

        5 minute rate 0 bps

      police:

          cir 10000000 bps, bc 312500 bytes, be 312500 bytes

        conformed 4646556 packets, 411683229 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          transmit

        violated 0 packets, 0 bytes; actions:

          drop

        conformed 54000 bps, exceeded 0000 bps, violated 0000 bps

I’m not sure why traffic like BGP would match into both the hardware

and software policiers, when its such a simple match statement (I am

assuming that because the packet count under the software counters is

much lower than the ACL match, so the rest were policied by

hardware?):

I am trying to write a CoPP template for some 7600s running as PEs. It

 

> would be handy if they were running a similar CoPP configuration to

> that on our Juniper PEs we are going to be connecting these 7600’s too

> so we have consistent CoPP across that domain of equally exposed

 

It’s not going to be consistent, CoPP does work, but can’t really compete with over decade newer Trio kit.

 

> CoPP on 7600’s can’t police ARP but one can use the MLS HWRL for that.

> The HWRLs can also handle other protocols like HSRP and CoPP can’t

> police multicast in hardware, so do people usually police ARP and HSRP

> using the MLS HWRLs instead of CoPP?

 

Pretty sure HSRP works just fine. For multicast, you just need to allow all multicast in CoPP (otherwise it’s processed by software CoPPP, which you don’t

want) and then limit in mls rate-limit.

 

> The HWRLs support other protocols too that ARE supported in CoPP in

> hardware, so are there any other protocols that people prefer to

> police using the HWRLs?

 

Example please, I cannot recall overlap.

 

> With regards to ACLs, do people really have giant access lists of

> peers they allow BGP to/from? The 7600 I am piloting this on has over

 

Yes. Two, one low rate for SYN and one for other BGP, alas. However if your master configuration data is not network, but database, then it does not really matter how complex or simple the network configuration is, as it’s generated automatically from database.

If it’s pure CLI jockey network, it can be a challenge.

 

But even this is isn’t as good as it should be, as each neighbour would need to have their own policer, like Cisco LPTS or Juniper ddos-protection can do.

But this is one of those things where you’ll rather carry a risk than overcomplicate the configuration.

 

> any any eq 179″ as above then I feel I need to police, unless I can

> guarantee at the edge I have filtered out traffic on TCP 179 from

> everywhere it shouldn’t be coming from. What approach to others take

> here? Why?

 

I have opted for simplicity, I have CoPP class for internal signalling stuff, which is critical, another for important customer/peer stuff, like BGP, and another for unimportant stuff (ping, udp traceroute…)

 

> What do people do with unusual traffic like IP fragments? I am

> discarding them. Thoughts?

 

If you can get away discarding fragments hitting control-plane, do it. If not, police it.

 

> What about packets with IP options set, I am allowing record-route

> only and dropping the rest. Thoughts?

 

No on expects IP options to work in the Internet, there is mls command to police them, I would do that, even for transit

 

> ICMP, I’m just proposing to allow the follow:

> ip access-list extended CoPP-Limit-and-Permit-ICMP  permit icmp any

> any echo  permit icmp any any echo-request  permit icmp any any

> unreachable  permit icmp any any ttl-exceeded  permit icmp any any

> packet-too-big  deny icmp any any

>

> Again, any thoughts there?

 

Never use ‘deny’ in PFC3 CoPP ACLs. It’s not needed, and it may not be supported and may cause negative match and stop of evaluation (i.e. won’t fall to next classs).

Netflow viewers

FlowViewer / SiLK handles IPv6.

Web-based, graphical tracking and analysis. Free.

http://sourceforge.net/projects/flowviewer/

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/flexible_netflow/configuration_guide/b_fnf_3se_3850_cg/b_fnf_3se_3850_cg_chapter_010.html#reference_A9019899140647F2B3F87ABABCFC170D

http://qosient.com/argus/

Cisco IOS sup-720 SNMP

In order to keep the same interfaces indexes, the only way to achieve that easily is moving the nvram:ifIndex-table from the old SUP to the new SUP.

This document says that the file can be downloaded and viewed:

http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/28420-ifIndex-Persistence.html

 

Procedure:

Old SUP:

#copy nvram:ifIndex-table disk0:

New SUP:

#delete nvram:ifIndex-table

#copy disk0:ifIndex-table nvram:

#reload

1 17 18 19 20