Site dedicated mainly to internetworking. The goal is to share experiences, teach IP, IPv6. Talk about Linux, IP services, servers, promote IPv6 adoption, routing protocols, security and in some cases just some thoughts. Keywords: linux, cisco, ospf, bgp, eigrp, ip, ipv6, sla, link, routers, routings, telco, telecommunications, security, ipv4
Showing posts with label ipv6. Show all posts
Showing posts with label ipv6. Show all posts
Tuesday, June 24, 2014
Monday, August 5, 2013
IPv6 & Satellite links: The right solution for rest of the world
Abstract:
Nowadays, having Internet access is a right.
It’s like having electricity or water. Being an extremist, I would even say
it’s like oxygen in somehow.
This small draft tries to summarize a simple
combination of technologies that is supposed to be a long term solution to
remote places where Internet access if generally difficult to get.
One of the goals of mankind today should be to
offer good and reliable Internet access to everyone, in despite of their
location. Our current motivation is oriented to places where a terrestrial link
is impossible to find.
We basically want to mix two good technologies
that unfortunately we believe are not working together today: 1) satellite
links and 2) IPv6. The first one with its pros and cons -as all kind of
technology- is a proven solution. The second one has also proved to be
reliable, and is the de facto standard for the near future.
Introduction:
In the last 13 years of my life I have been
working in the satellite link area. Additionally, since 1998 I've been curious
about IPv6 but it was not until six years ago that I've really been able to
work with it. Finally, I have always been passionate about Internet, communications
and freedom of information
As a technical person I have
always preferred connections over fiber,
copper or even wireless links (microwave, Wi-Fi, WIMAX, etc.) however
these are not always possible, mostly because of site location.
One of the goals of mankind
today should be to offer good and reliable Internet access to everyone, in
ispite of their location
.
Proposal:
One of the amazing things of satellite links,
it’s their capability to reach virtually anywhere in the globe. I’ve had the
chance to participate in satellite port installations in very remote places
such as boats at sea or in remote rural or jungle sites where there isn't even
cell phone signal. In turn I have seen all kinds of solutions deployed on these
links: ATM (Automatic Teller Machines), PoS (Point of Sales), corporate private
link and of course: Internet Access.
During the last years I have been deeply
involved with IPv6. I am a firm believer in the “Internet of things” concept,
where most things need and will be connected to Internet .
Unfortunately, for various reasons, the
conventional thinking is that Internet
connections are suitable only for home
and office applications in urban sites. Even though this is partly true, we cannot forget the
great masses of people (and things) in non-urban areas, remarkably greater in
developing countries. In the end, this fact becomes very negative. Millions of
people are being left behind when the advantages of Internet access is taken
away from them. i.e.: access to e-learning, e-nursering, telemedicine,
research, cloud computing, online consultations and many other great benefits
provided.
Though fiber links, hybrid fiber-coax and very
high-speed Wireless links are growing in all countries, there are places where
these technologies will never be seen or will be missing for several decades.
The solution I see coming, one we should not miss, is the pairing of the new
Internet protocol (IPv6) and satellite communications. Of course Satellite
links exist everywhere and IPv6 is coming forward, what propose is to keep
those technologies together.
It is my point of view that
this combination is the only one that really combines a long-term feasibility.
And is currently achievable! This is the right way to connect everyone in the
globe and also support the emerging new protocol and many Internet-based
services that already exist and undoubtedly will be growing up at least during
the next few years.
Unfortunately satellite
technology providers have been among the last to offer IPv6 based solutions. At
present, if you google something like: “IPv6
satellite hubs” you won’t get an easy link to click on, and then, if you
hit on the results, you won't find major
Satellite vendors that specifically support IPv6 Hubs. As far as I know, last
year there was only one Satellite Hub manufacturer that added IPv6 support to
its solution. Saying that, we have seen a change, though small, by one supplier.
There looks to be already products (very few) on the market with native
-IPv6- implementations. My belief is that with some support from the community,
and probably from some organization and collaboration we can do this
combination a “must to have” among satellite hubs suppliers. We think that if
the satellite industry keeps growing without
IPv6, it will be worse for it in the long term. Our assumption is based upon
what IPv6 has to offer and what the lack
of it might do to remote locations: 1) missing IPv6 in satellite technology in
those locations will hurt IPv6 deployment, 2) Those places won’t enjoy some
benefits offered by IPv6.
Finally, I would like to mention that
traditional problems found in satellite links such as: 1) round trip delay and
2) costs; are being solved with new technologies. Also there are some new
initiatives that will boost even more this situation.
Conclusion:
The combination of satellite links and IPv6 is
the right way to provide Internet access in very remote places in order to
prepare for the current and the future of Internet-based services.
Wednesday, May 29, 2013
Thursday, February 21, 2013
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!
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!
Monday, January 14, 2013
IPv6 crosswords puzzle
http://goo.gl/lVuv6
I hope you enjoy it :)
I hope you enjoy it :)
Subscribe to:
Posts (Atom)