Internet blackout to protest SOPA

The Stop Online Piracy Act (SOPA), also known as House Bill 3261 or H.R. 3261, is a bill that was introduced in the United States House of Representatives on October 26, 2011. The bill, if made law, would expand the ability of U.S. law enforcement and copyright holders to fight online trafficking in copyrighted intellectual property and counterfeit goods.

The originally proposed bill would allow the U.S. Department of Justice, as well as copyright holders, to seek court orders against websites accused of enabling or facilitating copyright infringement. Depending on who makes the request, the court order could include barring online advertising networks and payment facilitators from doing business with the allegedly infringing website, barring search engines from linking to such sites, and requiring Internet service providers to block access to such sites. The bill would make unauthorized streaming of copyrighted content a crime, with a maximum penalty of five years in prison for ten such infringements within six months. The bill also gives immunity to Internet services that voluntarily take action against websites dedicated to infringement, while making liable for damages any copyright holder who knowingly misrepresents that a website is dedicated to infringement.

A development such as this is extremely harmful to the Internet and would significantly alter the way Internet works. This could not possibly be construed as a US National issue. The implications of US decisions on Internet Policy stretches beyond its borders, worldwide. SOPA / PIPA seek intervention on sites that are non-US sites as well, and naturally US would do extended work on the basis of an ACT like this to cover the rest of the world with the 'wisdom' enshrined in the Act.

Click Here To Read Rest Of The Post...

MEF Service Level Aggrements In Interconnect Networks

Topic Covered:-
1. Three Class Of Service(CoS) Model Framework
2. Delivering Service Level Aggrement
3. Bandwidth Profiling Model
4. Performance

MEF Service Level Aggrement

View more presentations from shivlu.

Click Here To Read Rest Of The Post...

Public Internet Registry Purposes .NGO

Public Internet Registry purposes ".NGO" as the exclusive domain for local and global non-governmental organizations looking to advance their mission.


Click Here To Read Rest Of The Post...

Implementation of EoMPLS (Ethernet Over MPLS)

Introduction
Layer 2 vpn is being used by many of service providers. It can be configure in two ways, one way to use l2 vpn over ip cloud with the help of l2tpv3 and another way is to use over mpls backbone by using encapsulation mpls. In this simulation I will be covering how to configure l2 mpls vpn over mplsvpn cloud.

Figure 1

R0-CE and R4-CE is looking for l2 vpn so that the communication is possible between the both as
they are on same local area network.

How Layer2 MPLS Works
Service provider should use the mpls in the whole cloud to provision l2mpls vpn. The forwarding will be the same as it happens in the case of layer 3 vpn, the only difference is that in that case the customer pool is advertised via MP-iBGP which works as full mesh but in this scenario only point to point will work. If the customer is looking for point to multipoint in that case VPLS (Virtual Private Lan Services) need to be configured which requires minimum of 7600 series router with sip and spa card. In this scenario customer link is terminated on PE router and with the help of xconnect l2 vpn is configured. For every layer2 a unique vc (virtual circuit) is required and the label is generated for that vc only. In our example we are using 100 as vcid, which should be unique on both PEs. When ever the l2 session comes up a new ldp session is being established between the both PEs and the connection is virtually treated as directly connected connection. In simple ldp neighbourship, only directly connected peers can establish the LDP neighbourship but in l2 circuits we get the LDP neighbourship which are not directly connected.

The discovery mechanism is used by the directly connected LDP peers is known to basic discovery
and by l2 circuits is known as extended discovery. Both the peers exchange the targeted hello
messages with each other. TCP session is established by the peers but hellos are exchanged as udp packets over multicast address 224.0.0.2.

Session is always established on loopback address with the remote router and that loopback should be the ldp router id else it won’t work. (Never Perform Loopback Summarization in MPLS)

How The Labels Will Exchange
When the circuit comes up a local label is generated on the basics of vc id and is
exchanged with the remote end router and vice versa.

How The Forwarding Will Work
Labels are already exchanged in the service provider cloud for loopbacks. It means every router is having label information for reaching any other router in the cloud. That label will work as top label which is going to swap at each and every hop underneath that label a vc label is stored which will only come in picture when the packet will reach to its destination PE and that PE has the information of that label against that vc id consequence ip packet will forward towards the customer end.

In figure 1, label 17 is used for IGP and label 19 is used for vc 100. When the packet comes from R0-CE label 19 is imposed on packet against vc 100 and on that one more label is imposed which is 17. In the path only label 17 will be swapped. As in figure1, When label 17 is imposed and forwards to the outgoing interface which is connected to R2-P router. On R2-P router LFIB is checked for label 17 and the outgoing label is showing as pop label because R3-PE is advertising its directly connected interface as implicit null. So at R2-P the top most label is removed and packet is forwarded towards R3-PE with label 19. When the packet reached R3-PE label 19 is checked in local database and come to know that it is being generated for vc 100 consequence ip packet delivered to R4-CE.

How To Check The Status Of Circuit
R1#show mpls l2transport summary
Destination address: 30.30.30.30, total number of vc: 1
0 unknown, 1 up, 0 down, 0 admin down, 0 recovering
1 active vc on MPLS interface Fa0/0
Output 1

How To Check The Neighbourship
R1#show mpls ldp neighbor
Peer LDP Ident: 20.20.20.20:0; Local LDP Ident 10.10.10.10:0
TCP connection: 20.20.20.20.20465 - 10.10.10.10.646
State: Oper; Msgs sent/rcvd: 20/21; Downstream
Up time: 00:11:05
LDP discovery sources:
FastEthernet0/0, Src IP addr: 1.1.1.2
Addresses bound to peer LDP Ident:
1.1.1.2 20.20.20.20 2.2.2.2
Peer LDP Ident: 30.30.30.30:0; Local LDP Ident 10.10.10.10:0
TCP connection: 30.30.30.30.31666 - 10.10.10.10.646
State: Oper; Msgs sent/rcvd: 19/19; Downstream
Up time: 00:09:08
LDP discovery sources:
Targeted Hello 10.10.10.10 -> 30.30.30.30, active, passive
Addresses bound to peer LDP Ident:
2.2.2.1 30.30.30.30
Output 2

How to Check The Label Generated And Received
R1#sh mpls l2transport binding
Destination Address: 30.30.30.30, VC ID: 100
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
Output 3

Output 2 depicts that l2 session is established with peer 30.30.30.30 against VCID 100.
For this particular VCID local label 19 is generated and the 19 is receiving from the
30.30.30.30 peer. The label can be different also. The local label of R1-PE will become
the remote label on R3-PE. Below command depicts the same

R3#show mpls l2transport binding
Destination Address: 10.10.10.10, VC ID: 100
Local Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 19
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Output 4

The output of Output 3 and 4 depicts that the label exchange information is going correct.
The same command can be used for troubleshooting also.

How To Check The MPLS Forwarding
R1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 20.20.20.20/32 0 Fa0/0 1.1.1.2
17 Pop tag 2.2.2.0/30 0 Fa0/0 1.1.1.2
18 17 30.30.30.30/32 0 Fa0/0 1.1.1.2
19 l2ckt(100) 9067 none point2point
Output 5

From Output 5 it is cleared that 17 label is used as outgoing label 19 label is used for vcid 100 which is point to point connection. Now check the output of MPLS forwarding on R2-P router where 17 should be the local label and pop label is used as outgoing label.

R2#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.10.10.10/32 0 Fa0/0 1.1.1.1
17 Pop Tag 30.30.30.30/32 4350 Fa0/1 2.2.2.1
Output 6

How To Check The Label Stack Which Is Depicted In Figure 1
R1#sh mpls l2transport vc 100 detail
Local interface: Fa0/1 up, line protocol up, Ethernet up
Destination address: 30.30.30.30, VC ID: 100, VC status: up
Next hop: 1.1.1.2
Output interface: Fa0/0, imposed label stack {17 19}
Create time: 00:06:10, last status change time: 00:05:37
Signaling protocol: LDP, peer 30.30.30.30:0 up
MPLS VC labels: local 19, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 70, send 70
byte totals: receive 7603, send 7603
packet drops: receive 0, seq error 0, send 0
Output 7

Check End To End Connectivity
R0#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 372/560/756 ms
Output 8

Configurations
R0-CE
interface FastEthernet0/1
Description ### Connected With Service Provider End ###
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto

R1-PE
mpls label protocol ldp
interface Loopback0
ip address 10.10.10.10 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
interface FastEthernet0/1
description ### CE Is Coming On This Interface ###
no ip address
duplex auto
speed auto
xconnect 30.30.30.30 100 encapsulation mpls
!
router ospf 1
log-adjacency-changes
mpls ldp router-id Loopback0 force

R2-P
mpls label protocol ldp
interface Loopback0
ip address 20.20.20.20 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
interface FastEthernet0/1
ip address 2.2.2.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
router ospf 1
!
mpls ldp router-id Loopback0 force


R3-PE
mpls label protocol ldp
interface Loopback0
ip address 30.30.30.30 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
xconnect 10.10.10.10 100 encapsulation mpls
!
interface FastEthernet0/1
ip address 2.2.2.1 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
mpls label protocol ldp
mpls ip
!
router ospf 1
mpls ldp router-id Loopback0 force


R4-CE
interface FastEthernet0/0
Description ### Connected With Service Provider End ###
ip address 192.168.1.2 255.255.255.0
duplex auto
speed auto

Click Here To Read Rest Of The Post...

Split Horizon and Route Poisoning - Layer 3 Routing Loops

Most of the time, I always be a part of layer 2 routing loop discussion but never heard about the engineers talking about layer 3 routing loop problem. This is being experienced during my recent visit in some company where all engineers knows why to use Spanning Tree Protocol but none of them knew why to use split horizon and route poisoning.
In layer 3 networks, there might chance of routing loops and split horizon, hold down timers and route poisoning are the techniques which help to prevent the layer 3 routing loop. Below depicted Figure 1 is showing the converge network. Let’s assume in case of failure of 10.4.0.0 network, router C will forward the update to router B and router B will forward the update to router A and router C as well. By doing this the same kind of the update which is being generated by C is received and C might think that he is getting the information of 10.4.0.0 network from B but In fact, 10.4.0.0 network is directly attached to router C. This situation can arise in smaller networks too.

The first work around is the split horizon technique which says not to send the updates to the interfaces from it has been received. It looks like send update information (Number of interfaces – Receiving Interface Updates).
Next one is route poisoning, when the router detects link down, the attached router sends the update to its neighbors. But in this case, the receiving router can send back the received information to the same interface from where it received by setting the route metric to maximum. Definitely this is the violation of split horizon rule but it helps router to understand about that particular network is down or inaccessible which actually help the convergence of routing. Now 10.4.0.0 is poisoned route which is having the maximum metric assigned as the route is not reachable. When the neighbor send the route back to the originator, it becomes reverse poisoned.

What does route poisoning do?

1. Set the hop count to an unreachable state as soon as the failed network is detected
2. Route remains poisoned until the hold-down timer expires.
3. Hold timer depends on the routing protocol; Every protocol is having different hold-down timer.
4. Only uni direction traffic flow.
5. If the route is not back up during the hold down time period expires, that route is removed from the routing table and added in the garbage table.

The last one is Hold Down timers. What does hold-timers do?
1. A router receives an update from a neighbor indicating that a network that previously was accessible is now no longer accessible.

2. The receiving router marks that route possibly down and starts the hold-down timer.

3. If an update with a better metric for that network is received from any neighboring router during the hold-down period, the network is reinstated and the hold-down timer is removed.

4. If an update from any other neighbor is received during the hold-down period with the same or worse metric for that network, that update is ignored. Thus, more time is allowed for the information about the change to be propagated.

5. Routers still forward packets to destination networks that are marked as possibly down. This allows the router to overcome any issues associated with intermittent connectivity. If the destination network truly is unavailable and the packets are forwarded, black hole routing is created and lasts until the hold-down timer expires. (Very Important Point). This could be the reason, administrators look forward to reduce the hold-down timers to increase the convergence time. Definitely if the network is not stable these timers generates lot of messages.

As per section 2.2.2, RFC 1058 explicitly says that “Split horizon with poisoned reverse will prevent any routing loops that involve only two gateways. However, it is still possible to end up with patterns in which three gateways are engaged in mutual deception.” Definitely this could be the case of broadcast of multi-access networks.

Click Here To Read Rest Of The Post...