[j-nsp] MX loopbacks, routing instances and broadcast/unicast to RE

2011-06-17 Thread Clarke Morledge
This is a side issue related to my last "MX loopback filter and monitor 
traffic" thread:


I am trying to understand how traffic on different routing instances 
(virtual routers, VRFs) get picked up on different loopback interfaces on 
the MX.   I am trying to design appropriate RE-protect filters, but it 
isn't intuitive to me as to how this works on this platform.


For example, let's say I have the global routing instance, plus two VRFs 
(A and B, each one is a separate routing instance):


[edit interfaces lo0]
root@MX-Rtr# show
unit 0 {
description "This interface belongs to the Global routing instance";
family inet {
filter {
input re-protect-global;
}
address 192.168.0.1/32;
}
}
unit 1 {
description "This interface belongs to  VRF A routing instance";
family inet {
filter {
   input re-protect-vrfa;
}
address 192.168.100.1/32;
}
}
unit 2 {
description "This interface belongs to  VRF B routing instance";
family inet {
filter {
   input re-protect-vrfb;
}
address 192.168.200.1/32;
}
}

Here is what I am seeing:  for unicast traffic destined to the RE, traffic 
hits the loopback interface according to the appropriate routing instance; 
e.g. traffic coming into the MX on the global routing instance destined to 
the RE is seen by the filter "re-protect-global",  traffic coming in on 
VRF A is seen by the "re-protect-vrfa" filter, and traffic coming in on 
VRF B is seen by the "re-protect-vrfb" filter.


The same logic applies to multicast traffic.  For example, if you run OSPF 
in different routing instances, the appropriate filters per routing 
instance will see the appropriate OSPF multicast traffic.


Makes sense.

However, broadcast traffic is handled differently.   First, I have 
recently learned that Junos takes the OPPOSITE default position than Cisco 
IOS does on their 6500/7600 platforms.   By default, Cisco does not pass 
on directed broadcast to the Supervisor.  Junos, on the other hand, sends 
all direct broadcast to the RE by default.


Secondly, this broadcast traffic is ALWAYS seen on the "re-protect-global" 
filter -- no matter what routing instance the traffic entered the router 
on.  So, directed broadcast on VRF A does NOT get seen by re-protect-vrfa. 
Directed broadcast on VRF B does NOT bet seen by re-protect-vrfb. Instead, 
you will always see that traffic on the "re-protect-global" filter.


This appears to be true whether or not you are looking at directed 
broadcast on a "sub interface" or on IRBs.


So, I have two questions:  (1) why does Junos send directed broadcast to 
the RE by default, and (2) why does directed broadcast traffic show up on 
lo0.0 irrespective of the "arriving" routing instance?



Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] MX loopback filter and monitor traffic

2011-06-17 Thread Alex
If all of the traffic that comes into the router to the RE via these 
exposed Layer3 interfaces eventually makes it way to the RE via the 
loopback address, at unit 0, why is that the "monitor traffic" command 
does not show me anything?Why is the loopback interface so "special"?


JUNOS lo0 is not the same as CSCO Loopback[0-9][0-9]* (note 
lowercase/uppercase L and numbers).
In JUNOS, the traffic is never looped back via lo0 unlike in IOS 
Loopback[0-9][0-9]*.

Therefore, it is not possible to:
1/ use "monitor traffic interface" on JUNOS lo0
2/ use NAT-on-a-stick with JUNOS lo0
3/ loop the VoIP call thru JUNOS lo0 in Cisco IOS dial-peer style
4/ use FBF for traffic originated from the RE itself

HTH
regards
Alex 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp