Category Archives: Cisco

JUNIPER JUNOS COMMAND SERIES – 2

Hi All, lets continue our useful Junos command series by looking at 2 more interesting commands. One is really a way of doing same thing as in Cisco however 2nd is completely different command n I doubt available in other vendor CLIs.

We will look at configuration from interface stanza but can be applied to other areas.

So this is our example interface config from one of the interface.

re0.MX104_PE> show configuration interfaces ge-0/0/1
description "Test";
mtu 1600;
hold-time up 0 down 1000;
unit 0 {
 family inet {
 address 10.0.0.170/30;
 }
 family mpls;
}

Now due to any reason the interface which you were using has changed and now you need to put the same config on lets support ge-0/0/3

Lets look at current config of ge-0/0/3

re0.MX104_PE> show configuration interfaces ge-0/0/3
re0.MX104_PE>

As expected, config is empty and nothing has been configured.

Ok to configure the same parameters on new interface, one method is to go n set each configuration stanza individually. i.e..

edit
edit interface ge-0/0/3
set description “Test”
etc etc…

which is valid method but time consuming. Junos gives us facility to do the same thing by using command “copy

Using this command, you can copy the config from one interface to another without going through all those lengthy steps.

re0.MX104_PE> edit
Entering configuration mode
[edit]
re0.MX104_PE# copy interfaces ge-0/0/1 to ge-0/0/3

[edit]
re0.MX104_PE# show | compare
[edit interfaces]
+ ge-0/0/3 {
+ description "Test";
+ mtu 1600;
+ hold-time up 0 down 1000;
+ unit 0 {
+ family inet {
+ address 10.0.0.170/30;
+ }
+ family mpls;
+ }
+ }


re0.MX104_PE# delete interfaces ge-0/0/1

re0.MX104_PE# show | compare
[edit interfaces]
- ge-0/0/1 {
- description "Test";
- mtu 1600;
- hold-time up 0 down 1000;
- unit 0 {
- family inet {
- address 10.0.0.170/30;
- }
- family mpls;
- }
- }
+ ge-0/0/3 {
+ description "Test";
+ mtu 1600;
+ hold-time up 0 down 1000;
+ unit 0 {
+ family inet {
+ address 10.0.0.170/30;
+ }
+ family mpls;
+ }
+ }

So you can see this has made the configuration easy to move.

Only catch here is that target interface in which you want to copy the configuration should be totally empty of any configuration otherwise you will see error like this.

re0.MX104_PE# copy interfaces ge-0/0/1 to ge-0/0/3
error: target statement 'ge-0/0/3' already exists

Ok so that’s was one command

Lets move over to next command which is similar to Cisco or might be to other vendors but most of the Juniper engineers are not aware of this.

This is to delete the whole interface config and put that into default mode.

In Cisco IOS, we would be doing something like default interface <interface name> under config mode to put the config into default config.

In Juniper to achieve the same thing, you need to either delete individual statements under interface config or you can just mention delete at the top interface level which would prompt you for confirmation and will delete everything.

[edit]
re0.MX104_PE# edit interfaces ge-0/0/1

[edit interfaces ge-0/0/1]
re0.MX104_PE# show
description "Test";
mtu 1600;
hold-time up 0 down 1000;
unit 0 {
 family inet {
 address 10.0.0.170/30;
 }
 family mpls;
}

[edit interfaces ge-0/0/1]
re0.MX104_PE# delete
Delete everything under this level? [yes,no] (no) yes

[edit interfaces ge-0/0/1]
re0.MX104_PE# show | compare
[edit interfaces ge-0/0/1]
- description "Test";
- mtu 1600;
- hold-time up 0 down 1000;
- unit 0 {
- family inet {
- address 10.0.0.170/30;
- }
- family mpls;
- }

Only difference is that in Cisco using “default”, there will still be configuration present under interface like “no ip address” etc etc however in Junos, this will delete everything under it.

So that’s all, I hope you liked this article as well and will make use of these commands in your day to day operational work or troubleshooting.

Regards

Mohit Mittal

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

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

BGP Route Distinguisher vs Route Target

In this post I will try to clarify the difference between route distinguisher and route target within the Cisco world of MPLS VPN’s. The main confusion comes from the fact that in most Cisco Press books they always show the route distinguisher value and route target value as the same.
They are not the same and are used for completely different things.
In simple terms the route distinguisher is used to create a unique 96 bit address called the VPNv4 address.
This ensures that even if two customers are running the 10.0.0.0/8 address space their addresses remain unique within the MPLS network.
The Route Target is a 64 bit BGP community used to tag prefixes. It tells the Remote PE routers which prefix it can import.

Route Distinguisher

The route distinguisher has only one purpose, to make IPv4 prefixes globally unique. It is used by the PE routers to identify which VPN a packet belongs to, e.g to enable a router to distinguish between 10.0.0.1/8 for Customer A and 10.0.0.1/8 for Customer B. The route distinguisher is made up of an 8 byte field prefixed to the customer 4 Byte IPv4 address, the resulting 12 byte field makes a unique VPNv4 address.

RD

R1(config)#ip vrf Customer_A

If we type “rd ?” you can see 2 options for configuring the RD..

R1(config-vrf)#rd ?
ASN:nn or IP-address:nn VPN Route Distinguisher

For the purpose of this description I will configure the RD value as 65355:10 which AS number 65535 and Unique value 10 combinatin

R1(config-vrf)#rd 65355:10

To verify this value enter the command sh ip vrf
R1#sh ip vrf
Name Default RD Interfaces
Customer_A 65355:10

Route Target

The route target on the other hand is an 8 byte field which is a BGP extended Communities Attribute and it defines which prefixes are exported and imported on the PE routers.

RT

So for example consider Router R3 has 2 VRF’s configured on it “Customer_A” and “Customer_B” so you would define under each vrf a unique route target value, these take the same format as the route distinguisher, but for the purpose of this explanation we are going to use 1:1 for Customer_A and 2:2 for Customer_B. On R3 we want to export and import the prefixes for Customer A and B, however on router R1 we only want to import and export the prefixes for Customer_A and on router R2 we only want to import and export the prefixes for Customer_B

To conclude, the route distinguisher and route target values perform two completely separate functions, and although in a lot of cisco books the values are the same (which they can be) it is confusing to someone learning MPLS for the first time as they assume they do the same thing.
The route distinguisher makes a unique VPNv4 address across the MPLS network and the route target defines which prefixes get imported and exported on the PE routers.

 

Regards

Mohit Mittal

 

MC – LAG (Multi-Chassis LAG)

Networks of today demands lot of redundancy, be it link level redundancy or device level. Service providers employ various methods to provide this level of service for their customers and one of way is Link Aggregation Group (LAG) where multiple Ethernet links are combined to form a single aggregated group, thereby increasing bandwidth and providing redundancy. This layer 2 transparency is achieved by the LAG using a single MAC address for all the device’s ports in the LAG group. LAG uses a control protocol called LACP for its operation.

Instead of having multiple link i.e 2, 4 or 8 aggregated in one Lag, vendors suggested a proprietary solution to have the device level redundancy built as well in Lag and result was Multi-chassis Lag (MC-LAG). As this is proprietary solution, all the vendors do support it but with little difference from one another. Cisco calls this solution as Multichassis Ether Channel, Alcatel calls its MC-LAG.

The CE (Customer Edge) device is completely unaware that its Ethernet links that belong to the same LAG (Etherchannel in Cisco) are connected to two separate PE (Provider Edge) devices. We can assume PE device here as Alcatel 7750. The two PE routers each have one LAG connected to the same CE device. At a time, only one PE router’s LAG ports are active and carrying traffic. The other PE router’s LAG ports are standby and only become active when failure is detected in the active links. The PE routers perform election to decide the active and standby router.

Picture1

If you see the above figure, from CE’s perspective, all 4 ports belonging to a LAG are connected to a single service provider device (here PEs). All 4 ports are active, but only 2 ports are UP at a time; the other 2 ports are in DOWN state. On the both PE routers, as before we have to create a regular LAG towards the CE device and on top of that we configure MC-LAG separately where we define MC-LAG peer (i.e. 2nd PE address) and LACP parameters. The MC-LAG control protocol information is exchanged between PE routers. This exchange results in active/standby selection, and ensures only one PE router’s ports are active and carrying traffic.  MC-LAG control protocol runs only between MC-LAG peers. Both PE routers send an exactly same {Admin Key, System ID, System Priority} information in the LACP packets.

Link Aggregation Control Protocol (LACP) detects multiple links available between two devices and configures them to use as an aggregate bandwidth. The two sides detect the availability of the other side by sending LACP packets. One end is an Actor, while the other end is the Partner. During LACP negotiation, (Admin Key, System ID, System Priority) identifies the LAG instance. So, for a LAG, all participating ports on that device must have the same values for these 3 fields.

 

Regards

Mohit Mittal

 

OSPFv3 for IPv6 alone or IPv4 as well?

We know that OSPFv2 is Link state routing protocol developed by IETF as a robust IP routing protocol suitable for large networks and to carry Ipv4 addresses. OSPF was first documented as a standard by John Moy in RFC 1131 and further Improvements were made in OSPF version 2. OSPF was then extensively modified by IETF to support IPv6 and called OSPFv3. But do you know OSPFv3 can be used to carry IPv4 addresses as well?

Before going into it, let’s review some differences between OSPFv2 and OSPFv3

  • OSPFv3 introduces new LSA types
  • OSPFv3 has different packet format
  • OSPFv3 adjacencies are formed over link-local IPv6 communications
  • OSPFv3 runs per-link rather than per-subnet
  • OSPFv3 supports multiple instances on a single link, Interfaces can have multiple IPv6 addresses
  • OSPFv3 uses multicast addresses FF02::5 (all OSPF routers), FF02::6 (all OSPF DRs)
  • OSPFv3 Neighbor Authentication done with IPsec (AH)
  • OSPFv2 Router ID (RID) must be manually configured, still a 32-bit number

Ok, now coming back to original question. If an organization wanted to use OSPF for both their IPv4 and IPv6 routing protocol, then they would likely use OSPFv2 for their IPv4 routing and OSPFv3 for their IPv6 routing. This would give the organization dual control planes for dual forwarding protocols. In this configuration, if there was a problem with either routing domain then it would not affect the other IP version. The same separation could also be achieved by running two completely different routing protocols. For instance, an organization could use OSPFv2 for IPv4 and IS-IS in single-protocol single-topology mode for IPv6. The IETF has continued to develop OSPFv3 so that it is now capable of working with multiple address families. In much the same way as Multi Protocol Border Gateway Protocol (MP-BGP) can function as an IPv4 and IPv6 routing protocol.

Once again, Cisco changed the IOS configuration commands required for OSPFv3 configuration. The new OSPFv3 configuration uses the “ospfv3” keyword instead of the earlier “ipv6 router ospf” routing process command and “ipv6 ospf” interface commands. OSPFv3 is still configured on the interfaces similarly to how the previous OSPFv3 commands were used. However, the biggest change is in the configuration of the routing process. This new syntax is more like multi-Address Family configuration of BGP and you have both an IPv4 and an IPv6 address family configuration section under “router ospfv3 “. New OSPFv3 syntax is used to configure a dual-protocol interface and for multi-address-family configuration under the OSPFv3 routing process is:

ipv6 unicast-routing
ipv6 cef
!
router ospfv3 <process-id>
router-id <router-id>
auto-cost reference-bandwidth 1000
address-family ipv6 unicast
area 0 range <range>
area 1 range <range>
address-family ipv4 unicast
area 0 range <Ipv4 range>
area 1 range <Ipv4 range>

So, OSPF is now evolved into a fully dual-protocol multi-AF routing protocol. Organizations now have multiple options for deploying OSPF. Organizations can stick with OSPFv2 for IPv4, and then use OSPFv3 for IPv6-only for a configuration that separates the control planes and the forwarding planes. Organizations can now combine the configuration of IPv4 and IPv6 into a single OSPFv3 process that can work equally well for both IP protocols.

 

Regards

Mohit Mittal