I would understand if it's possible, and if yes how, to convert the following rules to OpenWRT UCI format using the rule directive:
ip rule add to all table 111 pref 4
ip rule add from 10.0.0.1/24 lookup 113 pref 32768
ip rule add iif lo lookup 113 pref 32768
ip rule add from all lookup 112 pref 32769
I also have a default route to add to a specific table:
ip route add default via 10.0.0.1 dev br-lan table 113
I guess for this one I will have to use the route directive, I'm just not sure how and I will like to familiarise more with the OpenWRT UCI way of doing this.
I also want to learn this because I would like to improve the automation facility present in OpenWISP (an open source wifi controller).
Thanks in advance
Federico
Related
I have a specific scenario:
There are 2 paths leading to a given OSPF prefix:
-Both of the paths are learnt via OSPF
-Prefix CIDRs are the same size
-Both OSPF "preference" value is unchanged (so is the default: 10)
My problem is that only a single Path is put inside my routing-table
( I would assume it is because one of the OSPF path's cost was lower than the other's).
I got 2 questions:
-What command do I need to put into Juniper CLI in order to see the "not-so-best" OSPF paths (that actually didnt make it into the routing table)
-How do I see the metric of each individual path toward a given prefix.
Thanks in advance.
OSPF does not advertise routes, it advertises LSAs. You need look at the OSPF "database" to see the different LSAs, and you need to understand the LSA types and the Djikstra algorithm.
while using Workers, I have a switch/case to match request.cf.region.
I cannot find the list of 21 names that Cloudflare uses for the regions of Italy.
I created my own, here below.
Can anybody confirm the list I'm providing matches Cloudflare's names?
As a reference I'm using the names from the wikipedia "Economy of regions" section: https://en.wikipedia.org/wiki/Regions_of_Italy
A first discrepancy I've found, Cloudflare defines 'Lazio' as 'Latium'.
I'm trying to find if there's other names that don't match the names from Wikipedia.
I share the list for public use and maintenance.
Basilicata
Calabria
Campania
Emilia-Romagna
Friuli-Venezia Giulia
Latium
Liguria
Lombardy
Marche
Molise
Piedmont
Apulia
Sardinia
Sicily
Tuscany
Trentino-Alto Adige/Südtirol
Umbria
Aosta Valley
Veneto
request.cf.region represents the ISO 3166-2 name for the first level region associated with the IP address of the incoming request. This is documented at this page
For localisation inconsistencies I'd recommend to reach out to Cloudflare Support to have it reviewed.
I'm trying to program a simplified version of a eBGP speaker. For the import policy, I want to make sure that any new route that I import doesn't have any loops. The routing table that I build looks something like this.
10.0.0.0/8 3 8 11
10.8.0.0/8 4
192.168.0.0/16 3 5 6
192.168.43.0/24 (local)
My question is, how do you check for a routing loop?
Now I've tried multiple things and I think the right way to see if there would be any loops would be to construct a DAG using all the routes in the routing table. Then checking if the new route creates a cycle in the graph. But I can't understand if I should only look at certain prefixes when creating the DAG.
In eBGP loop detection is based on the ASPATH. You can NOT accept routes with ASPATHs that include your own ASN.
This is defined in RFC4271:
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
Hint: If you want to implement a BGP Speaker, I suggest your meticulously read all related RFCs starting with RFC4271.
As for iBGP there is no loop detection needs as an iBGP Speaker will NOT forward iBGP learned routes to another iBGP speaker. You need to have all your iBGP speaker connected in full-mesh, use a route-reflector or confederations.
Article regarding those principles (for iBGP): http://www.rogerperkin.co.uk/routing-protocols/bgp/bgp-confederation-vs-route-reflector/
I want to have a list of source IP addresses of an interface outbound traffic. How could I find the direction of a packet whether it's inbound or outbound reading traffic using libpcap? I don't know the subnet information of either side. And there are clients/servers on both sides, so I can't rely on port number ranges to filter traffic.
Why there is no information in libpcap packet header about direction, or filter option like inbound in pcap-filter?
Netsniff-NG, while not relying on libpcap, supports Linux kernel packet type extensions.
They're documented
here
One of the packet types is outgoing and commented as "outgoing of any type".
The following example will capture all packets leaving your interface.
$ netsniff-ng --in eth0 --out outgoing.pcap --type outgoing
Using this you can utilize other command-line tools to read the PCAP file and pull out all the source
addresses. Maybe something *nix-ey like this:
$ tcpdump -nnr outgoing.pcap | cut -d " " -f3 | cut -d . -f1-4
Note: I haven't tried this on a router.
you could use "ether src" or "ether dst" to filter packet direction. This require you to know the mac address of the interface.
You can select a direction that packets will be capture calling pcap_setdirection() before pcap_loop().
For example, to capture incoming packets only you need to write:
handle = pcap_open_live("eth0", 65535, 1, 0, errbuf);
pcap_setdirection(handle, PCAP_D_IN);
pcap_loop(handle, -1, process_packet, NULL);
Possible directions are: PCAP_D_IN, PCAP_D_OUT, PCAP_D_INOUT.
See tcpdump.org/manpages/pcap_setdirection.3pcap.txt
The PCAP file format does not contain a field that holds the interface used during the capture. With that said, the newer PCAP-NG file format, currently used by Wireshark & Tshark, supports it along with packet direction.
Existing pcap-ng features:
packet dropped count
annotations (comments)
local IP address
interface & direction
hostname <-> IP address database
PcapNg
It sounds like you're capturing from a router or firewall so something like the following
would not work.
ip src 192.168.1.1
Capturing the traffic into flows may be an option but it still will not provide you with direction information. Though, you will be able to determine the source and destinations address easily. If you have an existing pcap you can convert it to the ARGUS format:
argus -r capture.pcap -w capture.argus
ra -nnr capture.argus
Other tools, some w/ examples, that can easily obtain end-points/hosts are:
ntop -f capture.pcap
tcpprof -nr capture.pcap
Wireshark Endpoints
flow-tools
You'll have to parse out the information you want, but I don't think that's too much trouble. I recommend taking a look at PCAP-NG if you can't work with this.
I tried dst==192.168.1.101 but only get :
Neither "dst" nor "192.168.1.101" are field or protocol names.
The following display filter isn't a valid display filter:
dst==192.168.1.101
Match destination: ip.dst == x.x.x.x
Match source: ip.src == x.x.x.x
Match either: ip.addr == x.x.x.x
Filtering IP Address in Wireshark:
(1)single IP filtering:
ip.addr==X.X.X.X
ip.src==X.X.X.X
ip.dst==X.X.X.X
(2)Multiple IP filtering based on logical conditions:
OR condition:
(ip.src==192.168.2.25)||(ip.dst==192.168.2.25)
AND condition:
(ip.src==192.168.2.25) && (ip.dst==74.125.236.16)
You can also limit the filter to only part of the ip address.
E.G. To filter 123.*.*.* you can use ip.addr == 123.0.0.0/8. Similar effects can be achieved with /16 and /24.
See WireShark man pages (filters) and look for Classless InterDomain Routing (CIDR) notation.
... the number after the slash represents the number of bits used to represent the network.
If you only care about that particular machine's traffic, use a capture filter instead, which you can set under Capture -> Options.
host 192.168.1.101
Wireshark will only capture packet sent to or received by 192.168.1.101. This has the benefit of requiring less processing, which lowers the chances of important packets being dropped (missed).
Try
ip.dst == 172.16.3.255
Actually for some reason wireshark uses two different kind of filter syntax one on display filter and other on capture filter. Display filter is only useful to find certain traffic just for display purpose only. its like you are interested in all trafic but for now you just want to see specific.
but if you are interested only in certian traffic and does not care about other at all then you use the capture filter.
The Syntax for display filter is (as mentioned earlier)
ip.addr = x.x.x.x
or
ip.src = x.x.x.x
or
ip.dst = x.x.x.x
but above syntax won't work in capture filters, following are the filters
host x.x.x.x
see more example on wireshark wiki page
in our use we have to capture with host x.x.x.x. or (vlan and host x.x.x.x)
anything less will not capture? I am not sure why but that is the way it works!
Other answers already cover how to filter by an address, but if you would like to exclude an address use
ip.addr < 192.168.0.11