ARP, InARP, RARP, Proxy ARP & Gratuitous ARP?? Whats this all about!!

There are lots of Arp terms in Network field today i.e. ARP, RARP, InARP, Proxy ARP and Gratuitous ARP. This was really confusing for me atleast in my early networking days and I am sure people who are new to networking must be in same situation. So I thought of putting the details here in order to alleviate their confusion. So let’s start

 1) ARP (Address Resolution Protocol)

ARP or Address Resolution protocol is a protocol as its name states which works on TCP/IP Layer 2. Networking between devices can’t be done without using this protocol which basically helps in getting the mac-address of connected router or gateway from IP Address. So for example, host/computer is connected to Router over Ethernet and we have manually configured IP Addresses on both sides with Router acting as Gateway for Host computer. Before Host can send packet to Router, it needs to build Layer 2 Frame and this frame encapsulates Packet including Payload/Date. You know that Frame has Source MAC-Address and Destination MAC-Address fields apart from other fields. So host can take out source-mac address from value burned in its NIC (Network Interface card) however it won’t be knowing the destination mac-address and in order to get the value of destination mac address host uses ARP. So Host will send broadcast ARP request message (destination FF:FF:FF:FF:FF:FF MAC address), which is accepted by all computers, requesting an answer for router’s gateway mac-address which is returned by Router in form for Arp-reply as a unicast.

APR_Packet Format

54:1e:56:f7:7d:4a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 602, p 0, ethertype ARP, arp who-has 20.20.20.20 tell 20.20.20.200

00:00:00:5e:00:00 > 54:1e:56:f7:7d:4a, ethertype 802.1Q (0x8100), length 64: vlan 602, p 0, ethertype ARP, arp reply 20.20.20.20 is-at 00:00:00:5e:00:00

2) InARP ( Inverse ARP)

Now what is Inverse Arp then? Inverse ARP as you might guess is the opposite of ARP.  Instead of using layer 3 IP address to find a layer 2 MAC address, Inverse ARP uses layer 2 MAC addresses to find a layer 3 IP address.

Inverse ARP was mostly used by Framerelay and ATM Networks to map the DLCI to IP Address. So router basically asks the IP Address of destination or other end of PVC by listing DLCI for that router.

3) RARP (Reverse ARP)

Reverse ARP is same as Inverse ARP however it was mainly used for device configuration. In InARP IP Address of remote end was being asked however RARP task is to get the IP Address for its own purpose.

A network administrator creates a table in a local area network’s gateway router that maps the physical machine (or Media Access Control – MAC address) addresses to corresponding IP Addresses. When a new machine is set up, its RARP client program requests it’s IP Address from the gateway router. Assuming that an entry has been set up in the router table, the RARP server will return the IP address to the machine which can store it for future use.

Reverse ARP has been deprecated and replaced by BOOTP which was then later replaced by DHCP.

4) Proxy ARP

As we mentioned above that the ARP is basically to find out Layer 2 address from Layer 3 IP Address. Now suppose host is connected to router over Ethernet and host has one address 10.10.0.1/16 and router has 10.10.10.0/24.

Host wants to resolve the ARP for 10.10.0.100 and thinks that Router is also in same subnet so should be able to get the mac-address however as Routers by design limit broadcast domains so won’t be sending the arp reply back and request will be rejected. If on the other hand router has any other interface connected to 10.10.0.0/16 network and proxy-arp is enabled, in that case Router will send the arp reply to host by listing its own mac-address basically acting as proxy for destination Network. In this case we don’t have to change the netmask of host and it will work fine.

On Cisco interfaces, when we configure “no ip proxy-arp”, we are disabling this behaviour.

5) Gratuitous ARP

Gratuitous ARP is by far the interesting version of ARP and lets see how gratuitous ARP works. We will go through 2 use cases here:

Firstly let’s discuss some of the properties of GARP

  • Both source and destination IP in the packet are the IP of the host issuing the gratuitous ARP
  • The destination MAC address is the broadcast MAC address (ff:ff:ff:ff:ff:ff) . This means the packet will be flooded to all ports on a switch
  • No reply is expected

1st use case of GARP is finding duplicate IP Address on LAN. Host which wakes up lets say after reboot sends GARP by putting the Sender IP address and Target IP Address as its own IP and broadcast the frame using Ethernet II destination address of all FFs.

It is not expecting any reply however if someone replies back with mac-address corresponding to Target IP Address then it means that IP address is being used somewhere else in LAN which is a problem. In this way host can detect duplicates.

2nd use case of GARP is case of redundancy protocols like VRRP/HSRP. VRRP (Virtual Redundancy Routing Protocol) or HSRP works by providing redundant physical gateways to host reachable over same Virtual address in order for Host to reach destination networks even though one physical router is down.

GARP_VRRP

VRRP has VIP (Virtual IP) concept which is shared among 2 VRRP routers and one of them is Active at any one time and holds Virtual MAC-Address corresponding to this VIP. Whenever host requests for ARP for 10.1.1.1, Master router will reply back with Virtual MAC Address.

Now we know that Switch updates its MAC Address table by looking at Mac address being learned on which port. Assuming Router 1 is Master currently, Switch will have entry in its table for Virtual Mac address learnt via Eth1 interface.

Let’s suppose that Router 1 goes down and in that case Router 2 sends GARP forcing switch to update its MAC-address table in order for it to update new location of Virtual MAC address reachable over new port i.e Eth2.

In this way, Host never sees an issue and packets sent by it will always egress a correct port.

Format of Gratuitous ARP

GARP Format

So that’s all, I hope you enjoyed this blog and I was able to clear some of your confusion. Let me know if you still have any doubt.

Thanks

Mohit Mittal

Advertisements

Juniper JunOS Command Series – 1

Hi All, from this series we will look at some useful JunOS commands and concepts where Juniper give us flexibility over other vendors and I hope this will help you in case you are switching from other vendor products to JunOS.

We will look at example from interface configuration however same can be applied to any stanza or part of configuration in Junos.

Lets start with configuration of interface ge-0/0/7 where 3 logical units have been defined and this link is made to participate in 3 vlans correspondingly.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

However later some requirement change and because of it you need to change the ip addressing on one of the unit from 10.10.10.5 to say 20.20.20.5.

Now one way of doing this in Junos is to configure the new address in below fashion!!

MX104>edit
Entering configuration mode

[edit]
MX104# edit interfaces ge-0/0/7

[edit interfaces ge-0/0/7]
MX104# set unit 100 family inet address 20.20.20.5/30

But this has created an additional row under the interface stanza for which we have to write one delete statement to delete previous 10.10.10.5 address.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 10.10.10.5/30;
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}
 
[edit interfaces ge-0/0/7]
MX104#delete unit 100 family inet address 10.10.10.5/30

Final config is:

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

This method is fine for one change however not a very quick method. Junos gives us ability to change this value in very quick way by using “rename” command.

(NOTE: I did rollback the changes made above before proceeding further in order for interface configuration to be at same stage from where I started my blog)

Rename command renames the value of particular variable to new value and you need to mention the whole command hierarchy or go to level where you want the change to be applied. This is easy method to achieve same thing in less number of changes.

[edit interfaces ge-0/0/7]
MX104# rename unit 100 family inet address 10.10.10.5/30 to address 20.20.20.5/30

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
}

Now, what if you want to change all IP Addresses under interface ge-0/0/7 stanza to use 20.20.20.x address rather than 10.10.10.x.. 2 methods can be set/delete and rename as we saw above however we have to define 2 rename statements in our case to change the ip addresses on remaining unit 200 and unit 300.

Again Junos is to the rescue and this time we will use another command “replace”. Replace command replaces the pattern you want to be replaced with new pattern.

Let’s see it in action.

Below is our configuration after we changed unit 100 with new ip address using rename command.

MX104> show configuration interfaces ge-0/0/7
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 10.10.10.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 10.10.10.13/30;
    }
} 

Now we have to change the ip addresses on unit 200 and unit 300 and in that case we can achieve this by using below command:

[edit interfaces ge-0/0/7]
MX104# replace pattern 10.10.10 with 20.20.20

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}

Pretty exciting and fast !!! 🙂

One thing to remember is that you have to be in exact hierarchy where you want this pattern to be replaced. If you are at the Top level i.e under edit hierarchy only, then this will replace all instances of 10.10.10 with 20.20.20 whereever it is in whole config and not just ge-0/0/7.

Let’s see this in action one more time.

below is our configuration resulting from replace method. Now lets assume that we have to change all units and accordingly vlan’s last 2 digits from 00 to 10.. so unit and vlan id needs to be changed from 100, 200 and 300 to 110, 210, and 310 respectively.

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 100 {
    vlan-id 100;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 200 {
    vlan-id 200;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 20.20.20.13/30;
    }
}


[edit interfaces ge-0/0/7]
MX104# replace pattern 00 with 10

[edit interfaces ge-0/0/7]
MX104# show
description Test;
vlan-tagging;
unit 110 {
    vlan-id 110;
    family inet {
        address 20.20.20.5/30;
    }
}
unit 210 {
    vlan-id 210;
    family inet {
        address 20.20.20.9/30;
    }
}
unit 310 {
    vlan-id 310;
    family inet {
        address 20.20.20.13/30;
    }
}

So that’s all, I hope you liked this article and will make use of these commands in your day to day operational work or troubleshooting. In future blogs we will see more useful commands and till then, have a nice day..

 

Regards

Mohit Mittal

 

 


	

L2VPN using Kompella – Junos

In my earlier blog on L2VPN via CCC https://networkzblogger.com/2017/04/23/l2vpn-via-ccc-in-junos/ we saw in that method customer interface needs to be bind with LSP and for each customer we need to have separate LSP configured which is not ideal from operational perspective. In this blog we will look at another method of achieving this where BGP is used as signalling protocol which automates the connections, so manual configuration of the association between the LSP and the customer edge interface is not required.

This config is also called Kompella after its author (https://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00) where BGP is used to signal the control plane and it uses a two label stack as Martini. The VC (VPN) label is signalled via BGP and transport label can be signaled via either RSVP or LDP.

We would be looking at below topology where we will be configuring the MPLS L2VPN or Juniper L2CIRCUIT between M10i and MX960 PEs. M320s in between are just acting as Transit P/PE nodes and no configuration specifically needed on them for L2VPN however normal RSVP/LDP/MPLS/IGP config needs to be configured for transport label same as how L3VPN works.

L2VPN Kompella

MX104s are acting as RR so BGP neighborship will appropriate family needs to be activated between PEs-RRs.

For BGP based L2VPNs, following configuration needs to be configured

  1. BGP group with family l2vpn signalling
  2. Routing instance using instance type “l2vpn”
  3. Ethernet link needs to be established with Customer and same needs to be defined under Routing-instance.

Let’s start with Juniper l2vpn configuration.

First BGP Group where l2vpn signalling family needs to be enabled for PE-RR group.

BGP neighborship between M10i and one of the RR.

M10i-PE> show configuration protocols bgp group L2VPN-RRs
type internal;
family l2vpn {
    signaling;
}
authentication-algorithm md5;
authentication-key-chain BGP-L2VPN-key-chain;
neighbor 10.198.123.234;  <<<<<<<<< Loopback of RR1
neighbor 10.198.123.237;  <<<<<<<<< Loopback of RR2

BGP neighborship between M10i and one of the RR.

M10i-PE > show bgp neighbor 10.198.123.234
Peer: 10.198.123.234+179 AS 65004 Local: 10.198.123.213+50453 AS 65004
 Group: L2VPN-RRs Routing-Instance: master
 Type: Internal State: Established Flags: <Sync>
 Options: <Preference LocalAddress GracefulRestart LogUpDown AddressFamily Rib-group Refresh>
 Address families configured: l2vpn-signaling
 Local Address: 10.198.123.213 Holdtime: 90 Preference: 170
 Peer ID: 10.198.123.234 Local ID: 10.198.123.213 Active Holdtime: 90
 NLRI for restart configured on peer: l2vpn
 NLRI advertised by peer: l2vpn
 NLRI for this session: l2vpn
 Peer supports Refresh capability (2)
 Restart time configured on the peer: 120
 Stale routes from peer are kept for: 300
 Restart time requested by this peer: 120
 NLRI that peer supports restart for: l2vpn
 NLRI peer can save forwarding state: l2vpn
 NLRI that peer saved forwarding for: l2vpn
 NLRI that restart is negotiated for: l2vpn
 NLRI of received end-of-rib markers: l2vpn
 NLRI of all end-of-rib markers sent: l2vpn.
.
.

Even though customer facing config is not part of MPLS L2VPN, I will define it here which is using l2vpn encapsulation vlan-ccc.

M10i-PE > show configuration interfaces fe-0/1/1
description "Connected to CE-1";
vlan-tagging;
link-mode full-duplex;
encapsulation vlan-ccc;
unit 2 {
 encapsulation vlan-ccc;
 vlan-id 1001;
 family ccc;
}

Fairly simple configuration which is using encapsulation vlan-ccc.

OK, lets move to 2nd and 3rd part which is routing-instance configuration. I have highlighted important bits below. Off course for this L2VPN type you need to define RD, RT, and Interface which I am not mentioning specifically but you can see below.

M10i-PE > show configuration routing-instances L2VPN
instance-type l2vpn;
interface fe-0/1/1.2;
route-distinguisher 10.198.123.213:2;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Audi {
 site-identifier 2;
 interface fe-0/1/1.2 {
 remote-site-id 3;
 }
 }
 }
}

Important bit is instance-type l2vpn which enables this routing-instance for L2VPN. Under protocols l2vpn we have to enable the encap type as ethernet-vlan and then under site parameters we need to be define local site-identifier which is in our case is 2 and an optional remote-site-id. I have defined remote-site-id as 3 which will be configured on MX960 Remote-PE as its local site-identifier.

In same way we will be configuring the MX960 PE

MX960-PE> show configuration interfaces ge-1/1/9.700
encapsulation vlan-ccc;
vlan-id 700;
family ccc;

MX960-PE> show configuration routing-instances L2VPN
instance-type l2vpn;
interface ge-1/1/9.700;
route-distinguisher 10.198.123.205:3;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Bentley {
 site-identifier 3;
 interface ge-1/1/9.700 {
 remote-site-id 2;
 }
 }
 }
}

Once this is configured, let’s check the routing table on M10i

M10i-PE > show route table L2VPN.l2vpn.0
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.198.123.205:3:3:1/96 <<<<<<<<<------------ Learnt from MX960
 *[BGP/170] 13:56:58, localpref 100, from 10.198.123.237
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
 [BGP/170] 13:56:58, localpref 100, from 10.198.123.234
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
.
.
.
10.198.123.213:2:2:3/96 <<<<<<<<-------------- Local route on M10i
 *[L2VPN/170/-101] 16:56:08, metric2 1
 Indirect

This output is showing us RD value of 10.198.123.205:3 plus value of remote-side identifier which is 3 as well plus label-offset value which is 1

In same way, local route has RD value of 10.198.123.213:2 plus value of remote-side identifier which is 2 and label-offset value of 3. Will explain label-offset later.

So this completes our BGP control signalling path.

L2VPN connection state is up between both PEs

M10i-PE > show l2vpn connections up
Layer-2 VPN connections:

Instance: L2VPN
Edge protection: Not-Primary
 Local site: Audi (2)
 connection-site Type St Time last up # Up trans
 3               rmt  Up May 2 20:53:51 2017 1
 Remote PE: 10.198.123.205, Negotiated control-word: Yes (Null)
 Incoming label: 800006, Outgoing label: 800003
 Local interface: fe-0/1/1.2, Status: Up, Encapsulation: VLAN

Now we can move over to forwarding path where we will see MPLS labels. As in case of L3VPNs, we have 2 Labels on each packet i.e. VPN Label and other is transport label.

Transport label is calculated in same way where label is assigned for next-hop which in our case is remote-PE MX960 loopback address and this label can be learnt by any method LDP or RSVP and will be advertised to M10i PE by its immediate neighbour which in our case is M320.

So to check the label stack which is being pushed at M10i, we can see the MPLS.0 table.

M10i-PE > show route table mpls.0
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
.
.
.
fe-0/1/1.2 *[L2VPN/7] 14:27:18, metric2 1
 > via so-0/0/0.0, Push 800003, Push 299888(top) Offset: 252

So you can see two labels are being pushed, TOP (transport) label is 299888 which is advertised by M320

M320-Transit-P-1> show ldp database session 10.198.123.213
.
.

Output label database, 10.198.123.202:0--10.198.123.213:0
 Label Prefix
 306336 10.198.123.100/32
 299808 10.198.123.201/32
 3      10.198.123.202/32
 299792 10.198.123.203/32
 308832 10.198.123.204/32
 299888 10.198.123.205/32
 304288 10.198.123.211/32

VPN Label is 800003 which is calculated little bit differently in case of L2VPNs and not directly advertised by Remote-Pes.

Formula to calculate VPN label is

L2VPN label = Label-Base (remote) + Site-Id(Local) – Label-Offset (remote)

Label-base (remote) value is what we can get from MX960 by looking at its L2VPN.l2vpn table

MX960-PE > show route table L2VPN.l2vpn.0 extensive
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
.
.
 Advertised metrics:
 Flags: Nexthop Change
 Nexthop: Self
 Localpref: 100
 AS path: [65004] I
Path 10.198.123.205:3:3:1 Vector len 4. Val: 0
 *L2VPN Preference: 170/-101
 Next hop type: Indirect, Next hop index: 0
 Address: 0xa5d246c
.
.
.
 Label-base: 800002, range: 2, status-vector: 0x0, offset: 1
 Secondary Tables: L2VPN.l2id.0

You can see above that label-base is 800002 on MX960 and Label-offset value is 1

So as per our equation above,

L2VPN Label = 800002 + 2 (Site-id local on M10i)  – 1  = 800003

Once this VPN Label reaches MX960, it is pop as per normal MPLS procedures and out to CE-2 interface.

800003 *[L2VPN/7] 14:37:16
 > via ge-1/1/9.700, Pop Offset: 4

In same way, MX960 will also calculate the VPN label for traffic flowing from MX960 to M10i.

So that’s all for this blog. I hope you enjoyed it and let me know if you still have any issues.

 

Regards

Mohit Mittal


	

eBGP using IPv6 in Juniper JunOS

Hi All

In my earlier post on VRRP https://networkzblogger.com/2017/04/15/vrrpv6-and-tracking-in-junos/ we looked at VRRPv6 and how VRRP tracking is working on receiving the Ipv6 default route. As that blog was mainly focusing on VRRP, so didn’t explained anything on Ebgp relationship over Ipv6 and IPV6 default route however in this post I will be mainly focusing on it.

Let’s start.

We will be using same Model as we used in earlier post, but in condensed form. Rather than looking at redundant configs, we will concentrate on one EBGP between 2 neighbors.

Below mentioned topology will be used where MX104 CE is connected to Juniper CE-1 ISP and we will have EBGP over IPV6 running between them and MX104 CE in turn receiving Ipv6 default route from ISP.

eBGP_IPv6

Lets look at Interface configs first on both sides.

MX104_CE> show configuration logical-systems LS1-Tower
interfaces {
    ge-0/0/4 {
        unit 600 {
            description "Connected to ISP-CE-1_ge-0/2/0.600";
            vlan-id 600;
            family inet6 {
                address 2a00:2380:3013:1000:0:0:0:3/127;
            }
        }
    }

ISP_CE-1> show configuration interfaces ge-0/2/0
description "Connected to MX104 CE_ge-0/0/4 ";
vlan-tagging;
mtu 1600;
hold-time up 0 down 1000;
link-mode full-duplex;
unit 600 {
    vlan-id 600;
    family inet6 {
        address 2a00:2380:3013:1000:0:0:0:2/127;
    }
}

Fairly straightforward configuration where we used statically configured IPV6 addresses. We could have also used 128-bit IPv6 addresses or we can use link local addresses but only requirement is that with link-local addressing we need to use statement “local-interface”. You can also use eui-64 address where we just need to know the /64 subnet and router auto calculates the ipv6 addresses by concatenating the subnet address with 48 bit mac-address and 16 bit 0xFFFE

Once this is done, let’s see the Ebgp config.

MX104_CE > show configuration logical-systems LS1-Tower protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
export [ Main_Subnets_IPV6 Backup_Subnets_IPV6 ];
local-as 65004;
neighbor 2a00:2380:3013:1000:0:0:0:2 {
    peer-as 2856;
}

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
       peer-as 65004;
}

Again a straightforward configuration on the same lines as Ipv4 where we defined separate group btnet6 for IPV6 config and added the neighbor command with corresponding peer autonomous system.

Now let’s see the bgp status

MX104_CE > show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2  2856          3                      4       0       1           3 Establ
  inet6.0: 0/0/0/0

BGP is up on MX104 CE however it is not receiving anything so let’s advertise IPV6 default route from ISP CE.

We need to manually add the static route under routing-options with discard or reject option (one will send ICMP unreachable and other will silently reject). You can notice the difference from IPV4 static route where there was no need to define the rib.

ISP_CE-1> show configuration routing-instances Internet-600
instance-type vrf;
interface fe-0/1/2.0;
interface ge-0/2/0.600;
interface ge-0/2/0.602;
route-distinguisher 2856:1;
vrf-target target:2856:1;
routing-options {
    rib Internet-600.inet6.0 {
        static {
            route ::/0 discard;
        }
    }
}

Once this is done, configure this under policy-statement and reference that policy as export under neighbor statement.

ISP_CE-1> show configuration policy-options policy-statement default-export-ipv6
from {
    route-filter ::/0 exact;
}
then accept;

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IGUK-IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
    export default-export-ipv6;
    peer-as 65004;
}

Now let’s check the default route on MX104:

Ok we see some activity now.

MX104_CE> show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2   2856                 7                       8       0       2             2:03              Establ
  inet6.0: 1/1/1/0

MX104_CE> show route logical-system LS1-Tower receive-protocol bgp 2a00:2380:3013:1000::2 extensive
inet6.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
* ::/0 (1 entry, 1 announced)
     Accepted
     Nexthop: 2a00:2380:3013:1000::2
     AS path: 2856 I

So we have this default route under MX104 and we used this to under VRRP tracking to track outgoing interface towards ISP.

So that’s all for this blog. If you have any queries, please let me know.

Regards

Mohit


	

L2VPN via CCC in Junos!!!!

L2VPNs are another type of VPNs which Service providers have in their kitty to connect their customers over its MPLS environment. With L2VPNs, service providers extend the Customer LAN over the SP network and customer don’t have any idea that they are connected over the MPLS network. There are many variants of L2VPNs and majority of them use LDP/BGP schemes to configure this. However first method which was implemented for carrying layer 2 traffic over a MPLS network was CCC (Circuit Cross Connect) which we will talk here and still being used by many SPs to connect their customers.

CCC scheme always use an RSVP Signaled LSP which has advantage of taking Traffic Engineering properties of RSVP. For each connection between Customers we need to have a dedicated LSP which is different from LDP/BGP schemes which use same Transport LSP to send the traffic E2E.

As we have dedicated LSP between 2 End Point PEs, there is no concept of VPN Label to associate the corresponding VRF/Customer interface in case of CCC scheme. Also in CCC, as there is only label E2E, we need to disable the PHP (Penultimate Hop Popping) so that Penultimate Hop Router doesn’t Pop the label which would otherwise send plain Ethernet Frame to Egress PE and PE won’t be knowing what to do with this.

For a point-to-point CCC connection, the connection is bidirectional, so an RSVP-signaled LSP is required in each direction between the two PEs.

We will look at configuration of L2VPN via CCC method on Junos where we will use the below Network to configure it.

VPN CCC Model

As the connection needs to be bidirectional, we will only look at the forwarding path from Left to right however other direction would be using the same method.

On Ingress side, Customer CE-1 is connected to ge-0/1/8/.601 interface on MX104 PE and interface config would be:

Re1@Ingress_PE> show configuration interfaces ge-0/1/8
description "Connected to Customer CE-1";
vlan-tagging;
mtu 1522;
encapsulation vlan-ccc;
unit 601 {
    encapsulation vlan-ccc;
    vlan-id 601;
    family ccc;
}

Vlans 512-4094 are only reserved for vlan-ccc encapsulation so you need to use vlan greater than equal to 512.

On Egress side, Customer CE-2 is connected to xe-2/0/0.601 interface on MX960 PE and interface config would be:

Re1@Egress_PE> show configuration interfaces xe-2/0/0
description "Connected to Customer CE-2";
vlan-tagging;
mtu 1522;
encapsulation vlan-ccc;
unit 601 {
 encapsulation vlan-ccc;
 vlan-id 601;
 family ccc;
}

Next config is to create a Label switched path from Ingress to Egress with an optional strict ‘path’ to fully utilize the TE properties otherwise router will dynamically calculate the path towards Egress.

In our case, we have defined the path

So LSP from Ingress MX104 PE to Egress PE MX960 via Transit PE looks like:

Re1@Ingress_PE > show configuration protocols mpls label-switched-path MX104-MX960
to 10.198.123.205;
bandwidth 100m;
optimize-timer 900;
preference 200;
priority 5 0;
primary MX104-MX960; <<<<< Path

Re1@Ingress_PE > show mpls lsp name MX104-MX960
Ingress LSP: 11 sessions
To             From           State Rt P ActivePath LSPname
10.198.123.205 10.198.123.100 Up    0 * MX104-MX960 MX104-MX960
Total 1 displayed, Up 1

LSP is Up and everything looks fine from Ingress to Egress. In same way we have to configure the LSP from MX960 to MX104 in other direction. Once both LSPs are up, we have to bind these LSPs and Ingress Interface under one connection on MX104 and same way in MX960.

Lets check on MX104 Ingress

Re1@Ingress_PE > show configuration protocols connections remote-interface-switch L2VPN
interface ge-0/1/8.601;
transmit-lsp MX104-MX960; 
receive-lsp MX960-MX104;  

Once we have configured this on both sides, we should have this connection Up and running. Lets check this.

Re1@Ingress_PE > show connections remote-interface-switch L2VPN
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:

So we have UP state once config is done on both sides. Our L2VPN is ready to accept and switch the traffic to egress. For any chance if there is any issue in config like vlan-mismatch on other end or LSP is down because of any reason like path or Bandwidth issue, connection won’t be up and we can see from the various legend from the command output showing exactly where is the issue.

Now as Control plane is configured, let’s check how Forwarding plane looks like.

Lets see the label which has been allocated by Ingress PE for this LSP.

Re1@Ingress_PE > show rsvp session ingress up name MX104-MX960
Ingress RSVP: 11 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up    0 1 FF         - 307680   MX104-MX960
Total 1 displayed, Up 1, Down 0

Re1@Ingress_PE > show route table mpls.0 label-switched-path MX104-MX960 extensive
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Restart Complete
ge-0/1/8.601 (1 entry, 1 announced)
TSI:
KRT in-kernel ge-0/1/8.601.0 /32 -> {Push 307680}
 *CCC Preference: 200/1
 Next hop type: Router, Next hop index: 829
 Address: 0x2b4c224
 Next-hop reference count: 2
 Next hop: 10.0.0.169 via ge-0/0/1.0 weight 0x1, selected
 Label-switched-path MX104-MX960
 Label operation: Push 307680
 Label TTL action: no-prop-ttl
 Session Id: 0x3
 State: 
 Local AS: 65004
 Age: 19:10 Metric: 328
 Validation State: unverified
 Task: MPLS
 Announcement bits (1): 0-KRT
 AS path: I

Lets look at Transit PE-1. As you can see below, Label from MX104 Ingress is being swapped here with 300928.

Re1@Transit-PE-1> show rsvp session transit name MX104-MX960
Transit RSVP: 13 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      307680  300928 MX104-MX960
Total 1 displayed, Up 1, Down 0

Similarly on Transit PE-2

Re1@Transit-PE-2> show rsvp session transit name MX104-MX960
Transit RSVP: 7 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      300928  300427  MX104-MX960
Total 1 displayed, Up 1, Down 0

At Egress PE,

Re1@Egress-PE> show rsvp session egress up name MX104-MX960
Egress RSVP: 29 sessions
To             From           State Rt Style Labelin Labelout LSPname
10.198.123.205 10.198.123.100 Up 0 1 FF      300427  -        MX104-MX960
Total 1 displayed, Up 1, Down 0

Re1@Egress-PE> show route table mpls.0 label 300427 extensive
mpls.0: 81 destinations, 81 routes (81 active, 0 holddown, 0 hidden)
Restart Complete
300427 (1 entry, 1 announced)
TSI:
KRT in-kernel 300427 /52 -> {Pop }
 *CCC Preference: 7
 Next hop type: Router, Next hop index: 1725
 Address: 0xe9414fc
 Next-hop reference count: 2
 Next hop: via xe-2/0/0.601, selected
 Label operation: Pop
 Load balance label: None;
 Label element ptr: 0xa7c8780
 Label parent element ptr: 0x0
 Label element references: 20
 Label element child references: 0
 Label element lsp id: 0
 Session Id: 0x0
 State: 
 Local AS: 65004
 Age: 2d 2:21:13
 Validation State: unverified
 Task: MPLS global
 Announcement bits (1): 1-KRT
 AS path: I

Just to confirm this all, you can use the below command on Ingress/Egress PE which shows what all labels being pushed and used for this LSP via CCC.

Re1@Ingress_PE > show connections remote-interface-switch L2VPN labels
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
  Outgoing labels: Push 307680

Re1@Egress_PE > show connections remote-interface-switch L2VPN labels
CCC and TCC connections [Link Monitoring On]
Legend for status (St): Legend for connection types:
 UN -- uninitialized if-sw: interface switching
 NP -- not present rmt-if: remote interface switching
 WE -- wrong encapsulation lsp-sw: LSP switching
 DS -- disabled tx-p2mp-sw: transmit P2MP switching
 Dn -- down rx-p2mp-sw: receive P2MP switching
 -> -- only outbound conn is up Legend for circuit types:
  Incoming labels: 300427
 Outgoing labels: Push 301040

Others labels shown in above commands are for opposite direction from Egress to Ingress.

So that’s all for L2VPN CCC. I hope I have been able to clear your doubts if you had any. if you have any queries, please let me know. In future blogs, we will discuss other methods of doing L2VPN.

Regards

Mohit

How to find SNMP OID in JunOS

Before we got into that, lets see what is SNMP?

Simple Network Management Protocol (SNMP) is an application–layer protocol for exchanging management information between network devices. It is a part of Transmission Control Protocol⁄Internet Protocol (TCP⁄IP) protocol suite.

SNMP is one of the widely accepted protocols to manage and monitor network elements. Most of the professional–grade network elements come with bundled SNMP agent. These agents have to be enabled and configured to communicate with the network management system (NMS).

SNMP consists of

SNMP Manager:

A manager or management system is a separate entity that is responsible to communicate with the SNMP agent implemented network devices. This is typically a computer that is used to run one or more network management systems.

Managed Devices:

A managed device or the network element is a part of the network that requires some form of monitoring and management e.g. routers, switches, servers, workstations, printers, UPSs, etc…

SNMP Agent:

The agent is a program that is packaged within the network element. Enabling the agent allows it to collect the management information database from the device locally and makes it available to the SNMP manager, when it is queried for. These agents could be standard (e.g. Net-SNMP) or specific to a vendor (e.g. HP insight agent)

Every SNMP agent maintains an information database describing the managed device parameters. The SNMP manager uses this database to request the agent for specific information and further translates the information as needed for the Network Management System (NMS). This commonly shared database between the Agent and the Manager is called Management Information Base (MIB).

In other words, MIB files are the set of questions that a SNMP Manager can ask the agent. Agent collects these data locally and stores it, as defined in the MIB. So, the SNMP Manager should be aware of these standard and private questions for every type of agent.

Management Information Base (MIB) is a collection of Information for managing network element. The MIBs comprises of managed objects identified by the name Object Identifier (Object ID or OID).

A typical object ID will be a dotted list of integers. For example, the OID in RFC1213 for “sysDescr” is .1.3.6.1.2.1.1.1

SNMP

Now the real question…how to find the SNMP OID corresponds to SNMP Object name in Junos?

For that firstly, we need to find the exact object name

Lets say we have to check the OID corresponding to BGP AS, in this we can either give the command as following:

show snmp mib walk 1 | match bgp

This will be give us number of results however if we already know the object name then we can match that specific name. Currently I don’t know so I just mentioned bgp and it gave me lots of output.

RE-1> show snmp mib walk 1 | match bgp

bgpVersion.0 = 10

bgpLocalAs.0 = 65004

bgpPeerIdentifier.10.0.0.241 = 0.0.0.0

bgpPeerIdentifier.10.10.10.10 = 0.0.0.0

bgpPeerIdentifier.10.10.10.14 = 0.0.0.0

bgpPeerIdentifier.10.10.10.18 = 0.0.0.0

bgpPeerIdentifier.10.30.205.2 = 0.0.0.0

bgpPeerIdentifier.10.30.205.6 = 0.0.0.0

.

.

.

I can see one of the output is bgpLocalAs.0 which is I am after, so lets see how we can get the OID corresponding to it.

RE-1> show snmp mib walk bgpLocalAs | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/15.1F6/junos">
    <snmp-object-information xmlns="http://xml.juniper.net/junos/15.1F6/junos-snmp">
        <snmp-object>
            <name>bgpLocalAs.0</name>
            <object-value-type>number</object-value-type>
            <object-value>65004</object-value>
            <oid>1.3.6.1.2.1.15.2.0</oid>
        </snmp-object>
    </snmp-object-information>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Here it is , so we got the OID and you can use this OID in NMS systems to poll this specific object.

Regards

Mohit

Advertisements
Advertisements