How to temporarily disable IPv4 on an interface within Linux

Case:

   We want to disable IPv4 on an interface

Solution:

   sudo ip -4 addr flush dev enp0s1

Explanation:

   The above command removes all IPv4 addresses for interface enp0s1. Important, remember that this disabling is only temporary.

The sad tale of the ISP that didn’t deploy IPv6

Once upon a time in the not so distant past, a large ISP dominated a country’s 

telecommunications market and felt powerful and without competition. Whenever someone 

needed to log on to the 

Internet they would use their services. Everyone envied their market penetration.

This large ISP, however, had never wanted to deploy IPv6 because they thought their stock

 of IP addresses was enough and saw no indicator telling them that they needed the new 

protocol.

During the course of those years, another smaller ISP began implementing IPv6 and slowly 

began to grow, as they realized that the protocol did indeed make a difference in the eyes of their 

clients and that it was helping them win over new users.

The small ISP’s market penetration continued to grow, as did their earnings and general respect

 for their services. As they grew, it became easier for them to obtain better equipment, traffic 

and interconnection prices. Everything was going very well. The small ISP couldn’t believe that

something as simple as deploying IPv6 could be paying off so spectacularly. Their customers

 told them their needs included running VPNs and holding conference calls with partners in 

other parts of the world, and that their subsidiaries, customers and business partners in Europe

 and Asia had already adopted IPv6.

Despite being so powerful, the large ISP began experiencing internal problems that were 

neither billing nor money related. Sales staff complained that they were having trouble closing 

many deals because customers had started asking for IPv6 and, although their ISP was so

 large and important, they simply did not have IPv6 to offer. Both corporate customers and 

residential users were asking for IPv6; even major state tenders were requiring IPv6.

When this started happening, the Sales Manager complained to the Products, Engineering and 

Operations departments. The latter were left speechless and some employees were let go by 

the company. In the end, Sales did not care where the fault lay – they were simply unable to 

gain new customers. Realizing that they were losing customers, some of the salespeople 

accepted job offers at the small ISP who was looking to grow their staff as they could now 

afford the best sales force. 

Then the same thing happened with the larger ISP’s network manager, an expert who knew 

a lot about IPv6 but who had been unable to overcome the company’s bureaucracy and bring

 the new protocol into production. Logically, the network manager was followed by his trusted 

server administrator and head of security. The large ISP couldn’t believe what was happening

 right before their very eyes. The sales force hired by the smaller ISP (those who used to 

work for the large ISP) brought with them their huge customer base, all of them potential prospects.

A stampede of the large ISP’s clients was on the way. The months went by and the smaller

 ISP was no longer simply offering Internet access – its Data Center had grown, major 

companies brought in new cache servers and much more. They were now offering co-location, 

hosting, virtual hosting, voice and video, among many other services.

When the large provider decided to deploy IPv6, it had to do so very quickly. Things went 

wrong; many errors were made. In addition, certain consultants and companies took 

advantage of their problems and charged higher rush fees. Network downtime increased,

 as did the number of calls to the call center. The large ISP’s reputation started to crumble.

As expected, in the end, everyone who was part of this story – clients and providers alike – 

ended up deploying IPv6. Some ended up happier than others, but everyone adopted IPv6

 on their networks.

By Alejandro Acosta

How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

Issue:

  How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

Answer:

  app.run(host='::',port=5005)

Start your machine learning or AI journey with Runpod. If you need affordable GPU rental , RunPod has the lowest prices. Rent a NVIDIA RTX A6000 with 48GB VRAM, or other models like NVIDIA 3090.

My humble results. Testing ping to loopback using v4 and v6

Hello there,
  Regarding RTT v4 vs v6 I did something "interesting" recently, would like to know your thoughs.
  If you ping6 your loopback (let´s say 1000 packets) interface with Windows or Linux, v6 is faster.
  Now try the same on MAC (El capitan for example).., v6 is 20-25% slower.
  I did the above with many devices (and asked some friends) and the behavior was pretty much the same.


MAC:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.037/0.098/1.062/0.112 ms
--- ::1 ping6 statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.058/0.120/0.194/0.027 ms



Linux:
--- 127.0.0.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 98999ms
rtt min/avg/max/mdev = 0.015/0.021/0.049/0.007 ms

--- ::1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99013ms
rtt min/avg/max/mdev = 0.019/0.031/0.040/0.004 ms


Windows 10:

Ping statistics for ::1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


Ping statistics for 127.0.0.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 4ms, Average = 0ms


Bye,


wetheitteam.com
Where to order pain Relief without prescription
vivo v15 pro

Read a BGP live stream from CAIDA

Objective
  Read a BGP live stream from CAIDA and insert them into a BGP session

What do we need
  bgpreader from the bgpstream core package provided by Caida
  bgp_simple.pl obtained in github

Overview
  We will read the BGP live stream feed using bgpreader, then the standard output of it will be redirected to a pipe file (mkfifo) where a perl script called bgpsimple will be reading this file. This very same script will established the BGP session against a BGP speaker and announce the prefixes received in the stream.

LAB Topology
  The configuration was already tested in Cisco & Quagga
  The BGP Speaker (Cisco/Quagga) has the IPv4 address 192.168.1.1
  The BGP Simple Linux box has the IP 192.168.1.2

How does it works?
  bgpreader has the ability to write his output in the -m format used by libbgpdump (by RIPENCC), this is the very same format bgpsimple uses as stdin. That's why myroutes is a PIPE file (created with mkfifo).

Steps:  

INSTALL BGP READER - UBUNTU 15.04

First install general some packages:
apt-get install apt-file libsqlite3-dev libsqlite3 libmysqlclient-dev libmysqlclient
apt-get install libcurl-dev libcurl  autoconf git libssl-dev
apt-get install build-essential zlib1g-dev libbz2-dev
apt-get install libtool git
apt-get install zlib1g-dev

Also intall wandio
wandio-1.0.3
git clone https://github.com/alistairking/wandio

./configure

cd wandio
./bootstrap.sh
./configure && ./make && ./make install
wandiocat http://www.apple.com/library/test/success.html

to test wandio:
wandiocat http://www.apple.com/library/test/success.html

Download bgp reader tarball from:
https://bgpstream.caida.org/download

#ldconfig (before testing)

#mkfifo myroutes

to test bgpreader:
./bgpreader -p caida-bmp -w 1453912260 -m
(wait some seconds and then you will see something)

# git clone https://github.com/xdel/bgpsimple


Finally run everything
In two separate terminals (or any other way you would like to do it):

./bgpreader -p caida-bmp -w 1453912260 -m > /usr/src/bgpsimple/myroutes
./bgp_simple.pl -myas 65000 -myip 192.168.1.2 -peerip 192.168.1.1 -peeras 65000 -p myroutes

One more time, what will happen behind this?
bgpreader will read an online feed from a project called caida-bmp with starting timestamp 1453912260 (Jan 27 2016, 16:31) in "-m" format, It means a libbgpdump format (see references). The stardard output of all this will be send to the file /usr/src/bgpsimple/myroutes which is a "pipe file". At the same time, bgp_simple.pl will create an iBGP session againts peer 192.168.1.1/AS65000 (a bgp speaker such as Quagga or Cisco). bgp_simple.pl will read myroutes files and send what it seems in this file thru the iBGP Session.

Important information
- The BGP Session won't be established until there is something in the file myroutes
- eBGP multi-hop session are allowed
- You have to wait short time (few seconds) until bgpreaders start to actually see something and bgp_simple.pl starts to announce to the BGP peer

References / More information:
-Part of the work was based on:
http://evilrouters.net/2009/08/21/getting-bgp-routes-into-dynamips-with-video/

- Caida BGP Stream:
https://bgpstream.caida.org/

- bgpreader info:
https://bgpstream.caida.org/docs/tools/bgpreader

- RIPE NCC libbgpdump:
http://www.ris.ripe.net/source/bgpdump/

- Introduction of "Named Pipes" (pipe files in Linux):
http://www.linuxjournal.com/article/2156

The sad tale of the ISP that didn’t deploy IPv6

Once upon a time in the not so distant past, a large ISP dominated a country’s telecommunications market and felt powerful and without competition. Whenever someone needed to log on to the Internet they would use their services. Everyone envied their market penetration.

This large ISP, however, had never wanted to deploy IPv6 because they thought their stock of IP addresses was enough and saw no indicator telling them that they needed the new protocol.

During the course of those years, another smaller ISP began implementing IPv6 and slowly began to grow, as they realized that the protocol did indeed make a difference in the eyes of their clients and that it was helping them win over new users.

The small ISP’s market penetration continued to grow, as did their earnings and general respect for their services. As they grew, it became easier for them to obtain better equipment, traffic and interconnection prices. Everything was going very well. The small ISP couldn’t believe that something as simple as deploying IPv6 could be paying off so spectacularly. Their customers told them their needs included running VPNs and holding conference calls with partners in other parts of the world, and that their subsidiaries, customers and business partners in Europe and Asia had already adopted IPv6.

Despite being so powerful, the large ISP began experiencing internal problems that were neither billing nor money related. Sales staff complained that they were having trouble closing many deals because customers had started asking for IPv6 and, although their ISP was so large and important, they simply did not have IPv6 to offer. Both corporate customers and residential users were asking for IPv6; even major state tenders were requiring IPv6.

When this started happening, the Sales Manager complained to the Products, Engineering and Operations departments. The latter were left speechless and some employees were let go by the company. In the end, Sales did not care where the fault lay – they were simply unable to gain new customers. Realizing that they were losing customers, some of the salespeople accepted job offers at the small ISP who was looking to grow their staff as they could now afford the best sales force. Then the same thing happened with the larger ISP’s network manager, an expert who knew a lot about IPv6 but who had been unable to overcome the company’s bureaucracy and bring the new protocol into production. Logically, the network manager was followed by his trusted server administrator and head of security. The large ISP couldn’t believe what was happening right before their very eyes. The sales force hired by the smaller ISP (those who used to work for the large ISP) brought with them their huge customer base, all of them potential prospects.

A stampede of the large ISP’s clients was on the way. The months went by and the smaller ISP was no longer simply offering Internet access – its Data Center had grown, major companies brought in new cache servers and much more. They were now offering co-location, hosting, virtual hosting, voice and video, among many other services.

When the large provider decided to deploy IPv6, it had to do so very quickly. Things went wrong; many errors were made. In addition, certain consultants and companies took advantage of their problems and charged higher rush fees. Network downtime increased, as did the number of calls to the call center. The large ISP’s reputation started to crumble.

As expected, in the end, everyone who was part of this story – clients and providers alike – ended up deploying IPv6. Some ended up happier than others, but everyone adopted IPv6 on their networks.

$GENERATE A records using BIND. Match forward and rDNS

Hi,
This post is very short but perhaps very useful. There is less documentation on the Internet than expected.

Objective: 
a) Set the reverse DNS and forward DNS match for a / 24 in BIND9 using $GENERATE.

Requirements: 
- A  /24 network (of course, you can adapt the example to other networks)
- BIND9
- We will use A and PTR records

Example: 
Network: 192.168.30.0/24
Domain: example.com

Let's make the rDNS for 192.168.30.X resolved to: X.client.example.com
Similarly, X.client.example.com to resolve to 192.168.30.X

It would be like this:
192.168.30.1 ---> 1.client.example.com
192.168.30.2 ---> 2.client.example.com
192.168.30.3 ---> 3.client.example.com
1.client.example.com ---> 192.168.30.1
2.client.example.com ---> 192.168.30.2
3.client.example.com ---> 192.168.30.3
(Etc)

Steps: 
We create reverse zone in /etc/bind/named.conf.

a) The reverse zone:

zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query {any; };
};


After that, then in file 30.168.192.in-addr.arpa.db place the following: 

$TTL    86400 ; 24 hours, could have been written as 24h or 1d

@  1D  IN        SOA localhost.     hostmaster.example.com. (

                              2002022401 ; serial

                              3H ; refresh

                              15 ; retry

                              1w ; expire

                              3h ; minimum

                             )

; Name servers for the zone - both out-of-zone - no A RRs required

                        NS      localhost.

$GENERATE 1-255 $ PTR $.client.example.com.

b) The forward DNS is doing the following in the client.example.com zone file: 

$TTL    86400 ; 24 hours, could have been written as 24h or 1d

@  1D  IN        SOA localhost.     hostmaster.example.com. (

                              2002022401 ; serial

                              3H ; refresh

                              15 ; retry

                              1w ; expire

                              3h ; minimum

                             )

; Name servers for the zone - both out-of-zone - no A RRs required

                        NS      localhost.

$GENERATE 1-255.client.example.com $ A 192.168.30.$

Testing: 
#dig -x 192.168.30.3 (reverse dns) 
#dig 3.cliente.ejemplo.com (forward dns) 

P.S. As usual there can be more than way of doing this kind of things.

Advertising IPv6 Routes Between IPv4 BGP Peers (Cisco)

Situation:
  I want to advertise IPv6 networks / prefixes over IPv4 eBGP session
History:
  Although not common, this case may occur in some situations. 
  For example, in this moment, I have a Cisco router with IPv6 support (routing) but do not support BGP IPv6 neighbors
Error (just in case):
  (Probably you are receiving the message below)     :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

 
Solution:
  Fortunately BGP support carrying routing information for different protocols (ie. IPv6). Therefore it is possible to exchange prefixes IPv6 over eBGP IPv4 sessions.
Configuration:
  In this basic scenario with R1 <--> R2 connected back-to-back the configuration is as follows (the prefix announced by R1 is learned by R2).

R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0

R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!
"The trick":
  * The session must be eBGP multihop, if not, R2 will not learn the prefix (the same error as seen above). I admit I do not get 100% why it happens however after readings some documents it looks like the router complains that the next-hop IP address and the way it was configured are in different subnet (make sense, one is IPv6 and IPv4 another!).
  * In R2 (who receive the prefix) there must be a route-map applied (in) forcing the next-hop IPv6 address of R1
After applying ebgp-multihop (everything works):
* Mar 1 02:01:42.539: BGP (1): 1.1.1.1 rcvd UPDATE w / attr: nexthop :: FFFF: 1.1.1.1, origin i, metric 0, path 1* Mar 1 02:01:42.539: BGP (1): 1.1.1.1 rcvd 2800:26 :: / 32* Mar 1 02:01:42.543: BGP (0): Check route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table* Mar 1 02:01:42.543: BGP (1): Check for installing route 2001: db8 :: / 32 -> 2001: db8 :: 1 (::) to main IPv6 tableMore information:- https://supportforums.cisco.com/docs/DOC-21110- http://ieoc.com/forums/p/15154/130174.aspx- http://ieoc.com/forums/p/15154/130174.aspx

I hope it's useful!

IPv6 crosswords puzzle

http://goo.gl/lVuv6

I hope you enjoy it :)