I am trying to get Quagga do something as simple as advertising a eBGP learned prefix to another eBGP connected neighbour. Simple enough right?
BGPd config snippet
!
router bgp 64620
bgp router-id 172.29.253.80
bgp log-neighbor-changes
network 172.29.253.80/32
timers bgp 10 30
neighbor 10.35.253.2 remote-as 64901
neighbor 10.35.253.2 next-hop-self
neighbor 10.35.253.2 soft-reconfiguration inbound
neighbor 10.47.0.254 remote-as 64621
neighbor 10.47.0.254 ebgp-multihop 255
neighbor 10.47.0.254 next-hop-self
neighbor 10.47.0.254 soft-reconfiguration inbound
!
Prefix 10.47.0.0/16 learned from neighbour 10.47.0.254 and re-advertised to 10.35.253.2
# sh ip bgp 10.47.0.0/16
BGP routing table entry for 10.47.0.0/16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.35.253.2
64621
10.47.0.254 from 10.47.0.254 (10.47.0.254)
Origin IGP, localpref 100, valid, external, best
Last update: Mon Mar 19 08:35:28 2018
But checking the advertised-routes to 10.35.253.2 reveals it (10.47.0.0/16) is indeed not advertised. I also verified this with tcpdump.
# sh ip bgp neighbors 10.35.253.2 advertised-routes
BGP table version is 0, local router ID is 172.29.253.80
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.29.253.80/32 10.35.253.1 0 32768 i
Total number of prefixes 1
BGPd version
# /usr/lib/quagga/bgpd --version
bgpd version 0.99.24.1
This turned out to be a bug in Quagga;
https://bugzilla.quagga.net/show_bug.cgi?id=972
Solved by switching to FRR which seems to be more actively maintained.
Related
I'm trying to pentest some IPSEC implementation for a uni project, and following this guide I'm stuck at:
Step 1 (common): Forging an ICMP PTB packet from the untrusted network The attacker first has to forge an appropriate ICMP PTB packet (a single packet is sufficient). This is done by eavesdropping a valid packet from the IPsec tunnel on the untrusted network. Then the attacker forges an ICMP PTB packet, specifying a very small MTU value equal or smaller than 576 with IPv4 (resp. 1280 with IPv6). The attacker can use 0 for instance. This packet spoofs the IP address of a router of the untrusted network (in case the source IP address is checked), and in order to bypass the IPsec protection mechanism against blind attacks, it includes as a payload a part of the outer IP packet that has just been eavesdropped. This is the only packet an attacker needs to send. None of the following steps involve the attacker.
I know what MTU is, but what does the bold statement mean?
How do I set the MTU size of a packet with scapy?
It means that I have to set the size of a IP packet less than 576 bytes?
It's already set to 140 B,at least it shows this with len command.
There's something that I didn't get right, maybe I have to set the fragmentation?
I know nothing about the subject, but some quick searching seems to indicate that it's referring to an IPv6 ICMP packet with a type of 2 ("packet too big").
Then from some poking around scapy, this appears to be how you'd create one:
from scapy.layers.inet6 import ICMPv6PacketTooBig
icmp_ptb = ICMPv6PacketTooBig(mtu=0)
Of course though, you'll need to do some testing to verify this.
I am using datastax opscenter 6.0 for DSE Cassandra Monitoring. Configuration is done to send SNMP trap but Trap receiver ( HP Openview in this case ) is not receiving this alert.
I don't see any SNMP realted errors in opscenter logfile. How do I trace the exact error?
Here is my snmp.conf file:
[snmp]
# set to 1 to enable SNMP trap sending
enabled=1
# Levels can be a comma-delimited list of any of the following:
# DEBUG,INFO,WARN,ERROR,CRITICAL,ALERT
# If the left is empty, OpsCenter will listen for all levels.
levels=ALERT
# Comma-delimited list of cluster names for which
# this alert config will be eligible to run.
# If left empty, this alert will be called for events on all clusters.
clusters=
# SNMP engine ID, specified by rfc3411 and rfc5343.
# See http://tools.ietf.org/html/rfc3411#section-5
# SnmpEngineID definition for more information.
#
# 32 octet (max length) unique hex engine ID. Must not be all zeroes or all
# 255's. The first four octets specify the enterprise ID, left filled
# with zeroes and starting with an 8. The fifth octet specifies a format scheme
# that specifies the nature of the remaining octets. The remaining octets
# are given in accordance with the specified format.
#
# Format Schemes:
# 1 -- IPv4 Address scheme
# 2 -- IPv6 Address scheme
# 3 -- MAC Address scheme
# 4 -- Text Address scheme
# 5 -- Octets scheme
#
# Default scheme is octets scheme; if nothing else, you should change
# 01020304 to a unique octet string.
#engine_id=80:00:00:00:05:01:02:03:04
# IPv4 address of the SNMP target.
target_ip=*.*.*.* ( commented due to security urpose )
# Port to direct traps to on the SNMP target.
target_port=162
# Set to 1 to use SNMPv3 and the user/privacy key/auth key model. Set to 0 to
# use SNMPv1/community model.
use_snmpv3=0
# SNMPv1/2 community name (for community security model)
community_name=public
# SNMPv3 username
#user=opscusername
# SNMPv3 authentication protocol
# Options:
# MD5 -- MD5-based authentication protocol
# SHA -- SHA-based authentication protocol
# NoAuth -- no authentication to use
#auth_protocol=SHA
# SNMPv3 authentication key
#auth_key=authkey1
# SNMPv3 privacy protocol
# Options:
# DES -- DES-based encryption protocol
# AES -- AES128-based encryption protocol (RFC3826)
# 3DES -- triple DES-based encryption protocol (Extended Security Options)
# AES192 -- AES192-based encryption protocol (Extended Security Options)
# AES256 -- AES256-based encryption protocol (Extended Security Options)
# NoPriv-- no encryption to use
#privacy_protocol=AES
# SNMPv3 privacy key
#privacy_key=privkey1
Try setting levels=ALERT to levels= and make sure its not just that your filtering the events your looking for first (can turn it back once have it working like you want, just easier to see more things).
Can use wireshark or tcpdump to check if the trap is being sent with something like:
tcpdump -i eth1 -T snmp "(port 161 or 162)"
(note: eth1 may need to be replaced with your interface name). SNMP clients can be a little bit of a pita in being setup correctly as well, so good to check if they are being sent and not handled vs not sent.
I am currently facing a trouble in my code.
Mainly, I emulate the connection between two computers, connected via an ethernet bridge (Raspberry Pi, Raspbian). So I am able to influence parameters of this connection (like bandwidth, latency and much more) via tc qdisc.
This works out fine, as you can see in the code down below.
But now to my problem:
I am also trying to exclude specific port ranges, what means ports that aren't influenced by my given parameters (latency etc..).
For that I created two prio bands. The prio band 0 (higher priority) handles my port exclusion (already in the parent root).
Afterwards in prio band 1 (lower priority), I decline a latency via netem.
The whole data traffic will pass through my influenced prio band 1, the remaining (excluded data) will pass uninfluenced through prio band 0.
I don't get kernel errors while executing my code! But I only receive filter parent 1: protocol ip pref 1 basic after typing sudo tc filter show dev eth1.
My match is not even mentioned. What did I wrong?
Can you explain me why I don't get my excpected output?
THIS IS MY CODE (in right order of executioning):
PARENT ROOT
sudo tc qdisc add dev eth1 root handle 1: prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
This creates two priobands (1:1 and 1:2)
BAND 0 [PORT EXCLUSION | port 100 - 800]
sudo tc qdisc add dev eth1 parent 1:1 handle 10: tbf rate 512kbit buffer 1600 limit 3000
Creates a tbf (Token Bucket Filter) to set bandwidth
sudo tc filter add dev eth1 parent 1: protocol ip prio 1 handle 0x10 basic match "cmp(u16 at 0 layer transport lt 100) and cmp(u16 at 0 layer transport gt 800)" flowid 1:1
Creates a filter with specific handle, that excludes port 100 to 800 from the prioband 1 (the influenced data packets)
BAND 1 [NET EMULATION]
sudo tc qdisc add dev eth1 parent 1:2 handle 20: tbf rate 1024kbit buffer 1600 limit 3000
Compare with tbf above
sudo tc qdisc add dev eth1 parent 20:1 handle 21: netem delay 200ms
Creates via netem a delay of 200ms
Here you can see my hierarchy as an image
The question again:
My filter match is not even mentioned. What did I wrong?
Can you explain me why I don't get my excpected output?
I appreciate any kind of help! Thanks for your efforts!
~rotsechs
It seems like I have to neglect the missing output! Nevertheless, it works perfectly.
I established a SSH connection to my Ethernet Bridge (via MobaXterm). Afterwards I laid a delay of 400ms on it. The console inputs slowed down as expected.
Finally I created the filter and excluded the port range from 20 to 24 (SSH has port 22). The delay of my SSH connection disappeared immediately!
Doing my ccna3 on lab 5.5.1 in packet tracer. question asks to do a debug spanning-tree events command on the 2960 router. this does not work. all routers have STP on.
the image below is a capture of the switch with the root bridge. this command does not work on any of the 3 switches and it is clearly written in the book to do this command on all 3.
any help would be greatly appreciated
S2#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0001.643C.50E9
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0001.643C.50E9
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p
Fa0/2 Desg FWD 19 128.2 P2p
Fa0/6 Desg FWD 19 128.6 P2p
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/18 Desg FWD 19 128.18 P2p
S2#debug ?
ip IP information
sw-vlan vlan manager
S2#debug spanning-tree events
^
% Invalid input detected at '^' marker.
This is an old thread, but, it's probably a limitation of Packet Tracer. I would assume from the output given that this isn't a router and actually a switch. In which case, it is a limitation.
I have an application that has a TCP client and a server. I set up the client and server on separate machines. Now I want to measure how much bandwidth is being consumed ( bytes sent and received during a single run of the application). I have discovered that wireshark is one such tool that can help me get this statistic. However, wireshark seems to be GUI dependent. What I wanted was a way to automate the measuring and reporting of this statistic. I dont care about the information about individual packets captured by wireshark. I dont need that information. Is there some way to run wireshark so that all it does is write to a file, the total bytes sent and received between two hosts while the application was running on both ends?
Also, is there a better way to capture this statistic ? Through netstat or /proc/dev/net or any other tool ?
Both my machines have ubuntu 10.04 or later running on them.
Bro is an appropriate tool to measure connection-oriented statistics. You can either record a trace of your application communication or analyze it in realtime:
bro -r <trace>
bro -i <interface>
Thereafter, have a look at the connection log (conn.log) in the same directory for the amount of bytes sent and received by the application. Specifically, you're interested in the TCP payload size, which conn.log exposes via the columns orig_bytes and resp_bytes. Here is an example:
bro-cut id.orig_h id.resp_h conn_state orig_bytes resp_bytes < conn.log | head
which yields the following output:
192.168.1.102 192.168.1.1 SF 301 300
192.168.1.103 192.168.1.255 S0 350 0
192.168.1.102 192.168.1.255 S0 350 0
192.168.1.103 192.168.1.255 S0 560 0
192.168.1.102 192.168.1.255 S0 348 0
192.168.1.104 192.168.1.255 S0 350 0
192.168.1.104 192.168.1.255 S0 549 0
192.168.1.103 192.168.1.1 SF 303 300
192.168.1.102 192.168.1.255 S0 - -
192.168.1.104 192.168.1.1 SF 311 300
Each row represents a single connection, transport-layer ports omitted. The last two columns represent the bytes sent by the originator (first column) and responder (second column). The column conn_state represents the connection status. Please refer to the documentation for all possible field values. Some important values are:
S0: Connection attempt seen, no reply.
S1: Connection established, not terminated.
SF: Normal establishment and termination. Note that this is the same symbol as for state S1. You can tell the two apart because for S1 there will not be any byte counts in the summary, while for SF there will be.
REJ: Connection attempt rejected.