@Ashvin
BGP can only introduce detination based routes to their neighbors. There are lots of tools like communities that you mention to make the distribution of more specific routes scripted and reasonably automated.
But at the end of the day, BGP is introducing destination prefixes into the forwarding table and cannot do any source based routing.
Hi Steve,
Agree for BGP which is what I also said in Message 12.
However, from what I understand the requirement is for destination/source-based routing but with the list of addresses to be dynamic and be signalled remotely. This is certainly the case for the DDoS mitigtation case as well.
Apparently, this has been possible using SCU/DCU.
Cheers,
Ashvin
Hi,
Had few observations with regards to the output:
1. I believe the announcement is for IP Transit and can see some prefixes with longer than /24. As a best practice, it is recommended not to announce longer than /24 prefixes
http://archive.apnic.net/meetings/22/docs/tut-routing-pres-bgp-bcp.pdf
2. From the cisco config, I gathered prefixes in AES-ip & TCL-ip were being set local-preference of 500 towards AS9498 and AS4755 respectively. However, since this is eBGP, the local-preference attribute is only local within an AS and does not get announced with the set local-preference to eBGP peers.
To influence inbound routing for specific prefixes, AS-PATH preprend would be more appropriate.
3. The order of the export policies is also import in the configuration. For example:
set protocols bgp group group-1 neighbor 14.142.79.177 export bgp-redistributes set protocols bgp group group-1 neighbor 14.142.79.177 export bgp-policies-group-1-1-export
Policy "bgp-redistributes" already contains accept actions, hence the same prefix does not get evaluated in the next policy. Re-ordering the policy can be beneficial.
There are different ways to configure the policy for AS-PATH preprend. An example could be as below:
It's important that the order of the export policies is in the correct order. Example:
export [ TCL-AS-PREPEND EXPORT-BGP ];
As mentioned before, there could be other ways of writing export policies to achieve the same objective.
Hope this helps.
Cheers,
Ashvin
Hi,
I can confirm that the command works on MX5
root@MX5-R2002> show chassis hardware detail Hardware inventory: Item Version Part number Serial number Description Chassis MX5-T
root@MX5-R2002> start shell pfe network tfeb0 TFEB platform (1000Mhz MPC 8548 processor, 1024MB memory, 512KB flash) TAZ-TBB-0(MX5-R2002 vty)# show jnh 0 pool usage EDMEM overall usage: [NH////////|FW////////|CNTR///////////|HASH////////////|ENCAPS////|------------------] 0 4.0 8.0 14.0 20.7 24.8 32.0M Next Hop [**************|--------|RRRRRRRRRRRRRRRRRRRRRRRR] 4.0M (30% | 70%) Firewall [|----------------------|RRRRRRRRRRRRRRRRRRRRRRRR] 4.0M (<1% | >99%) Counters [*************************|---------------------------------------------] 6.0M (35% | 65%) HASH [********************************************************************************] 6.7M (100% | 0%) ENCAPS [************************************************] 4.1M (100% | 0%) Shared Memory - NH/FW/CNTR/HASH/ENCAPS [--------------------------------------------------------------------------------] 7.2M (0% | 100%) DMEM overall usage: [-] 0 0.0M
Regards
Rakesh
Dear Ashvin,
Thanks for the input , Based on your input i have created a template for changing the existing configuration . I am planning to remove the existing bgp configuration completely and reconfigure based on the attached template . Herewith i have attached the topology diagram . Please suggest for any changes in the template .
Thanks,
Mahesh
Hi,
One thing that comes to mind is ddos-protection.
Could you check:
show ddos-protection protocols [icmp | bgp]
show ddos-protection protocols statistics terse
show ddos-protection statistics
Just in case you see any violation or dropped packets.
May be looking at the logs as well for bgp teardown reasons or ddos.
Cheers,
Ashvin
Hi,
The config template looks ok.
Based on the topology, I am not sure if you have any BGP routes that need to be announced to transits, so below term may not be matched:
set policy-options policy-statement EXPORT-BGP term EXPORT-BGP
You could also aggregate some of the prefixes and announce the aggregate route. Example:
set routing-options aggregate route 123.255.250.0/23 set routing-options aggregate route 203.223.188.0/22 set policy-options policy-statement EXPORT-BGP term EXPORT-AGGREGATE from route-filter 123.255.250.0/23 exact set policy-options policy-statement EXPORT-BGP term EXPORT-AGGREGATE from route-filter 203.223.188.0/22 exact set policy-options policy-statement EXPORT-BGP term EXPORT-AGGREGATE then accept set policy-options policy-statement EXPORT-BGP term EXPORT-STATIC from protocol static set policy-options policy-statement EXPORT-BGP term EXPORT-STATIC from prefix-list-filter EXPORT-BGP exact set policy-options policy-statement EXPORT-BGP term EXPORT-STATIC then accept set policy-options policy-statement EXPORT-BGP term DEFAULT then reject
This could be another method for influencing inbound traffic, by exporting part of the /24s at either transit but the global aggregate at both.
Hope this helps.
Cheers,
Ashvin
Hello,
I have a question regarding the difference between commands.
For example, i setup a network with 3 areas.
(area 1)<->(area 0)<>(area 2)
Area 1 = nssa area with an abr going to area 0.
On area 1's abr i want to summarize the routes from the nssa area so that when it gets to area 2 they are condenced.
So i would think this would be the command layout.
root@area1-R4# show protocols ospf
area 0.0.0.1 {
nssa {
default-lsa {
default-metric 10;
metric-type 2;
type-7;
}
area-range 100.0.0.0/24;
}
But when i look at the abr bordering area 0 and area 2, and a router in area 2 i still only see all the smaller routes and not the summarized routes.
But, if i move the area-range command to be directly under area 0.0.0.1 forinstance
root@area1-R4# show protocols ospf
area 0.0.0.1 {
nssa {
default-lsa {
default-metric 10;
metric-type 2;
type-7;
}
}
area-range 100.0.0.0/24;
I see only the summarized route in the abr facing area 2 and all the routers in area 2 as well.
Is there something i am missing, Could anyone help explain the difference between these two commands?
set protocols ospf area 0.0.0.1 nssa area-range 100.0.0.0/24
and
set protocols ospf area 0.0.0.1 area-range 100.0.0.0/24
Thanks for any help.
set protocols ospf area 0.0.0.1 nssa area-range 100.0.0.0/24
Area range command under NSSA Stanza summarizes Type 7 LSA's before getting translated as Type 5 LSA's
set protocols ospf area 0.0.0.1 area-range 100.0.0.0/24
Area range command specified under area area-number stanza only summarizes intra-area prefixes
So the behavior that was observed in your box is as per expectation (Inter-area prefixes got summarized after
area-range is configured under area area-number stanza.
area-range under nssa stanza is meant for only filtering Type 7 (external routes) for summarization
I dont have box now with me to cite illustration on the same.
I treid it out on my lab and it worked the way you stated. I just couldn't find anything online that pointed out the difference. I think i was looking in the wrong areas online.
I appreciate the help though, Saved me alot of digging around online.
Good that the info is of some help .
[Click the "Star" for Kudos if you think I earned it!}
Hi All,
May i know whether vrf-target import target:x:x will overide vrf-target target:x:x ? As i'm understand the vrf-target target:x:x use to communicate with remote peer but what purpose of vrf-target import target:x:x ?Can someone explain to me.
vrf-target {
target:7777:1111; import target:4:4;Thanks and appreciate any feedback
vrf-target import target:x:x will override vrf-target target:x:x
I assume this behavior has to do with the general convention of more specific ones being preferred ,over generic ones
vrf-target target:x:x by default generate the appropriate policy to match "all" routes for both export and import .
vrf-target import target:x:x by default generate the appropriate policy to match "all" routes for import that matches the configured target and places in the bgp.l3vpn.0,as your vrf routes are imported from bgp.l3vpn.0.
There is no difference as such between the two ,as the former is meant for both import and export and the latter meant specifically for import
No explicit policy required in both the cases to match the PE-CE protocol for export and matching BGP in import(as VRF routes are being imported from bgp.l3vpn.0).
Explicit policy is required matching the protocol , only when vrf-import and vrf-export is being used.
Please let me know for any clarification
Hi, Experts,
I made a simple test to export the TED to lsdist.0, only Nodes and Links NLRIs can be found in lsdist.0, no Prefix NLRI in there. I purposely exported an external route into ISIS, and confirmed that routes can be found in the routing table on the BGP-ls router, but question is how to trancode this kind of routes into lsdist.0?
I also noticed the logic here is ISIS --> TED --> lsdist.0, the external IGP routes seems can't be imported from IGP database into TE database, so that's explain why no Prefix NLRI in lsdist.0. Please correct me if anything i'm wrong.
Thanks!
Hi Vinod,
So u mean the vrf-target import target:4:4 and vrf-target export target:4:4 will replace / overide tag route the vrf-target target:x:x ? So if it overide then the Remote PE cannot connect using vrf-target target:x:x and it will made an outage right? Without the vrf-target import target:4:4 and vrf-target export target:4:4 i'm cannot leak route between this two VRF.
SITE_1 {
instance-type vrf;
interface ge-4/0/1.35;
interface ge-2/1/1.70;
route-distinguisher 7777:1111;
vrf-target {
target:7777:1111; -------------> To remote PE import target:4:4;
export target:4:4;
routing-options {
auto-export
SITE_2 {
instance-type vrf;
interface ge-1/1/1.40;
interface ge-3/2/2.50;
route-distinguisher 7777:2222;
vrf-target {
target:7777:2222; --------------> To Remote PE import target:4:4;
export target:4:4;
routing-options {
auto-export
Thanks and appreciate someone confirmation
Yes vrf-target export and vrf-target import overrides vrf-target target:x:x
Please use vrf-import and vrf-export instead of vrf-target import and vrf-target export, using this you can use multiple RT's
for import and export.
Only difference is you have to do via policy.
An example for vrf-import
routing-instances SITE-1 vrf-import import-vpn-A
policy-options{
policy-statement import-vpn-a {
term 1 {
from {
protocol bgp ; <<<< THIS IS always bgp as vrf routes are imported from bgp.l3vpn.0
community vpn-a;
}
then {
accept;
}
}
}
community vpn-a member target:7777:1111;
community vpn-a member target:4:4;
An example for vrf-export
routing-instances SITE-1 vrf-export export-vpn-A
If BGP is the PE-CE protocol
policy-options{
policy-statement export-vpn-a {
term 1 {
from {
protocol [bgp direct];
}
then
{
community add vpn-a;
}
}
}
If OSPF is the PE-CE protocol
policy-options{
policy-statement export-vpn-a {
term 1 {
from {
protocol [ospf direct];
}
then
{
community add vpn-a;
}
}
}
community vpn-a member target:7777:1111;
community vpn-a member target:4:4;
One of these targets can be your route-leak target(common between the leaked instances) and the other can be the target specific to the particular vrf....
Please rever back if you face any issues
Hi Vinod,
If need use vrf-import and vrf-export it need a lot changes in entire PE customer because the existing network dont use community style. The just use vrf-target target:x:x to make sure other VRF in other PE can communicate each other. Beside use vrf-import and vrf-export is there any way more simplest with minimal outage. I'm not sure if i'm use rib-group style can mde big outage if i make config mistake.
Thanks and appreciate some info.
Not sure about ways, other than community style for accepting/exporting multiple RT's , I will check for an alternative,if there is any.
RIB groups can be done without config mistake . If you can share your requirement , we can try with RIB-group .